On branch edburns/steveklabnik-wayback Use wayback machine link for non-existing blog post.

_articles/ar/best-practices.md

@@ -108,7 +108,7 @@ related:
 
 لا تترك مساهمة لا ترغب بها مفتوحة فقط لأنك تشعر بالذنب أو بدافع اللطف. مع مرور الوقت، تراكم issues و PRs غير المردود عليها سيجعل العمل على مشروعك أكثر توترًا ويخلق شعورًا بالرهبة.
 
-من الأفضل أن تقوم بإغلاق المساهمات التي تعلم مسبقًا أنك لن تقبلها، وبشكل فوري. وإذا كان مشروعك يعاني بالفعل من backlog كبير، فإن @steveklabnik يقدّم نصائح ممتازة حول [كيفية إجراء triage للـ issues بطريقة فعّالة](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+من الأفضل أن تقوم بإغلاق المساهمات التي تعلم مسبقًا أنك لن تقبلها، وبشكل فوري. وإذا كان مشروعك يعاني بالفعل من backlog كبير، فإن @steveklabnik يقدّم نصائح ممتازة حول [كيفية إجراء triage للـ issues بطريقة فعّالة](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
 
 أيضًا، تجاهل المساهمات يرسل إشارة سلبية إلى الـ community. المشاركة في مشروع مفتوح المصدر قد تكون خطوة مخيفة، خصوصًا إذا كانت هذه أول تجربة للشخص. حتى إن لم تقبل المساهمة، فمن المهم الاعتراف بجهد صاحبها وشكره على اهتمامه، فمجرد مشاركته هو بمثابة مجاملة كبيرة للمشروع!
 
@@ -227,7 +227,7 @@ related:
   أنا أؤمن بأن tests ضرورية لكل code يعمل عليه الناس. فلو كان code صحيحًا وكاملًا تمامًا، لما احتاج إلى أي تعديل – نحن نكتب code فقط عندما يكون هناك خلل، سواء كان سببًا في It crashes أو لغياب ميزة معينة .
   وبغض النظر عن التغييرات، تظل tests أساسية لاكتشاف أي regressions قد تدخلها عن طريق الخطأ
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 

_articles/best-practices.md

@@ -105,7 +105,7 @@ If you receive a contribution you don't want to accept, your first reaction migh
 
 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).
+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://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/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!
 
@@ -223,7 +223,7 @@ If you add tests, make sure to explain how they work in your CONTRIBUTING file.
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 

_articles/bg/best-practices.md

@@ -104,7 +104,7 @@ related:
 
 Не оставяйте отворен нежелан принос, защото се чувствате виновни или искате да сте мили. С течение на времето вашите въпроси без отговор и PR ще станат излишни. Това ще направи работата по вашия проект много по-стресираща и смущаваща.
 
-Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [как да избирате ефективно въпроси](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [как да избирате ефективно въпроси](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
 
 Второ, игнорирането на приносите изпраща отрицателен сигнал към вашата общност. Приносът към проект може да бъде смущаващ, особено ако на някого е за първи път. Дори и да не приемете техния принос, поздравете човека зад него и му благодарете за проявения интерес. Това е страхотен комплимент!
 
@@ -222,7 +222,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Мисля, че тестването е необходимо за целия код, върху който хората работят. Ако кодът беше напълно и перфектно правилен, нямаше да има нужда от промени - ние пишем код само когато нещо е правилно. грешно, или "Той се срива", или "Тази или онази функция липсва". Каквито и промени да правите, тестването е от съществено значение за улавяне на всякакви регресии, които може случайно да въведете.
   <p markdown="1" class="pquote-credit">
-— @edunham, [Общностна автоматизация на Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, [Общностна автоматизация на Rust"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 

_articles/bn/best-practices.md

@@ -107,7 +107,7 @@ related:
 
 অপরাধবোধ বা ভালো হতে চাও বলে অবাঞ্ছিত অবদান খোলা রাখবেন না। সময়ের সাথে সাথে, আপনার উত্তর না দেওয়া সমস্যা এবং জনসংযোগ আপনার প্রকল্পে কাজ করাকে আরও বেশি চাপপূর্ণ এবং ভীতিকর করে তুলবে।
 
-যেসব অবদান আপনি গ্রহণ করতে চান না তা অবিলম্বে বন্ধ করে দেওয়া ভালো। যদি আপনার প্রকল্প ইতিমধ্যেই একটি বড় ধরনের ব্যাকলগের কারণে ভুগছে, তাহলে @steveklabnik-এর কাছে [সমস্যাগুলি দক্ষতার সাথে কীভাবে সমাধান করা যায়](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) তার পরামর্শ আছে ।
+যেসব অবদান আপনি গ্রহণ করতে চান না তা অবিলম্বে বন্ধ করে দেওয়া ভালো। যদি আপনার প্রকল্প ইতিমধ্যেই একটি বড় ধরনের ব্যাকলগের কারণে ভুগছে, তাহলে @steveklabnik-এর কাছে [সমস্যাগুলি দক্ষতার সাথে কীভাবে সমাধান করা যায়](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) তার পরামর্শ আছে ।
 
 দ্বিতীয়ত, অবদান উপেক্ষা করা আপনার সম্প্রদায়ের কাছে একটি নেতিবাচক সংকেত পাঠায়। কোনও প্রকল্পে অবদান রাখা ভীতিকর হতে পারে, বিশেষ করে যদি এটি কারও প্রথমবারের মতো হয়। এমনকি যদি আপনি তাদের অবদান গ্রহণ না করেন, তবুও এর পিছনে থাকা ব্যক্তিকে স্বীকৃতি দিন এবং তাদের আগ্রহের জন্য তাদের ধন্যবাদ জানান। এটি একটি বড় প্রশংসা!
 
@@ -225,7 +225,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   আমি বিশ্বাস করি যে সকল কোডের উপর মানুষ কাজ করে তার জন্য পরীক্ষা অপরিহার্য। যদি কোডটি সম্পূর্ণ এবং নিখুঁতভাবে সঠিক হত, তাহলে এতে পরিবর্তনের প্রয়োজন হত না - আমরা কেবল তখনই কোড লিখি যখন কিছু ভুল হয়, তা সে "এটি ক্র্যাশ" হোক বা "এটিতে অমুক-অমুক বৈশিষ্ট্যের অভাব রয়েছে"। এবং আপনি যে পরিবর্তনই করুন না কেন, আপনার ভুলক্রমে প্রবর্তিত যেকোনো রিগ্রেশন ধরার জন্য পরীক্ষাগুলি অপরিহার্য।
   <p markdown="1" class="pquote-credit">
-— @edunham, ["রাস্টের কমিউনিটি অটোমেশন"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["রাস্টের কমিউনিটি অটোমেশন"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 

_articles/de/best-practices.md

@@ -113,7 +113,7 @@ Wenn Sie einen Beitrag erhalten, den Sie nicht annehmen möchten, könnte Ihre e
 
 Lassen Sie keinen unerwünschten Beitrag offen, weil Sie sich schuldig fühlen oder nett sein wollen. Im Laufe der Zeit werden unbeantwortete Issues und PRs die Projektarbeit stressiger und einschüchternder machen.
 
-Schließen Sie Beiträge lieber sofort, von denen Sie wissen, dass Sie sie nicht annehmen wollen. Wenn Ihr Projekt bereits unter einem großen Rückstand leidet, hat @steveklabnik Vorschläge für [eine effiziente Behandlung von Issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) (Englisch).
+Schließen Sie Beiträge lieber sofort, von denen Sie wissen, dass Sie sie nicht annehmen wollen. Wenn Ihr Projekt bereits unter einem großen Rückstand leidet, hat @steveklabnik Vorschläge für [eine effiziente Behandlung von Issues](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) (Englisch).
 
 Zweitens sendet das Ignorieren von Beiträgen ein negatives Signal an die Gemeinschaft um Ihr Projekt. Einen Projektbeitrag einzureichen, kann einschüchternd sein, besonders für Neulinge. Auch wenn Sie ihren Beitrag nicht annehmen, danken Sie der einreichenden Person für ihr Interesse. Das ist ein großes Kompliment!
 
@@ -253,7 +253,7 @@ Wenn Sie Tests hinzufügen, erklären Sie deren Funktionsweise in Ihrer CONTRIBU
   _I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce._
 
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 

_articles/el/best-practices.md

@@ -105,7 +105,7 @@ related:
 
 Μην αφήνετε μια ανεπιθύμητη συνεισφορά ανοιχτή επειδή αισθάνεστε ένοχοι ή επειδή θέλετε να είστε ευγενικοί. Με την πάροδο του χρόνου, τα αναπάντητα ζητήματα και αιτήματα θα κάνουν την εργασία στο έργο σας να μοιάζει πολύ πιο αγχωτική και εκφοβιστική.
 
-Είναι προτιμότερο να κλείνετε αμέσως τις συνεισφορές που ξέρετε ότι δεν θέλετε να δεχτείτε. Αν το έργο σας πάσχει ήδη από ένα μεγάλο ανεκτέλεστο, ο @steveklabnik έχει προτάσεις για το [πώς να ταξινομείτε αποτελεσματικά τα θέματα](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Είναι προτιμότερο να κλείνετε αμέσως τις συνεισφορές που ξέρετε ότι δεν θέλετε να δεχτείτε. Αν το έργο σας πάσχει ήδη από ένα μεγάλο ανεκτέλεστο, ο @steveklabnik έχει προτάσεις για το [πώς να ταξινομείτε αποτελεσματικά τα θέματα](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
 
 Δεύτερον, η αγνόηση συνεισφορών στέλνει ένα αρνητικό μήνυμα στην κοινότητά σας. Η συνεισφορά σε ένα έργο μπορεί να είναι εκφοβιστική, ειδικά αν είναι η πρώτη φορά που κάποιος συνεισφέρει. Ακόμα και αν δεν αποδεχτείτε τη συνεισφορά του, αναγνωρίστε το άτομο που βρίσκεται πίσω από αυτή και ευχαριστήστε το για το ενδιαφέρον του. Είναι ένα μεγάλο κομπλιμέντο!
 
@@ -223,7 +223,7 @@ related:
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Πιστεύω ότι οι δοκιμές είναι απαραίτητες για όλο τον κώδικα που δουλεύουν οι άνθρωποι. Αν ο κώδικας ήταν πλήρως και απόλυτα σωστός, δεν θα χρειαζόταν αλλαγές - γράφουμε κώδικα μόνο όταν κάτι είναι λάθος, είτε αυτό σημαίνει ότι "Καταρρέει" είτε ότι "Του λείπει το τάδε χαρακτηριστικό". Και ανεξαρτήτως των αλλαγών που κάνετε, οι δοκιμές είναι απαραίτητες για να πιάνετε τυχόν παλινδρομήσεις που μπορεί να εισαγάγετε κατά λάθος.
   <p markdown="1" class="pquote-credit">
-- @edunham, ["Rust's Community Automation"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+- @edunham, ["Rust's Community Automation"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>
 

_articles/es/best-practices.md

@@ -104,7 +104,7 @@ Si recibes una contribución que no deseas aceptar, tu primera reacci&oacu
 
 No dejes abierta una contribución no deseada porque te sientas culpable o quieras ser amable. Con el tiempo, tus issues sin respuesta y PRs hará que trabajar en tu proyecto se sienta mucho más estresante e intimidante.
 
-Es mejor cerrar de inmediato las contribuciones que sabes que no quieres aceptar. Si tu proyecto ya sufre de un gran backlog o lista de funcionalidades a implementar, @steveklabnik tiene sugerencias para [cómo elegir issues de manera eficiente](https://words.steveklabnik.com/how-to-be-an-open-source-gardener).
+Es mejor cerrar de inmediato las contribuciones que sabes que no quieres aceptar. Si tu proyecto ya sufre de un gran backlog o lista de funcionalidades a implementar, @steveklabnik tiene sugerencias para [cómo elegir issues de manera eficiente](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener).
 
 En segundo lugar, ignorar las contribuciones envía una señal negativa a tu comunidad. Contribuir a un proyecto puede ser intimidante, especialmente si es la primera vez de alguien. Incluso si no aceptas su contribución, reconocer a la persona detrás de ella y agradecerles por su interés. ¡Es un gran cumplido!
 
@@ -222,7 +222,7 @@ Si agregas testing, asegúrate de explicar cómo funcionan en su arc
   <img src="https://avatars.githubusercontent.com/edunham?s=180" class="pquote-avatar" alt="avatar">
   Creo que las pruebas son necesarias para todo c&oacute;digo en el que la gente trabaja. Si el c&oacute;digo era totalmente y perfectamente correcto, no necesitar&iacute;a cambios - s&oacute;lo escribimos c&oacute;digo cuando algo est&aacute; mal, ya sea "Se bloquea" o "Falta tal o cual caracter&iacute;stica". Independientemente de los cambios que est&eacute;s haciendo, las pruebas son esenciales para capturar cualquier regresi&oacute;n que pueda introducir accidentalmente.
   <p markdown="1" class="pquote-credit">
-— @edunham, ["Automatizaci&oacute;n de la comunidad de Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html)
+— @edunham, ["Automatizaci&oacute;n de la comunidad de Rust"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
   </p>
 </aside>