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