-— @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)
diff --git a/_articles/best-practices.md b/_articles/best-practices.md index 43b056c6271..f18c094a89a 100644 --- a/_articles/best-practices.md +++ b/_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.
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.
-— @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)
diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md index c94d9ef9a36..dc2b5b1cbe4 100644 --- a/_articles/bg/best-practices.md +++ b/_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:
Мисля, че тестването е необходимо за целия код, върху който хората работят. Ако кодът беше напълно и перфектно правилен, нямаше да има нужда от промени - ние пишем код само когато нещо е правилно. грешно, или "Той се срива", или "Тази или онази функция липсва". Каквито и промени да правите, тестването е от съществено значение за улавяне на всякакви регресии, които може случайно да въведете.
-— @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)
diff --git a/_articles/bn/best-practices.md b/_articles/bn/best-practices.md index dea8852c5b4..5fd269f78c0 100644 --- a/_articles/bn/best-practices.md +++ b/_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:
আমি বিশ্বাস করি যে সকল কোডের উপর মানুষ কাজ করে তার জন্য পরীক্ষা অপরিহার্য। যদি কোডটি সম্পূর্ণ এবং নিখুঁতভাবে সঠিক হত, তাহলে এতে পরিবর্তনের প্রয়োজন হত না - আমরা কেবল তখনই কোড লিখি যখন কিছু ভুল হয়, তা সে "এটি ক্র্যাশ" হোক বা "এটিতে অমুক-অমুক বৈশিষ্ট্যের অভাব রয়েছে"। এবং আপনি যে পরিবর্তনই করুন না কেন, আপনার ভুলক্রমে প্রবর্তিত যেকোনো রিগ্রেশন ধরার জন্য পরীক্ষাগুলি অপরিহার্য।
-— @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)
diff --git a/_articles/de/best-practices.md b/_articles/de/best-practices.md index e4402da32af..572363f5799 100644 --- a/_articles/de/best-practices.md +++ b/_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._-— @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)
diff --git a/_articles/el/best-practices.md b/_articles/el/best-practices.md index e4389724d1a..db4462b5c0e 100644 --- a/_articles/el/best-practices.md +++ b/_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:
Πιστεύω ότι οι δοκιμές είναι απαραίτητες για όλο τον κώδικα που δουλεύουν οι άνθρωποι. Αν ο κώδικας ήταν πλήρως και απόλυτα σωστός, δεν θα χρειαζόταν αλλαγές - γράφουμε κώδικα μόνο όταν κάτι είναι λάθος, είτε αυτό σημαίνει ότι "Καταρρέει" είτε ότι "Του λείπει το τάδε χαρακτηριστικό". Και ανεξαρτήτως των αλλαγών που κάνετε, οι δοκιμές είναι απαραίτητες για να πιάνετε τυχόν παλινδρομήσεις που μπορεί να εισαγάγετε κατά λάθος.
-- @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)
diff --git a/_articles/es/best-practices.md b/_articles/es/best-practices.md index c8aee16a1d5..f69ee0f0d6a 100644 --- a/_articles/es/best-practices.md +++ b/_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
Creo que las pruebas son necesarias para todo código en el que la gente trabaja. Si el código era totalmente y perfectamente correcto, no necesitaría cambios - sólo escribimos código cuando algo está mal, ya sea "Se bloquea" o "Falta tal o cual característica". Independientemente de los cambios que estés haciendo, las pruebas son esenciales para capturar cualquier regresión que pueda introducir accidentalmente.
-— @edunham, ["Automatización de la comunidad de Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, ["Automatización de la comunidad de Rust"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/fa/best-practices.md b/_articles/fa/best-practices.md index 8a22e65aa06..fdd3285d9c5 100644 --- a/_articles/fa/best-practices.md +++ b/_articles/fa/best-practices.md @@ -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://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) پیشنهاداتی در این خصوص ارائه کرده است. ثانیاً، بیتوجهی به مشارکتهایتان، سیگنالهای منفیای به درون اجتماع میفرستد. مشارکت در هر پروژهای میتواند دلهرهآور باشد، خصوصاً اگر برای اولین بار باشد که در پروژهای شرکت میکنید. حتی اگر مشارکت آنها را قبول نکردید، از آن شخص تشکر کرده و از توجه او سپاسگزار باشید. کار پسندیدهای است! @@ -223,7 +223,7 @@ related:
من معتقد هستم که تستها برای همهی کدهایی که افراد روی آنها کار میکنند، لازم است. اگر کد کاملاً صحیح و سالم باشد، دیگر نیازی به تغییر نخواهد داشت - ما فقط درصورتی که مشکلی پیش آمده باشد کد مینویسیم؛ مگر در زمانهایی که کد «خراب شود» یا «فاقد فلان ویژگی باشد». و صرف نظر از تغییراتی که ایجاد میکنید، تستها برای دستیابی به رگرسیونهایی که به طور تصادفی به وجود میآورید، ضروری است.
-— @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)
diff --git a/_articles/fr/best-practices.md b/_articles/fr/best-practices.md index e3252b7f877..caf80c68ee5 100644 --- a/_articles/fr/best-practices.md +++ b/_articles/fr/best-practices.md @@ -105,7 +105,7 @@ Si vous recevez une contribution que vous ne voulez pas accepter, votre premièr Ne laissez pas une contribution indésirable ouverte parce que vous avez un sentiment de culpabilité ou que vous voulez être gentil. Au fil du temps, vos issues sans réponse et les PRs rendront le travail sur votre projet beaucoup plus stressant et intimidant. -Il est préférable de fermer immédiatement les contributions que vous ne voulez pas accepter. Si votre projet souffre déjà d'un important retard, @steveklabnik propose des suggestions pour [comment trier efficacement les issues](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). +Il est préférable de fermer immédiatement les contributions que vous ne voulez pas accepter. Si votre projet souffre déjà d'un important retard, @steveklabnik propose des suggestions pour [comment trier efficacement les issues](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener). Deuxièmement, ignorer les contributions envoie un signal négatif à votre communauté. Contribuer à un projet peut être intimidant, surtout s'il s'agit de la première fois. Même si vous n'acceptez pas leur contribution, remerciez la personne derrière et remerciez-la de son intérêt. C'est un gros compliment! @@ -221,7 +221,7 @@ Si vous ajoutez des tests, assurez-vous d'expliquer comment ils fonctionnent dan
Je crois que des tests sont nécessaires pour tout le code sur lequel les gens travaillent. Si le code était complet et parfaitement correct, il n'aurait pas besoin de modifications - nous n'écrivons du code que lorsque quelque chose ne va pas, que ce soit "Il plante" ou "Il manque telle ou telle fonctionnalité". Et quels que soient les changements que vous effectuez, les tests sont essentiels pour détecter les régressions que vous pourriez introduire accidentellement.
-— @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)
diff --git a/_articles/hi/best-practices.md b/_articles/hi/best-practices.md index db31c75bfe7..4ad309be22f 100644 --- a/_articles/hi/best-practices.md +++ b/_articles/hi/best-practices.md @@ -105,7 +105,7 @@ related: अनचाहे योगदान को खुले छोडने का कारण यह नहीं होना चाहिए कि आपको आपत्ति महसूस हो रही हो या आप अच्छे बनना चाहते हों। समय के साथ, आपके बिना उत्तरित मुद्दे और पुल रिक्वेस्ट (PRs) से आपके प्रोजेक्ट पर काम करने में अधिक तनावपूर्ण और डरावनी भावना उत्पन्न हो सकती है। -जिन योगदानों को आप जानते हैं कि आप स्वीकार नहीं करना चाहते, उन्हें तुरंत बंद कर देना बेहतर है। यदि आपका प्रोजेक्ट पहले से ही बड़े बैकलॉग से ग्रस्त है, @steveklabnik [how to triage issues efficiently](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) के लिए सुझाव हैं . +जिन योगदानों को आप जानते हैं कि आप स्वीकार नहीं करना चाहते, उन्हें तुरंत बंद कर देना बेहतर है। यदि आपका प्रोजेक्ट पहले से ही बड़े बैकलॉग से ग्रस्त है, @steveklabnik [how to triage issues efficiently](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) के लिए सुझाव हैं . योगदान को नज़रअंदाज करना आपके समुदाय को नकारात्मक संकेत भेजता है। किसी प्रोजेक्ट में योगदान देना डराने वाला हो सकता है, खासकर अगर यह किसी के लिए पहली बार हो। भले ही आप उनके योगदान को स्वीकार न करें, इसके पीछे वाले व्यक्ति को स्वीकार करें और उनकी रुचि के लिए उन्हें धन्यवाद दें। यह एक बड़ी प्रशंसा है! @@ -224,7 +224,7 @@ You shouldn't need more than 1-2 sentences to respond. For example, when a user
मेरा मानना है कि उन सभी कोड के लिए परीक्षण आवश्यक हैं जिन पर लोग काम करते हैं। यदि कोड पूरी तरह से और पूरी तरह से सही था, तो इसमें बदलाव की आवश्यकता नहीं होगी - हम केवल तभी कोड लिखते हैं जब कुछ गलत होता है, चाहे वह "यह क्रैश हो जाता है" या "इसमें ऐसी और ऐसी सुविधा का अभाव है"। और चाहे आप जो भी बदलाव कर रहे हों, आपके द्वारा गलती से पेश किए गए किसी भी प्रतिगमन को पकड़ने के लिए परीक्षण आवश्यक हैं।
-— @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)
diff --git a/_articles/hu/best-practices.md b/_articles/hu/best-practices.md index c4c9ecd2d31..755ab2854f9 100644 --- a/_articles/hu/best-practices.md +++ b/_articles/hu/best-practices.md @@ -105,7 +105,7 @@ Ha olyan hozzájárulást kapsz, amelyet nem akarsz elfogadni, akkor az első re Ne hagyj nyitva nem kívánt hozzájárulást, csak azért, mert bűntudatot éreznél attól, hogy lezárod. Az idő múlásával a megválaszolatlan kérdések és a nem kívánt beolvasztási kérelmek sokkal stresszesebbé és elrettentőbbé teszik a projekttel való munkát. -Sokkal jobb, ha azonnal lezárod a hozzájárulást, ha nem akarod elfogadni. Ha a projekted már eleve nagy feladatlistával rendelkezik, akkor itt van @steveklabnik javaslata arra, hogy [hogyan priorizáld hatékonyan az issue-kat](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). +Sokkal jobb, ha azonnal lezárod a hozzájárulást, ha nem akarod elfogadni. Ha a projekted már eleve nagy feladatlistával rendelkezik, akkor itt van @steveklabnik javaslata arra, hogy [hogyan priorizáld hatékonyan az issue-kat](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener). Ugyanakkor a hozzájárulások rendszeres figyelmen kívül hagyása negatív jelet küldhet a közösségnek. A projekthez való hozzájárulás elrettentő is lehet, különösen, ha valaki először próbálja. Még ha nem is fogadod el az általa benyújtott hozzájárulást, becsüld meg azt a személyt aki benyújtotta, és mondj köszönetet az érdeklődése iránt, ez nagy dicséret! @@ -223,7 +223,7 @@ Ha teszteket adsz hozzá, akkor bizonyosodj meg arról, hogy elmagyaráztad azt
Úgy gondolom, hogy tesztek szükségesek minden olyan kódhoz, amelyen az emberek dolgoznak. Ha a kód teljesen és tökéletesen helyes volt, akkor nem lenne szükség változtatásokra - csak akkor írunk kódot, ha valami nincs rendben, legyen az összeomlás vagy hiányzó funkció. És függetlenül attól, hogy milyen változtatásokat hajtunk végre, a tesztek elengedhetetlenek a véletlenszerűen bevezetett regressziós hibák kivédésében.
-— @edunham, ["A Rust közösségi automatizálása"](https://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, ["A Rust közösségi automatizálása"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/id/best-practices.md b/_articles/id/best-practices.md index 4ab11ff70c2..a096be94919 100644 --- a/_articles/id/best-practices.md +++ b/_articles/id/best-practices.md @@ -105,7 +105,7 @@ Jika Anda menerima kontribusi yang tidak Anda inginkan, reaksi pertama Anda mung Jangan biarkan kontribusi yang tidak diinginkan tetap terbuka karena Anda merasa bersalah atau ingin bersikap baik. Pada akhirnya, masalah yang tidak terjawab dan PR akan membuat pekerjaan proyek Anda menjadi lebih berat dan mengintimidasi Anda. -Akan lebih baik untuk langsung menutup kontribusi yang Anda tahu tidak akan diterima. Jika proyek Anda mengalami hambatan yang besar, @steveklabnik memiliki saran untuk [mengatasi laporan masalah secara efisien](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). +Akan lebih baik untuk langsung menutup kontribusi yang Anda tahu tidak akan diterima. Jika proyek Anda mengalami hambatan yang besar, @steveklabnik memiliki saran untuk [mengatasi laporan masalah secara efisien](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener). Kedua, mengabaikan kontribusi akan mengirimkan sinyal negatif pada komunitas Anda. Berkontribusi pada sebuah proyek bisa jadi menakutkan, apalagi untuk pertama kalinya bagi orang lain. Meskipun Anda tidak menerima kontribusi mereka, akui hasil pekerjaan mereka dan ucapkan terima kasih atas minat mereka. Itu adalah sebuah pujian yang besar! @@ -221,7 +221,7 @@ Jika Anda menambahkan pengujian, pastikan untuk menjelaskan bagaimana mereka bek
Saya percaya bahwa pengujian otomatis sangat diperlukan untuk semua kode yang dikerjakan orang-orang. Jika kode tersebut benar, maka tidak diperlukan perubahan - kita hanya menuliskan kode apabila terjadi kesalahan, apakah "crash" atau "kurang fitur". Tanpa memperhatikan perubahan yang Anda lakukan, pengujian otomatis sangatlah penting untuk menangkap regresi kesalahan yang mungkin Anda timbulkan.
-— @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)
diff --git a/_articles/it/best-practices.md b/_articles/it/best-practices.md index 15064842755..3ca6890a16c 100644 --- a/_articles/it/best-practices.md +++ b/_articles/it/best-practices.md @@ -104,7 +104,7 @@ Se ricevi un messaggio che non vuoi accettare, la tua prima reazione potrebbe es 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). +È 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://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/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! @@ -222,7 +222,7 @@ Se aggiungi test, assicurati di spiegare come funzionano nel tuo file CONTRIBUTI
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.
-— @edunham, [Automazione comunitaria di Rust"](https://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, [Automazione comunitaria di Rust"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/ja/best-practices.md b/_articles/ja/best-practices.md index d1aa3c43487..7eb0c54daba 100644 --- a/_articles/ja/best-practices.md +++ b/_articles/ja/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)が役に立つでしょう。 また、コントリビュートを無視することはコミュニティに悪い影響を与えます。プロジェクトにコントリビュートすることは威圧感があります。特に初めてのコントリビュートであればなおさらです。たとえ、そのコントリビュートを受け入れないとしても、その人に対して受け入れない旨と感謝の気持ちを伝えましょう。それは大きな賛辞となります！ @@ -221,7 +221,7 @@ related:
私は人々が実装するあらゆるコードに対してテストが必要だと思っています。もしコードが完全に正しいのであれば、変更の必要はありませんが、 私達がコードを書くときは何かがおかしいときです、それは「クラッシュする」であったり「これこれの機能が足りない」といったようなケースです。どんな変更をしようとしているのであれ、テストは誤ってバグを入れ込んでしまう事を防ぐために非常に重要です。
-— @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)
diff --git a/_articles/ko/best-practices.md b/_articles/ko/best-practices.md index 26a6bb5407e..36e1a87c2fb 100644 --- a/_articles/ko/best-practices.md +++ b/_articles/ko/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)을 정리해 두었으니 참고하세요. 기여를 무시하는 것은 커뮤니티에 부정적인 신호를 보내는 것과 마찬가지입니다. 프로젝트에의 기여는 쉬운 일이 아닙니다. 특히 처음 기여하는 사람이라면 더 그렇습니다. 그들의 기여를 받아들이고 싶지 않다면, 적어도 그들이 보인 흥미와 노력에 대해 감사를 표하세요. 그것만으로도 큰 칭찬입니다! @@ -221,7 +221,7 @@ related:
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.
-— @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)
diff --git a/_articles/ms/best-practices.md b/_articles/ms/best-practices.md index fc11cd94e4d..9f74c30ef6c 100644 --- a/_articles/ms/best-practices.md +++ b/_articles/ms/best-practices.md @@ -105,7 +105,7 @@ Sekiranya anda menerima sumbangan yang tidak mahu anda terima, reaksi pertama an 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). +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://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/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! @@ -223,7 +223,7 @@ Sekiranya anda menambahkan ujian, pastikan untuk menerangkan bagaimana ia berfun
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.
-— @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)
diff --git a/_articles/nl/best-practices.md b/_articles/nl/best-practices.md index 0fedcb43424..c8589f3e65a 100644 --- a/_articles/nl/best-practices.md +++ b/_articles/nl/best-practices.md @@ -111,7 +111,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](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://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/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! @@ -239,7 +239,7 @@ Als u tests toevoegt, leg dan uit hoe ze werken in uw CONTRIBUTING-bestand. _I believe that tests are necessary for all code that people work on. If the code was fully and perfectly correct, it wouldn't need changes – we only write code when something is wrong, whether that's "It crashes" or "It lacks such-and-such a feature". And regardless of the changes you're making, tests are essential for catching any regressions you might accidentally introduce._-— @edunham, ["Rust's gemeenschapsautomatisering"](https://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, ["Rust's gemeenschapsautomatisering"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/pcm/best-practices.md b/_articles/pcm/best-practices.md index 785dc0e87e1..1503422bd03 100644 --- a/_articles/pcm/best-practices.md +++ b/_articles/pcm/best-practices.md @@ -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](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) so e go dey efficient. +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://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) so e go dey efficient. If you no wan accept one contribution: @@ -203,7 +203,7 @@ If you add tests, make sure say you explain how them dey work for your CONTRIBUT
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.
-— @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)
diff --git a/_articles/pl/best-practices.md b/_articles/pl/best-practices.md index e15b7cd62c4..a770caff068 100644 --- a/_articles/pl/best-practices.md +++ b/_articles/pl/best-practices.md @@ -106,7 +106,7 @@ Jeśli otrzymasz wkład, którego nie chcesz zaakceptować, pierwszą reakcją m Nie zostawiaj niechcianego wkładu otwartego, ponieważ czujesz się winny lub chcesz być miły. Z czasem Twoje problemy i PR bez odpowiedzi sprawią, że praca nad projektem będzie o wiele bardziej stresująca i zastraszająca. -Lepiej natychmiast zamknąć wpisy, o których wiesz, że nie chcesz ich akceptować. Jeśli twój projekt ma już duże zaległości, @steveklabnik ma sugestie dotyczące [jak skutecznie segregować problemy](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). +Lepiej natychmiast zamknąć wpisy, o których wiesz, że nie chcesz ich akceptować. Jeśli twój projekt ma już duże zaległości, @steveklabnik ma sugestie dotyczące [jak skutecznie segregować problemy](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener). Po drugie, ignorowanie wkładów wysyła negatywny sygnał do społeczności. Wkład w projekt może być zastraszający, szczególnie jeśli jest to pierwszy raz. Nawet jeśli nie zaakceptujesz ich wkładu, potwierdź osobę, która za tym stoi i podziękuj jej za zainteresowanie. To wielki komplement! @@ -228,7 +228,7 @@ Jeśli dodasz testy, wyjaśnij, jak działają w pliku CONTRIBUTING. 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.-— @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)
diff --git a/_articles/pt/best-practices.md b/_articles/pt/best-practices.md index f772ed06c07..d9b886005ff 100644 --- a/_articles/pt/best-practices.md +++ b/_articles/pt/best-practices.md @@ -105,7 +105,7 @@ Se você recebe uma contribuição que não deseja aceitar, sua primeira reaçã Não deixe uma contribuição indesejada aberta porque você se sente culpado ou quer ser legal. Com o passar do tempo, suas issues e PRs não respondidas farão o trabalho em seu projeto pareça mais estressante e intimidador. -É melhor fechar imediatamente as contribuições que você sabe que não deseja aprovar. Se seu projeto já sofre com um grande backlog, @steveklabnik tem sugestões para [como realizar a triagem de issues eficientemente](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). +É melhor fechar imediatamente as contribuições que você sabe que não deseja aprovar. Se seu projeto já sofre com um grande backlog, @steveklabnik tem sugestões para [como realizar a triagem de issues eficientemente](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener). Em segundo lugar, ignorar contribuições envia um sinal negativo para sua comunidade. Contribuir para um projeto pode ser intimidador, especialmente se é a primeira vez de alguém. Mesmo que você não aceite a contribuição dele(a), dê reconhecimento à pessoa por trás dela e agradeça pelo interesse. É um grande elogio! @@ -221,7 +221,7 @@ Se você adicionar testes, tenha certeza de ter explicado como eles funcionam em
Eu acredito que testes são necessários em todos os códigos que as pessoas trabalharam. Se o código estivesse completo e perfeitamente correto, ele não precisaria de alterações - nós só escrevemos código quando algo está errado, ou seja "Ele falha" ou "Ele não possui tal recurso". E, independentemente das mudanças que você esteja fazendo, os testes são essenciais para detectar qualquer regressão que você possa introduzir acidentalmente.
-— @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)
diff --git a/_articles/ro/best-practices.md b/_articles/ro/best-practices.md index a761b6dc5b3..c27a2c06bea 100644 --- a/_articles/ro/best-practices.md +++ b/_articles/ro/best-practices.md @@ -119,7 +119,7 @@ Dacă primești o contribuție pe care nu vrei să o accepți, prima ta reacție Nu lăsa o contribuție nedorită deschisă pentru că te simți vinovat sau dorești să fii drăguț. În timp, problemele la care nu s-a răspuns și PR-urile vor face lucrul pe proiectul tău să se simtă cu foarte mult mai stresant și mai intimidant. -Este mai bine să închizi imediat contribuțiile pe care știi că nu vrei să le accepți. Dacă proiectul tău suferă deja de restanțe mari, @steveklabnik are sugestii pentru [cum să triezi problemele eficient](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). +Este mai bine să închizi imediat contribuțiile pe care știi că nu vrei să le accepți. Dacă proiectul tău suferă deja de restanțe mari, @steveklabnik are sugestii pentru [cum să triezi problemele eficient](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener). În al doilea rând, ignorarea contribuțiilor trimite un semnal negativ către comunitatea ta. A contribui la un proiect poate fi intimidant, în special pentru prima dată. Chiar dacă nu accepți contribuția, consideră persoana din spatele ei și mulțumește-i pentru interes. Este un mare compliment! @@ -269,7 +269,7 @@ Dacă adaugi teste, asigură-te că explici cum funcționează în fișierul tă-— @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)
diff --git a/_articles/ru/best-practices.md b/_articles/ru/best-practices.md index 111bf483312..e4020ce33f0 100644 --- a/_articles/ru/best-practices.md +++ b/_articles/ru/best-practices.md @@ -105,7 +105,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). Кроме того, игнорирование вкладов оказывает отрицательное воздействие на ваше сообщество. Участие в проекте может быть пугающим, особенно в первый раз. Даже если вы не собираетесь принимать вклад, поблагодарите его автора за проявленный интерес. Это большой комплимент! @@ -223,7 +223,7 @@ related:
Я считаю, что тесты необходимы для всего кода, над которым работают люди. Если бы код был полностью и совершенно правильным, он не нуждался бы в изменениях — мы пишем код только тогда, когда с ним что-то не так, например, обнаружен баг или отсутствует нереализованная функциональность. И независимо от того, какие изменения вы вносите, тесты необходимы для выявления любых регрессий, которые вы можете случайно допустить.
-- @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)
diff --git a/_articles/sa/best-practices.md b/_articles/sa/best-practices.md index 725c0304b3f..113165a5b9f 100644 --- a/_articles/sa/best-practices.md +++ b/_articles/sa/best-practices.md @@ -103,7 +103,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)। द्वितीयतः, योगदानं उपेक्षितं समुदायाय नकारात्मकं संदेशं प्रेषयति। परियोजनायाम् योगदानं भयजनकं, विशेषतः प्रथमवारं यदि योगदानकर्तृ अस्ति। अपि यदि न स्वीक्रियते, तस्य प्रयासं मानयतु च आभारं कथयतु। महत् प्रशंसा। diff --git a/_articles/sw/best-practices.md b/_articles/sw/best-practices.md index 9f7edabfc72..a0600ceaddc 100644 --- a/_articles/sw/best-practices.md +++ b/_articles/sw/best-practices.md @@ -105,7 +105,7 @@ Ikiwa unapokea mchango usiotaka kukubali, majibu yako ya kwanza yanaweza kuwa ku Usiache mchango usiotakikana wazi kwa sababu unajisikia hatia au unataka kuwa wa huruma. Kadri muda unavyopita, masuala yako na PRs zisizojibiwa zitafanya kufanya kazi kwenye mradi wako kuwa ngumu zaidi na ya kutisha. -Ni bora kufunga mara moja michango unayojua hutaki kukubali. Ikiwa mradi wako tayari unakabiliwa na msongamano mkubwa, @steveklabnik ana mapendekezo ya [jinsi ya kupangilia masuala kwa ufanisi](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). +Ni bora kufunga mara moja michango unayojua hutaki kukubali. Ikiwa mradi wako tayari unakabiliwa na msongamano mkubwa, @steveklabnik ana mapendekezo ya [jinsi ya kupangilia masuala kwa ufanisi](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener). Pili, kupuuza michango kunaonyesha ishara mbaya kwa jamii yako. Kuchangia kwenye mradi kunaweza kutisha, hasa ikiwa ni mara ya kwanza ya mtu. Hata kama hutaki kukubali mchango wao, tambua mtu anayehusika na kuwashukuru kwa nia yao. Ni sifa kubwa! @@ -223,7 +223,7 @@ Ukiongeza majaribio, hakikisha umeeleza jinsi yanavyofanya kazi katika faili yak
Ninaamini kuwa majaribio ni muhimu kwa msimbo zote ambazo watu hufanya kazi. Ikiwa msimbo ulikuwa sahihi kabisa, hautahitaji mabadiliko - tunaandika tu msimbo wakati kuna kitu kibaya, iwe "Inaacha kufanya kazi" au "Haina kipengele fulani-na-vile". Na bila kujali mabadiliko unayofanya, majaribio ni muhimu ili kupata matatizo zozote ambazo unaweza kuanzisha kimakosa.
-— @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)
diff --git a/_articles/ta/best-practices.md b/_articles/ta/best-practices.md index c41c8e01805..da08caa97b6 100644 --- a/_articles/ta/best-practices.md +++ b/_articles/ta/best-practices.md @@ -105,7 +105,7 @@ related: நீங்கள் தேவையற்ற பங்களிப்பை மூடுவதற்காக வருத்தம் கொள்ள தேவையில்லை. காலப்போக்கில், உங்கள் திட்டத்தில் பதிலளிக்கப்படாத இடுவுகள் மற்றும் இழு கோரிக்கைகள் மனஅழுத்தத்தையும், அச்சுறுத்தலையும் அதிகரிக்கிறது. -நீங்கள் ஏற்க விரும்பாத பங்களிப்புகளை உடனடியாக மூடிவிடுதல் நல்லது. உங்கள் திட்டத்தில் ஏற்கனவே வேலைகள் நிறைய இருந்தால், [திறம்பட சிக்கல்களை எவ்வாறு தீர்க்க முடியும்](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) @steveklabnik சொல்லும் சில பரிந்துரைகள். இரண்டாவதாக, பங்களிப்புகளை புறக்கணிப்பது உங்கள் சமூகத்திற்கு ஒரு எதிர்மறை சமிக்ஞையை அனுப்புகிறது. ஒரு திட்டத்திற்கு பங்களிப்பது அச்சுறுத்தலாக இருக்கலாம், குறிப்பாக ஒருவரின் முதல் முறை. நீங்கள் அவர்களின் பங்களிப்பை ஏற்றுக் கொள்ளாவிட்டாலும், அதன் பின்னால் உள்ள நபரிடம் ஒப்புக்கொள்வதோடு, அவர்களின் ஆர்வத்திற்கு நன்றி தெரிவிக்கவும். இது ஒரு பெரிய பாராட்டு! @@ -221,7 +221,7 @@ related:
மக்கள் வேலை செய்யும் அனைத்து குறியீட்டிற்கும் சோதனைகள் தேவை என்று நான் நம்புகிறேன். குறியீடு முழுமையாக மற்றும் செய்தபின் சரியானதாக இருந்தால், அதில் மாற்றங்கள் தேவையில்லை - ஏதாவது தவறு ஏற்பட்டால், அது "அது செயலிழக்கச் செய்கிறது" அல்லது "இது போன்ற ஒரு அம்சம் இல்லை" என்பதை நாம் மட்டும் குறியீட்டை எழுதலாம். நீங்கள் எடுக்கும் மாற்றங்களைப் பொருட்படுத்தாமல், நீங்கள் தற்செயலாக அறிமுகப்படுத்தக்கூடிய எந்தப் பின்னடைவுகளையும் கையாளுவதற்கு சோதனைகள் அவசியம்.
-— @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)
diff --git a/_articles/tr/best-practices.md b/_articles/tr/best-practices.md index 8f25c0418ff..58e5f48856a 100644 --- a/_articles/tr/best-practices.md +++ b/_articles/tr/best-practices.md @@ -105,7 +105,7 @@ Kabul etmek istemediğiniz bir katkı alırsanız, ilk tepkiniz bunu görmezden Kendinizi suçlu hissettiğiniz için veya iyi davranmak istediğiniz için, istenmeyen bir katkıyı açık bırakmayın. Zaman içinde, cevaplanmayan sorunlar ve birleştirme istekleri projeniz üzerinde çalışmayı çok daha stresli ve korkutucu hissettirecektir. -Kabul etmek istemediğinizi bildiğiniz katkıları derhal kapatmak daha iyidir. Projeniz zaten büyük bir birikimden etkilenmişse, @steveklabnik, [sorunların verimli bir şekilde nasıl sıralanacağı](https://words.steveklabnik.com/how-to-be-an-open-source-gardener) konusunda verdiği önerilere bakabilirsiniz. +Kabul etmek istemediğinizi bildiğiniz katkıları derhal kapatmak daha iyidir. Projeniz zaten büyük bir birikimden etkilenmişse, @steveklabnik, [sorunların verimli bir şekilde nasıl sıralanacağı](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener) konusunda verdiği önerilere bakabilirsiniz. İkincisi, katkıları görmezden gelmek, topluluğunuz için olumsuz bir sinyal gönderir. Bir projeye katkıda bulunmak, özellikle birinin ilk defa olması durumunda korkutucu olabilir. Katkısını kabul etmeseniz bile, arkasındaki kişiyi kabul edin ve ilgileri için teşekkür ederiz. Onlar için bu büyük bir iltifat olur! @@ -223,7 +223,7 @@ Testler eklerseniz, CONTRIBUTING dosyanızda nasıl çalıştıklarını açıkl
İnsanların üzerinde çalıştığı tüm kodlar için testlerin gerekli olduğuna inanıyorum. Kod tamamen ve tamamen doğru olsaydı, değişikliğe ihtiyaç duymazdı - değişikliklerin yapılması gerektiğine - yalnızca bir şey yanlış olduğunda, "Çöktüğünde" ya da "Böyle ve böyle bir özellikten yoksun" olduğunda kod yazarız. Yaptığınız değişikliklerden bağımsız olarak, testler yanlışlıkla verebileceğiniz herhangi bir zararı yakalamak için gereklidir.
-— @edunham, ["Rust'un Topluluk Otomasyonu"](https://edunham.net/2016/09/27/rust_s_community_automation.html) +— @edunham, ["Rust'un Topluluk Otomasyonu"](https://web.archive.org/web/20260216092149/https://edunham.net/2016/09/27/rust_s_community_automation.html)
diff --git a/_articles/zh-hans/best-practices.md b/_articles/zh-hans/best-practices.md index edc4b09aa07..12e6a882c54 100644 --- a/_articles/zh-hans/best-practices.md +++ b/_articles/zh-hans/best-practices.md @@ -102,7 +102,7 @@ redirect_from: /zh-cn/best-practices/ 别因为自己感到内疚或者想做一个好人就把你不想接受的贡献继续保留。随着时间的流逝，这些你没有回答的 issue 和 PR 会让你觉得很不爽。 -更好的方式是马上关掉你不想接受的贡献。 如果你的项目已经积压大量的问题，@steveklabnik 可以给你点儿建议，[如何高效的解决 issue](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)。 +更好的方式是马上关掉你不想接受的贡献。 如果你的项目已经积压大量的问题，@steveklabnik 可以给你点儿建议，[如何高效的解决 issue](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener)。 第二点，忽略别人的贡献等于是在社区传递了一个负面的信号。让人感觉提交一个贡献是蛮恐惧的事情，尤其是对于刚加入的新手来说。即使你不接受他们的贡献，告诉他们为什么然后致谢。这会让人觉得更舒服。 @@ -217,7 +217,7 @@ fork 一个项目不什么坏事情。能复制并且修改别人的代码是开
我相信测试对所有的代码都是需要的。如果代码被完整的覆盖了测试，以后就不需要改了。我们只需要在代码崩溃或者需要某个功能的添加代码。不管你在修改什么，测试对于检查那些你可能不小心制造的问题都是必须的。
-— @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)
diff --git a/_articles/zh-hant/best-practices.md b/_articles/zh-hant/best-practices.md index 91d348b7545..58cf1d85a52 100644 --- a/_articles/zh-hant/best-practices.md +++ b/_articles/zh-hant/best-practices.md @@ -102,7 +102,7 @@ redirect_from: /zh-tw/best-practices/ 別因爲自己感到內疚或者想做一個好人就把你不想接受的貢獻繼續保留。隨著時間的流逝，這些你沒有回答的issue和PR會讓你覺得很不爽。 -更好的方式是馬上關掉你不想接受的貢獻。如果你的專案已經飽受積壓的issue的折磨，@steveklabnik 可以給你點建議，[如何高效率的解決issue](https://words.steveklabnik.com/how-to-be-an-open-source-gardener)。 +更好的方式是馬上關掉你不想接受的貢獻。如果你的專案已經飽受積壓的issue的折磨，@steveklabnik 可以給你點建議，[如何高效率的解決issue](https://web.archive.org/web/20241208014624/https://steveklabnik.com/writing/how-to-be-an-open-source-gardener)。 第二點，忽略別人的貢獻等於是在社群傳遞了一個負面的信號。讓人感覺提交一個貢獻是蠻恐懼的事情，尤其是對於剛加入的新手來說。即使你不接受他們的貢獻，告訴他們爲什麼然後致謝。這會讓人覺得更舒服。 @@ -217,7 +217,7 @@ fork一個專案不什麼壞事情。能複製並且修改別人的程式是開
我相信測試對所有的程式都是需要的。如果程式被完整的覆蓋了測試，以後就不需要改了。我們只需要在程式崩潰或者需要某個功能的添加程式。不管你在修改什麼，測試對於檢查那些你可能不小心製造的問題都是必須的。
-— @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)