From 8912233ef973ac07f43cd705cea262e85132bc09 Mon Sep 17 00:00:00 2001 From: BlueButterflies Date: Wed, 3 Apr 2024 10:36:35 +0200 Subject: [PATCH] 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). -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

-Понякога, когато кажете „не“, вашият потенциален сътрудник може да се разстрои или да критикува решението ви. Ако поведението им стане враждебно, [вземете мерки за обезвреждане на ситуацията](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 @@ -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 -Повечето сътрудници с отворен код са „случайни сътрудници“: хора, които допринасят за проект само от време на време. Случаен сътрудник може да няма време да се запознае напълно с вашия проект, така че вашата работа е да го улесните да допринася. +Повечето сътрудници с отворен код са "случайни сътрудници": хора, които допринасят за проект само от време на време. Случаен сътрудник може да няма време да се запознае напълно с вашия проект, така че вашата работа е да го улесните да допринася. Насърчаването на други сътрудници е инвестиция и във вас самите. Когато дадете възможност на най-големите си фенове да работят с работата, която ги вълнува, има по-малко натиск да правите всичко сами. @@ -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), а не на консенсуса . -При процес на търсене на консенсус членовете на общността обсъждат основните опасения, докато не почувстват, че са били адекватно изслушани. Когато останат само второстепенни грижи, общността върви напред. „Търсене на консенсус“ признава, че една общност може да не е в състояние да достигне до перфектен отговор. Вместо това дава приоритет на слушането и дискусията. +При процес на търсене на консенсус членовете на общността обсъждат основните опасения, докато не почувстват, че са били адекватно изслушани. Когато останат само второстепенни грижи, общността върви напред. "Търсене на консенсус" признава, че една общност може да не е в състояние да достигне до перфектен отговор. Вместо това дава приоритет на слушането и дискусията.