diff --git a/_articles/bg/best-practices.md b/_articles/bg/best-practices.md new file mode 100644 index 00000000000..c94d9ef9a36 --- /dev/null +++ b/_articles/bg/best-practices.md @@ -0,0 +1,275 @@ +--- +lang: bg +title: Добри практики за поддържащи кода. +description: Улесняване на живота ви като поддържащ отворен код, от процеса на документиране до извличане на максимума от общността. +class: best-practices +order: 5 +image: /assets/images/cards/best-practices.png +related: + - metrics + - leadership +--- + +## Какво означава да си поддържащ код? + +Ако вашата работа е да поддържате проект с отворен код, който много хора използват, вероятно сте забелязали, че прекарвате повече време в отговаряне на въпроси, отколкото в програмиране. + +В ранните етапи на проекта прекарвате време в експериментиране с нови идеи и вземане на решения въз основа на това, което харесвате. С нарастването на популярността на проекта ви ще се окажете в ситуация, в която ще работите с вашите потребители и сътрудници все повече и повече. + +Поддържането на проект изисква повече от просто код. Тези задачи обикновено не се вземат предвид, но са също толкова важни за разрастващ се проект. Събрахме няколко идеи, които ще улеснят живота ви, от процеса на документиране до извличането на максимума от общността. + +## Документиране на вашите процеси + +Отбелязването на процедурите е една от най-добрите практики, които можете да направите като поддържащ код. + +Документирането не само изяснява вашето мислене, но също така помага на другите да разберат от какво се нуждаете или очаквате, без дори да се налага да питате. + +Като вземете под внимание процесите, ви е по-лесно да кажете "не", когато нечие предложение не отговаря на вашия контекст. Така Освен това улеснява други хора да се присъединят и да помогнат. Никога не знаете кой може да чете или използва вашия проект. + +Дори и да не сте от хората, които пишат цели параграфи, записването на ключови моменти е по-добро от никакви. + +### Изясняване на визията на вашия проект + +Започнете, като напишете целите на вашия проект. Добавете ги към вашия файл README или създайте отделен файл, наречен VISION. Ако има други артефакти, които могат да помогнат, като например карта на проект, направете и тях публични. + +Наличието на ясна документирана визия ви държи фокусирани и помага да избегнете неразбиране на обхвата от други сътрудници. + +Например: +@lord откри фактът, че наличието на визия за проект му помогна да разбере кои заявки да даде приоритет. Като начинаещ поддържащ код, той се оплака че не е бил верен на обхвата на проекта, когато е получил първата ви заявка за функционалност [Slate](https://github.com/lord/slate). + + + +### Съобщете вашите очаквания + +Понякога може да е трудно да се формулират правилата, така че други хора да могат да допринесат. Може да почувствате, че се държите като ченге или разваляте забавлението на другите. + +Въпреки това, написани и приложени справедливо, добрите правила дават възможност на поддържащите кода. Те ви предпазват от това да бъдете въвлечени в неща, които не искате да правите. + +Повечето хора, които срещат вашия проект, не знаят нищо за вас или вашите обстоятелства. Те може да приемат, че ви е платено да работите по него, особено ако това е нещо, което те използват и от което зависят редовно. Може би някога сте отделяли много време за проекта си, но сега сте заети с нова работа или член на семейството. + +Всичко е наред! Просто се уверете, че хората знаят. + +Независимо дали поддържането на вашия проект е на непълно работно време или просто доброволно, бъдете честни за това колко време имате. Това не е същото като колко време мислите, че ще отнеме проектът или колко време другите искат да отделите. + +Ето някои правила, които си струва да имате предвид: + +* Как се преглежда и приема принос (_Трябва ли да направите някои тестове? Някакви шаблони, които да използвате за проблеми?_) +* Типовете приноси, които ще приемете (_Искате ли помощ само за част от кода?_) +* Кога е уместно да се проследи (_напр. "Можете да очаквате отговор от поддържащия код в рамките на следващите 7 дни. Ако не сте чули нищо дотогава, не се колебайте да изпратите ping на нишката."_) +*Колко време посвещавате на проекта (_напр. "Ние инвестираме само около 5 часа на седмица в този проект"_) + +[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), и [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) това са някои примери за проекти с ясни правила за поддържащи и сътрудници. + +### Поддържайте публична комуникация + +Не забравяйте да документирате и вашите взаимодействия. Където можете, поддържайте публична комуникация относно вашия проект. Ако някой се опита да се свърже с вас лично, за да обсъдите заявка за функция или нужда от поддръжка, учтиво го насочете към обществен канал за комуникация, като списък с имейли или инструмент за проследяване на проблеми. + +Ако се срещнете с други поддържащи или вземете важни решения насаме, документирайте тези разговори публично, дори ако просто публикувате бележките си. + +По този начин всеки, който се присъедини към вашата общност, ще има достъп до същата информация като някой, който е бил там. От години. + +## Научете се да казвате не + +Написахте нещата. В идеалния случай всеки ще прочете вашата документация, но в действителност ще трябва да напомняте на другите, че това знание съществува. + +Наличието на всичко написано обаче помага да се обезличат ситуациите, в които е необходимо да се налагат правилата. + +Да кажете "не" не е забавно, но _"Вашият принос не отговаря на критериите за този проект"_ изглежда по-малко лично от _"Не харесвам приноса ви"_. + +Казването "не" се отнася за много ситуации, които ще срещнете като поддържащ код: заявки за функции, които са извън обхвата, някой дерайлира дискусия, върши ненужна работа за други. + +### Поддържайте разговора приятелски + +Едно от най-важните места, където ще практикувате да казвате "не", е в опашката за издаване и изтегляне на заявки. Като ръководител на проекти вие неизбежно ще получите предложения, които не искате да приемете. + +Може би приносът променя обхвата на вашия проект или не отговаря на вашата визия. Може би идеята е добра, но изпълнението е ужасно. + +Независимо от причината, можете тактично да се справите с приноси, които не отговарят на стандартите на проекта. + +Ако получите изпращане, което не искате да приемете, първата ви реакция може да бъде да го игнорирате или да се престорите, че не сте го видели. Това може да нарани чувствата на другия човек и дори да обезкуражи други потенциални сътрудници във вашата общност. + + + +Не оставяйте отворен нежелан принос, защото се чувствате виновни или искате да сте мили. С течение на времето вашите въпроси без отговор и PR ще станат излишни. Това ще направи работата по вашия проект много по-стресираща и смущаваща. + +Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за [как да избирате ефективно въпроси](https://words.steveklabnik.com/how-to-be-an-open-source-gardener). + +Второ, игнорирането на приносите изпраща отрицателен сигнал към вашата общност. Приносът към проект може да бъде смущаващ, особено ако на някого е за първи път. Дори и да не приемете техния принос, поздравете човека зад него и му благодарете за проявения интерес. Това е страхотен комплимент! + +Ако не желаете да приемете дарение: + +* **Благодаря им** за техния принос. +* **Обясни защо не отговаря** на обхвата на проекта и предлага ясни предложения за подобрение, ако е възможно. Знам мил, но твърд. +* **Споделете подходяща информация**, ако я имате. Ако забележите повтарящи се искания за неща, които не искате да приемете, добавете ги към документацията си, за да избегнете винаги да обяснявате едно и също нещо. +* **Затворете заявката** + +Не трябва да имате повече от 1-2 изречения, за да отговорите. Например, когато потребител [celery](https://github.com/celery/celery/) съобщи за грешка, свързана с Windows, @berkerpeksag [той отговори с](https://github.com/celery/celery/issues/3383): + +[celery screenshot](/assets/images/best-practices/celery.png) + +Ако идеята да кажете "не" ви ужасява, не се чувствайте сами. Както @jessfraz [казва](https://blog.jessfraz.com/post/the-art-of-closing/): + +> Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е: да кажеш "Не" на пачове, които не искаш да използваш. + +Не се чувствайте виновни, че не искате да приемете нечий принос. Първото правило на отворения код, [в съответствие със](https://twitter.com/solomonstre/status/715277134978113536) @shykes: _"Не, е временно; да, това е завинаги."_ Докато мъченичеството на ентусиазма на друг човек е добро нещо, отхвърлянето на принос не е същото като отхвърлянето на човека зад него. + +В крайна сметка, ако даден принос не е достатъчно добър, не сте длъжни да го приемете. Знам Бъдете мили и отзивчиви, когато хората допринасят за вашия проект, но приемайте само промени, които наистина вярвате, че ще направят проекта ви по-добър. Колкото по-често се упражнявате да казвате "не", толкова по-лесно става. Това е обещание. + +### Бъди проактивен + +За да намалите първо обема на нежеланите приноси, обяснете процеса на вашия проект за подаване и приемане на приноси в ръководството за приноси. + +Ако получите твърде много подавания с ниско качество, помолете сътрудниците да свършат малко работа предварително, например: + +* Попълнете шаблон или контролен списък за проблеми или PR +*Отворете проблем, преди да изпратите PR + +Ако не спазват вашите правила, незабавно затворете проблема и ги насочете към вашата документация. + +Въпреки че този подход може да изглежда неприятен в началото, проактивността всъщност е добра и за двете страни. Намалете шанса някой да инвестира много часове пропиляна работа върху заявка за изтегляне, която не приемате. И опростява управлението на натоварването. + + + +Понякога, когато кажете "не", вашият потенциален сътрудник може да се ядоса или да критикува решението ви. Ако поведението ви стане враждебно, [вземете мерки за обезвреждане на ситуацията](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) или дори ги отстранете от вашата общност, ако не желаят да си сътрудничат конструктивно. + +### Прегърнете наставничеството + +Може би някой във вашата общност редовно изпраща приноси, които не отговарят на стандартите на вашия проект. Може да бъде разочароващо и за двете страни многократното преминаване през процеса на отхвърляне. + +Ако видите, че някой е Ако сте развълнувани от проекта си, но той се нуждае от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо. техният принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, означен с _"добър първи проблем,"_, за да ги загреете. Ако имате време, помислете за менторство чрез първия си принос или намерете някой друг във вашата общност, който се интересува. готови да ги наставляват. + +##Използване на общността + +Не е нужно да правите всичко сами. Вашата проектна общност съществува с причина! Дори ако все още нямате активна общност от сътрудници, ако имате много потребители, оставете ги да работят. + +### Споделете натоварването + +Ако търсите други да се присъединят, започнете, като разпитате наоколо. + +Когато видите нови сътрудници да правят повторни приноси, трябва да признаете работата им, като им предложите повече отговорности. Документирайте как другите могат да постигнат лидерски роли, ако желаят. + +Насърчаването на други да [споделят собствеността върху проекта](../building-community/#споделете-собствеността-върху-вашия-проект) може значително да намали работното ви натоварване, както установи @lmccart във вашия проект, [p5.js](https://github.com/processing/p5.js). + + + +Ако трябва да се оттеглите от проекта си, независимо дали временно или за постоянно, не е срамно да помолите някой друг да поеме вместо вас. + +Ако други хора са ентусиазирани относно посоката на проекта, дайте им разрешение да се ангажират или официално предайте контрола на някой друг. Ако някой направи разклонение на вашия проект и това е активно поддържане някъде другаде, помислете за свързване на разклонението от вашия оригинален проект. Страхотно е, че толкова много хора искат вашият проект да се развива! + +@progrium [установи, че](https://web.archive.org/web/20151204215958/https://progrium.com/blog/2015/12/04/leadership-guilt-and-pull-requests/) документирайки визията на вашия проект, [Dokku](https://github.com/dokku/dokku), помогне тези цели да продължават, включително и след това, което е останало на проекта: + +> Написах wiki страница, описваща какво искам и защо го искам. По някаква причина бях изненадан от това! Нека поддържащите започнат да движат проекта в тази посока! Случи се? Как точно бихте го направили? Не винаги. Но както и да се приближи, аз реализирах проекта, както исках. + +### Позволете на другите да създават решенията, от които се нуждаят + +Ако потенциален сътрудник има различно мнение за това какво трябва да направи вашият проект, може да се наложи внимателно да го насърчите да работи върху собствената си вилка. + +Разклоняването на проект не е задължително да е лошо нещо. Да можеш да копираш и модифицираш проекти е едно от най-добрите неща на отворения код. Насърчаването на членовете на вашата общност да работят върху своя собствена вилица може да осигури творческия изход, от който се нуждаят, без да противоречи на визията на вашия проект. + + + +Същото важи и за потребител, който наистина иска решение, което вие просто нямате възможност да създадете. Предлагането на адаптивни API и кукички може да помогне на другите да посрещнат собствените си нужди, без да се налага директно да променят източника. +@orta [намери че](https://artsy.github.io/blog/2016/07/03/handling-big-projects/) окуражаващи плъгини за CocoaPods към "някои от по-интересните идеи": + +> Почти неизбежно е след като проектът стане голям, поддържащите трябва да бъдат много по-консервативни по отношение на това как въвеждат нов код. Умеете да казвате "не", но много хора имат законни нужди. Следователно в крайна сметка превръщате инструмента си в платформа. + +## Доведете роботите + +Така Точно както има задачи, с които други хора могат да ви помогнат, има и задачи, които никое човешко същество не трябва да изпълнява. Роботите са ваши приятели. Използвайте ги, за да улесните живота си като поддържащ код. + +### Изисквайте тестване и други проверки, за да подобрите качеството на вашия код + +Един от най-важните начини за автоматизиране на вашия проект е чрез тестване. + +Тестването помага на сътрудниците да се чувстват уверени, че няма да нарушат нищо. Те също така улесняват прегледа и бързото приемане на приноси. Колкото по-възприемчиви сте, толкова по-ангажирани ще бъдете. бъдете вашата общност. + +Настройте автоматични тестове за изпълнение на всички входящи приноси и се уверете, че могат да се изпълняват локално от сътрудниците. Изисква всички приноси на код да преминат през тестване, преди да могат да бъдат изпратени. Ще помогне за установяване на минимален стандарт за качество за всички приложения. +[Необходими са проверки на състоянието](https://help.github.com/articles/about-required-status-checks/) в GitHub може да помогне да се гарантира, че никакви промени не се обединяват, без първо да преминете през тестване. + +Ако добавите тестове, не забравяйте да обясните как работят във вашия CONTRIBUTING файл. + + + +### Използвайте инструменти за автоматизиране на основни задачи по поддръжката + +Добрата новина за поддържането на популярен проект е, че други поддържащи вероятно са се сблъсквали с подобни проблеми и са създали решение за него. + +Има [различни налични инструменти](https://github.com/showcases/tools-for-open-source) за подпомагане на автоматизирането на някои аспекти на работата по поддръжката. Няколко примера: + +* [semantic-release](https://github.com/semantic-release/semantic-release) автоматизирайте вашите версии +* [mention-bot](https://github.com/facebook/mention-bot) споменете възможни рецензенти за заявки за рул +* [Danger](https://github.com/danger/danger) помага за автоматизиране на прегледа на кода + +За доклади за грешки и други общи приноси GitHub има [Шаблони за проблеми и заявки за изтегляне](https://github.com/blog/2111-issue-and-pull-request-templates), които можете да създадете, за да рационализирате комуникацията, която получавате. Можете също да конфигурирате [имейл филтри](https://github.com/blog/2203-email-updates-about-your-own-activity)за управление на вашите имейл известия. + +Ако искате да станете малко по-напреднали, ръководствата за стил могат да стандартизират приноса към проекта и да ги направят по-лесни за преглед и приемане. + +Въпреки това, ако вашите стандарти са твърде сложни, те могат да увеличат бариерите пред приноса. Уверете се, че добавяте само правила, за да улесните живота на всички. + +Ако не сте сигурни какво инструменти, които да използвате, вижте какво правят други популярни проекти, особено тези във вашата екосистема. Например какво Как изглежда процесът на принос за други модули на Node? Използването на подобни инструменти и подходи също ще улесни. Направете своя процес по-познат на вашите целеви сътрудници. + +## То е добре пауза + +Работата с отворен код някога ви е носила радост. Може би сега е така започват да ви карат да се чувствате отбягващи или виновни. + +Може би се чувствате претоварени или нарастващо чувство на страх, когато мислите за вашите проекти. И междувременно се натрупват проблеми и заявки за изтегляне. + +Прегарянето е реален и всеобхватен проблем в работата с отворен код, особено сред поддържащите. Като поддържащ, вашето щастие е неподлежащо на обсъждане изискване за оцеляването на всеки проект с отворен код. + +Въпреки че трябва да се разбира от само себе си, вземете си почивка! Не трябва да чакате, докато се почувствате изморени, за да си вземете почивка. @brettcannon, разработчик на Python, реши да вземете [едномесечна ваканция](http://www.snarky.ca/why-i-took-october-off-from-oss-volunteering) след 14 години OSS доброволчество. + +Като всеки друг вид работа, редовните почивки ще ви поддържат мотивирани. свежи, щастливи и развълнувани от работата си. + + + +Понякога може да е трудно да си вземете почивка от работата с отворен код, когато чувствате, че целият свят има нужда от вас. Хората може дори да се опитат да ви накарат да се чувствате виновни, че сте се отдалечили. + +Направете всичко възможно, за да намерите поддръжка за вашите потребители и общност, докато сте далеч от даден проект. Ако не можете да намерите подкрепата, от която се нуждаете, все пак си направете почивка. Не забравяйте да общувате, когато не сте на разположение, така че хората да не се чувстват объркани от липсата ви на отзивчивост. + +Правенето на почивки се отнася и за нещо повече от ваканции. Ако не искате да работите с отворен код през почивните дни или по време на работното време, съобщете тези решения на другите, за да знаят, че няма да ви притесняват. + +## Погрижете се първо за себе си! + +Поддържането на популярен проект изисква различни умения от ранните етапи на растеж, но е не по-малко възнаграждаващо. Като поддържащ, вие ще практикувате лидерски умения и умения за хора на ниво, което малко хора могат да изпитат. Въпреки че не винаги е лесно да се управлява, поставянето на ясни граници и вземането само на това, което ви кара да се чувствате комфортно, ще ви помогне. за да сте щастливи, актуализирани и продуктивни. diff --git a/_articles/bg/building-community.md b/_articles/bg/building-community.md new file mode 100644 index 00000000000..2d3ffd75b20 --- /dev/null +++ b/_articles/bg/building-community.md @@ -0,0 +1,276 @@ +--- +lang: bg +title: Изграждане на приветливи общности +description: Изграждане на общност, която насърчава хората да използват, допринасят и образоват с вашия проект +class: building +order: 4 +image: /assets/images/cards/building.png +related: + - best-practices + - coc +--- + +## Настройване на вашия проект за успех + +Току-що стартирахте проекта си, разпространявате информацията и хората го следват. Брилянтно! Сега, как да ги накараш да останат? + +Гостоприемната общност е инвестиция в бъдещето на вашия проект и вашата репутация. Ако вашият проект едва започва да вижда първите си приноси, започнете, като дадете положителен опит на първите сътрудници и ги улеснете да се връщат отново. + +### Накарайте хората да се чувстват добре дошли + +Един от начините да мислите за общността на вашия проект е чрез това, което @MikeMcQuaid нарича [фуния на сътрудниците](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/): + +![Фуния на сътрудник](/assets/images/building-community/contributor_funnel_mikemcquaid.png) + +Докато изграждате общността си, помислете как някой на върха на фунията (потенциален потребител) може теоретично да си проправи път надолу (активен поддържащ). Вашата цел е да намалите триенето на всеки етап от опита на сътрудници. Когато хората имат лесни победи, те ще бъдат стимулирани да правят повече. + +Започнете с вашата документация: + +* **Направете го лесен за тези, които трябва да използват проекта.** [Приятелски документ README](../starting-a-project/#напишете-readme) и ясни примери за код ще улеснят използването му .Това е лесно начало за всеки, който попадне на вашия проект. +* **Ясно обяснете как да допринесете**, като използвате [файл за CONTRIBUTING](../starting-a-project/#напишете-вашите-указания-за-принос) и поддържате проблемите си актуални. +* **Добри първи издания**: За да помогнете на новите сътрудници да започнат, мислете ясно за [подчертаване на теми, които са достатъчно прости, за да се справи начинаещият](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). След това GitHub ще покаже тези проблеми на различни места в платформата, увеличавайки полезните приноси и намалявайки напрежението от потребителите, които се справят с проблеми, които са твърде трудни за тяхното ниво. + +[Проучване на GitHub за отворен код от 2017 г](http://opensourcesurvey.org/2017/) показа, че непълната или объркваща документация е най-големият проблем за потребителите с отворен код. Добрата документация приканва хората да взаимодействат с вашия проект. В крайна сметка някой ще отвори проблем или заявка. Използвайте тези взаимодействия като възможности да ги преместите надолу по фунията. + +* **Когато някой нов се присъедини към вашия проект, благодарете му за проявения интерес!** Необходим е само един негативен опит, за да накара някой да не иска да се върне. +* **Бъдете отзивчиви.** Ако не отговорите на въпроса им в продължение на един месец, има вероятност те вече да са забравили за вашия проект. +* **Бъдете непредубедени относно видовете приноси, които ще приемете.** Много сътрудници започват с докладване на грешка или извършване на малка корекция. Има [много начини да допринесете](../how-to-contribute/#какво-означава-да-допринасяш) към проект. Позволете на хората да помагат по начина, по който искат да помогнат. +* **Ако има принос, с който не сте съгласни,** им благодарете за тяхната идея и [обяснете защо](../best-practices/#научете-се-да-казвате-не) не отговаря на обхвата на проекта , с връзка към съответната документация, ако я имате. + + + +Повечето сътрудници с отворен код са "случайни сътрудници": хора, които допринасят за проект само от време на време. Случаен сътрудник може да няма време да се запознае напълно с вашия проект, така че вашата работа е да го улесните да допринася. + +Насърчаването на други сътрудници е инвестиция и във вас самите. Когато дадете възможност на най-големите си фенове да работят с работата, която ги вълнува, има по-малко натиск да правите всичко сами. + +### Документирайте всичко + + + +Когато започвате нов проект, може да ви се стори естествено да запазите работата си в тайна. Но проектите с отворен код процъфтяват, когато документирате процеса си публично. + +Когато документирате нещата, повече хора могат да бъдат включени във всяка стъпка от процеса. Може да получите помощ за нещо, от което дори не сте подозирали, че имате нужда. + +Записването на неща означава повече от просто техническа документация. Всеки път, когато почувствате нужда да напишете нещо или да обсъдите работата си насаме, запитайте се дали можете да я направите публично достояние. + +Бъдете прозрачни относно пътната карта на вашия проект, типовете приноси, които търсите, как се разглеждат приносите или защо сте взели определени решения. + +Ако забележите, че много потребители имат същия проблем, моля, документирайте отговорите в README. + +За срещи помислете за публикуване на вашите бележки или изводи в свързана тема. Обратната връзка, която ще получите от това ниво на прозрачност, може да ви изненада. + +Документирането на всичко се отнася и за работата, която вършите. Ако работите върху голяма актуализация на вашия проект, поставете го в заявка за изтегляне и го маркирайте като работа в процес (WIP). По този начин други хора могат да се почувстват ангажирани в процеса на ранен етап. + +### Бъдете отзивчиви + +Докато [популяризирате своя проект](../finding-users), хората ще имат обратна връзка за вас. Те може да имат въпроси за това как работят нещата или да се нуждаят от помощ, за да започнат. + +Опитайте се да бъдете отзивчиви, когато някой подаде проблем, изпрати заявка за изтегляне или зададе въпрос относно вашия проект. Когато отговаряте бързо, хората ще се почувстват като част от диалог и ще бъдат по-ентусиазирани да участват. + +Дори и да не можете да прегледате заявката незабавно, потвърждаването й на ранен етап помага да се увеличи ангажираността. Ето как @tdreyno отговори на заявка за изтегляне на [Middleman](https://github.com/middleman/middleman/pull/1466): + +![Middleman заявка за изтегляне](/assets/images/building-community/middleman_pr.png) + +[Това установи проучване на Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) сътрудниците, които са получили прегледи на кода в рамките на 48 часа, са имали много по-висок процент на възвръщаемост и повторен принос. + +Дискусиите относно вашия проект може също да се случват другаде в мрежата, като Stack Overflow, Twitter или Reddit. Можете да настроите известия на някои от тези места, така че да получавате известия, когато някой спомене вашия проект. + +### Дайте на вашата общност място за събиране + +Има две причини да дадете на вашата общност място за събиране. + +Първата причина е за тях. Помогнете на хората да се опознаят. Хората с общи интереси неизбежно ще искат място, където да говорят за това. А когато комуникацията е публична и достъпна, всеки може да чете минали архиви, за да се запознае и да участва. + +Втората причина е за вас. Ако не дадете на хората обществено място да говорят за вашия проект, те вероятно ще се свържат директно с вас. В началото може да изглежда достатъчно лесно да отговаряте на лични съобщения "само този път". Но с течение на времето, особено ако проектът ви стане популярен, ще се почувствате изтощени. Устояйте на изкушението да общувате с хората относно вашия проект насаме. Вместо това ги насочете към определен обществен канал. + +Публичната комуникация може да бъде толкова проста, колкото да насочите хората да отворят проблем, вместо да ви изпращат имейл директно или да коментират в блога ви. Можете също така да настроите пощенски списък или да създадете акаунт в Twitter, Slack или IRC канал, за да могат хората да говорят за вашия проект. Или опитайте всичко по-горе! + +[Kubernetes kops](https://github.com/kubernetes/kops#getting-involved) отделя работни часове през седмица, за да помогне на членовете на общността: + +> Kops също така отделя време всяка седмица, за да предлага помощ и насоки на общността. Поддържащите Kops се съгласиха да отделят време, специално посветено на работа с новодошлите, подпомагане с PR и обсъждане на нови функции. + +Забележителни изключения от публичната комуникация са: 1) проблеми със сигурността и 2) чувствителни нарушения на кодекса за поведение. Винаги трябва да имате начин хората да докладват тези проблеми лично. Ако не искате да използвате личния си имейл, настройте специален имейл адрес. + +## Разрастване на вашата общност + +Общностите са изключително силни. Тази сила може да бъде благословия или проклятие, в зависимост от това как я владеете. Тъй като общността на вашия проект расте, има начини да му помогнете да се превърне в сила на изграждане, а не на разрушение. + +### Не толерирайте лоши актьори + +Всеки популярен проект неизбежно ще привлече хора, които вредят, а не помагат на вашата общност. Те могат да започнат ненужни дебати, да се карат за тривиални характеристики или да тормозят другите. + +Направете всичко възможно да приемете политика на нулева толерантност към този тип хора. Ако не бъдат отметнати, негативните хора ще накарат другите хора във вашата общност да се чувстват неудобно. Може дори да си тръгнат. + + + +Редовните дискусии за тривиални аспекти на вашия проект разсейват другите, включително вас, от фокусирането върху важни задачи. Нови хора, които пристигат във вашия проект, може да видят тези разговори и да не искат да участват. + +Когато видите, че се появява негативно поведение, направете публично наблюдение за него. Обяснете с приятелски тон защо Такова поведение не е приемливо. Ако проблемът продължава, може да се наложи [да го помолите да напусне](../code-of-conduct/#вашите-отговорности-като-поддържащ). Вашият [кодекс на поведение](../code-of-conduct/) може да бъде конструктивно ръководство за тези разговори. + +### Запознайте се с сътрудниците там, където са + +Добрата документация става все по-важна, когато вашата общност расте. Случайни сътрудници, които иначе може да не са запознати с вашия проект, четат вашата документация, за да получат бързо контекста, от който се нуждаят. + +Във вашия CONTRIBUTING файл кажете изрично на новите сътрудници как да започнат. Може дори да искате да направите специален раздел за тази цел. [Django](https://github.com/django/django), например, има специална целева страница за посрещане на нови сътрудници. + +![Django страница с нови сътрудници](/assets/images/building-community/django_new_contributors.png) + +В опашката си с теми маркирайте грешки, които са подходящи за различни типове сътрудници: например [_"за начинаещи"_](https://kentcdodds.com/blog/first-timers-only), _"добра първа тема"_ или _"документация"_. [Тези маркировки](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) улесняват някой който е нов във вашия проект бързо да сканира вашите теми и първи стъпки. + +И накрая, използвайте вашата документация, за да накарате хората да се чувстват добре дошли на всяка стъпка от процеса. + +Никога няма да взаимодействате с повечето хора, които ще участват във вашия проект. Възможно е да има приноси, които не сте получили, защото някой се е почувствал уплашен или не е знаел откъде да започне. Дори няколко мили думи могат да попречат на някого да напусне проекта ви разочарован. + +Например, ето как [Rubinius](https://github.com/rubinius/rubinius/) започва [неговото допринасящо ръководство](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md): + +> Искаме да започнем, като ви благодарим, че използвате Rubinius. Този проект е труд на любов и ние оценяваме всички потребители, които улавят грешки, правят подобрения на производителността и помагат с документацията. Всеки принос е значим, така че благодарим за участието. Имайки предвид това, ето няколко насоки, които ви молим да следвате, за да можем успешно да се справим с проблема ви. + +### Споделете собствеността върху вашия проект + + + +Хората са развълнувани да допринасят за проекти, когато изпитват чувство за собственост. Това не означава, че трябва да преобърнете визията на вашия проект или да приемете приноси, които не искате. Но колкото повече признавате другите, толкова повече те ще останат наоколо. + +Вижте дали можете да намерите начини да споделите собствеността с вашата общност колкото е възможно повече. Ето няколко идеи: + +* **Отбягвайте коригирането на лесни (некритични) грешки.** Вместо това ги използвайте като възможности за набиране на нови сътрудници или наставничество на някой, който би искал да допринесе. В началото може да изглежда неестествено, но инвестицията ви ще се изплати с времето. Например @michaeljoseph помоли сътрудник да изпрати заявка за изтегляне на проблем с [Cookiecutter](https://github.com/audreyr/cookiecutter) по-долу, вместо да го коригира сам. + +![Cookiecutter issue](/assets/images/building-community/cookiecutter_submit_pr.png) + +* **Стартирайте файл CONTRIBUTORS или AUTHORS във вашия проект**, който изброява всички, които са допринесли за вашия проект, както прави [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md). + +* Ако имате значителна общност, **изпратете бюлетин или напишете публикация в блог**, като благодарите на сътрудниците. [Тази седмица в Rust](https://this-week-in-rust.org/) на Rust и [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) на Hoodie са два добри примера. + +* **Дайте достъп за ангажиране на всеки сътрудник.** @felixge установи, че това кара хората [да бъдат по-развълнувани да усъвършенстват корекциите си](https://felixge.de/2013/03/11/the-pull-request-hack.html) и дори намери нови поддържащи за проекти, по които не е работил от известно време. + +* Ако проектът ви е в GitHub, **преместете проекта си от личния си акаунт в [Организация](https://help.github.com/articles/creating-a-new-organization-account/)** и добавете поне един резервен администратор. Организациите улесняват работата по проекти с външни сътрудници. + +Реалността е, че [повечето проекти имат само](https://peerj.com/preprints/1233/) един или двама поддържащи, които вършат по-голямата част от работата. Колкото по-голям е вашият проект и колкото по-голяма е вашата общност, толкова по-лесно е да намерите помощ. + +Въпреки че не винаги може да намерите някой, който да отговори на обаждането, подаването на сигнал там увеличава шансовете други хора да се включат. И колкото по-рано започнете, толкова по-скоро хората могат да помогнат. + + + +## Разрешаване на конфликти + +В ранните етапи на вашия проект вземането на важни решения е лесно. Когато искаш да направиш нещо, просто го правиш. + +Тъй като вашият проект става по-популярен, повече хора ще се интересуват от решенията, които вземате. Дори и да нямате голяма общност от сътрудници, ако вашият проект има много потребители, ще намерите хора, които преценяват решенията или повдигат свои собствени проблеми. + +В по-голямата си част, ако сте култивирали приятелска, уважителна общност и сте документирали процесите си открито, вашата общност трябва да може да намери решение. Но понякога се натъквате на проблем, който е малко по-труден за разрешаване. + +### Поставете стандарта за учтивост + +Когато вашата общност се бори с труден проблем, настроението може да се надигне. Хората може да се ядосат или разочароват и да си го изкарат един на друг или на вас. + +Вашата работа като поддържащ е да предотвратите ескалацията на тези ситуации. Дори ако имате силно мнение по въпроса, опитайте се да заемете позицията на модератор или фасилитатор, вместо да влизате в битката и да популяризирате своите възгледи. Ако някой е нелюбезен или монополизира разговора, [действайте незабавно](../building-community/#не-толерирайте-лоши-актьори), за да поддържате дискусията цивилизована и продуктивна. + + + +Други хора ви търсят за напътствие. Давайте добър пример. Все още можете да изразите разочарование, нещастие или загриженост, но го направете спокойно. + +Да запазите хладнокръвие не е лесно, но демонстрирането на лидерство подобрява здравето на вашата общност. Интернет ви благодари. + +### Отнасяйте се към вашия README като към конституция + +Вашият README е [повече от просто набор от инструкции](../starting-a-project/#напишете-readme). Това също е място да говорите за вашите цели, продуктова визия и пътна карта. Ако хората са прекалено съсредоточени върху обсъждането на достойнствата на определена функция, може да ви помогне да прегледате отново вашия README и да говорите за по-високата визия на вашия проект. Фокусирането върху вашия README също обезличава разговора, така че можете да водите конструктивна дискусия. + +### Фокусирайте се върху пътуването, а не върху дестинацията + +Някои проекти използват процес на гласуване, за да вземат важни решения. Въпреки че е разумно на пръв поглед, гласуването набляга на достигането до "отговор", а не на изслушване и разглеждане на притесненията на другия. + +Гласуването може да стане политическо, когато членовете на общността се чувстват принудени да си правят услуги или да гласуват по определен начин. Не всеки гласува също, независимо дали е [мълчаливото мнозинство](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) във вашата общност или настоящи потребители, които не са знаели, че се провежда гласуване. + +Понякога е необходим равен вот. Доколкото можете обаче, наблягайте на ["търсенето на консенсус"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making), а не на консенсуса . + +При процес на търсене на консенсус членовете на общността обсъждат основните опасения, докато не почувстват, че са били адекватно изслушани. Когато останат само второстепенни грижи, общността върви напред. "Търсене на консенсус" признава, че една общност може да не е в състояние да достигне до перфектен отговор. Вместо това дава приоритет на слушането и дискусията. + + + +Дори ако всъщност не възприемете процес на търсене на консенсус, като поддържащ проект е важно хората да знаят, че слушате. Да накарате другите хора да се почувстват чути и да се ангажират с разрешаването на притесненията им допринася много за деескалацията на чувствителни ситуации. След това последвайте думите си с действия. + +Не бързайте с решение в името на решението. Уверете се, че всички се чувстват чути и че цялата информация е разпространена, преди да преминете към решение. + +### Поддържайте разговора фокусиран върху действието + +Дискусията е важна, но има разлика между продуктивни и непродуктивни разговори. + +Насърчавайте дискусията, стига да върви активно към разрешаване. Ако е ясно, че разговорът затихва или се отклонява от темата, заяжданията стават лични или хората се бъзикат за незначителни подробности, време е да го затворите. + +Позволяването на тези разговори да продължат е не само лошо за разглеждания проблем, но и за здравето на вашата общност. Изпраща съобщение, че този тип разговори са разрешени или дори насърчавани, и може да обезсърчи хората да повдигат или разрешават бъдещи проблеми. + +С всяка точка, изказана от вас или от други, запитайте се: "Как това ни доближава до решение?"_ + +Ако разговорът започва да се разплита, попитайте групата _"Кои стъпки трябва да предприемем по-нататък?"_, за да пренасочите разговора. + +Ако разговорът очевидно не води до никъде, няма ясни действия, които да бъдат предприети, или подходящото действие вече е предприето, затворете проблема и обяснете защо сте го затворили. + + + +### Подбирайте битките си мъдро + +Важен е контекстът. Помислете кой участва в разговора и как той представлява останалата част от общността. + +Всички в общността разстроени ли са или дори загрижени за това? Или е самотен размирник? Не забравяйте да имате предвид мълчаливите членове на вашата общност, а не само активните гласове. + +Ако проблемът не представлява по-широките нужди на вашата общност, може просто да се наложи да приемете притесненията на някои хора. Ако това е повтарящ се проблем без ясно решение, моля, насочете ги към предишни дискусии по темата и затворете темата. + +### Определете критерий за равновесие на общността + +С добро поведение и ясна комуникация повечето трудни ситуации се разрешават. Въпреки това, дори при продуктивна дискусия, може просто да има разлика в мненията за това как да продължите. В тези случаи идентифицирайте човек или група от хора, които могат да служат като балансьор. + +Нивелирът може да бъде основният поддържащ проекта или може да бъде малка група хора, които вземат решение въз основа на гласуване. В идеалния случай вие сте дефинирали нивелир и свързаната процедура във файл GOVERNANCE, преди да се наложи да го използвате. + +Вашето решение за вратовръзка трябва да е последна мярка. Разделящите въпроси са възможност за вашата общност да расте и да се учи. Прегърнете тези възможности и използвайте процес на сътрудничество, за да преминете към разрешаване, когато е възможно. + +## Общността е ❤️ на отворен код + +Здравите, процъфтяващи общности захранват хилядите часове, вложени в отворен код всяка седмица. Много сътрудници посочват други хора като причина да работят - или да не работят - с отворен код. Като се научите как да се възползвате от тази сила конструктивно, вие ще помогнете на някого да има незабравимо изживяване с отворен код. diff --git a/_articles/bg/code-of-conduct.md b/_articles/bg/code-of-conduct.md new file mode 100644 index 00000000000..22af32a478d --- /dev/null +++ b/_articles/bg/code-of-conduct.md @@ -0,0 +1,114 @@ +--- +lang: bg +title: Вашият кодекс на поведение +description: Улеснявайте здравословното и конструктивно поведение на общността чрез приемане и прилагане на кодекс на поведение. +class: coc +order: 8 +image: /assets/images/cards/coc.png +related: + - building + - leadership +--- + +## Защо имам нужда от кодекс на поведение? + +Кодексът на поведение е документ, който определя очакванията за поведение на участниците във вашия проект. Приемането и прилагането на кодекс на поведение може да помогне за създаването на положителна социална атмосфера за вашата общност. + +Кодексите на поведение помагат да защитите не само вашите участници, но и себе си. Ако поддържате проект, може да откриете, че непродуктивното отношение на другите участници може да ви накара да се почувствате изтощени или нещастни от работата си с течение на времето. + +Кодексът на поведение ви дава възможност да улесните здравословното, конструктивно поведение в общността. Проактивността намалява вероятността вие или другите да се уморите от вашия проект и ви помага да предприемете действия, когато някой направи нещо, с което не сте съгласни. + +## Създаване на кодекс на поведение + +Опитайте се да създадете кодекс на поведение възможно най-рано: в идеалния случай, когато за първи път създавате своя проект. + +В допълнение към съобщаването на вашите очаквания, кодексът на поведение описва следното: + +* Където кодексът на поведение влиза в сила _(само при проблеми и заявки за изтегляне или дейности на общността като събития?)_ +* За кого се прилага кодексът на поведение _(членове на общността и поддържащи лица, но какво да кажем за спонсори?)_ +* Какво се случва, ако някой наруши кодекса на поведение +* Как някой може да докладва за нарушения + +Където можете, използвайте предшестващо състояние на техниката. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от над 40 000 проекта с отворен код, включително Kubernetes, Rails и Swift. + +[Кодексът на поведение на Django](https://www.djangoproject.com/conduct/) и [Кодексът на поведение на гражданите](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) също са два добри примера на кодекс на поведение. + +Поставете файл CODE_OF_CONDUCT в основната директория на вашия проект и го направете видим за вашата общност, като го свържете от вашия CONTRIBUTING или README файл. + +## Решете как ще наложите своя кодекс на поведение + + + +Трябва да обясните как вашият кодекс за поведение ще бъде прилаган **_преди_** нарушение. Има няколко причини да го направите: + +* Демонстрира, че сте сериозни относно предприемането на действия, когато е необходимо. + +* Вашата общност ще се почувства по-уверена, че оплакванията действително се преглеждат. + +* Ще уверите вашата общност, че процесът на преглед е честен и прозрачен, ако някога се окажат разследвани за нарушение. + +Трябва да дадете на хората личен начин (като имейл адрес) да докладват за нарушение на кодекса на поведение и да обясните кой получава този доклад. Това може да бъде поддържащ, група от поддържащи или работна група за кодекс на поведение. + +Не забравяйте, че някой може да поиска да докладва за нарушение на лице, което получава тези доклади. В този случай им дайте възможност да докладват за нарушения на някой друг. Например @ctb и @mr-c [обясняват за техния проект](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer): + +> Случаи на злоупотреба, тормоз или по друг начин неприемливо поведение могат да бъдат докладвани чрез имейл **khmer-project@idyll.org**, който отива само до C. Titus Brown и Michael R. Crusoe. За да съобщите за проблем, свързан с някой от тях, моля, изпратете имейл до **Judi Brown Clarke, Ph.D.** директора по разнообразието в BEACON Center for the Study of Evolution in Action, Център за науки и технологии на NSF.* + +За вдъхновение вижте [ръководството за прилагане](https://www.djangoproject.com/conduct/enforcement-manual/) на Django (въпреки че може да не се нуждаете от нещо толкова изчерпателно, в зависимост от размера на вашия проект). + +## Налагане на вашия кодекс на поведение + +Понякога, въпреки всичките ви усилия, някой ще направи нещо, което нарушава този кодекс. Има няколко начина за справяне с негативното или вредно поведение, когато се появи. + +### Съберете информация за ситуацията + +Отнасяйте се към гласа на всеки член на общността също толкова важен, колкото и вашия собствен. Ако получите доклад, че някой е нарушил кодекса за поведение, приемете го сериозно и проучете въпроса, дори ако не съвпада с вашия собствен опит с този човек. Това сигнализира на вашата общност, че цените тяхната гледна точка и се доверявате на тяхната преценка. + +Въпросният член на общността може да е повторен нарушител, който постоянно кара другите да се чувстват неудобно, или може да е казал или направил нещо само веднъж. И в двата случея могат да бъдат основание за предприемане на действие в зависимост от контекста. + +Преди да отговорите, дайте си време да разберете какво се е случило. Прочетете миналите коментари и разговори на човека, за да разберете по-добре кои са те и защо може да са действали по този начин. Опитайте се да съберете гледни точки, различни от вашата собствена, за този човек и неговото поведение. + + + +### Предприемете подходящи действия + +След като съберете и обработите достатъчно информация, ще трябва да решите какво да правите. Докато обмисляте следващите си стъпки, не забравяйте, че вашата цел като модератор е да насърчите безопасна, уважителна и съвместна среда. Помислете не само как да се справите с въпросната ситуация, но и как вашият отговор ще повлияе на останалата част от поведението и очакванията на вашата общност в бъдеще. + +Когато някой съобщи за нарушение на кодекса на поведение, ваша, а не негова работа е да се справите с него. Понякога репортерът разкрива информация с голям риск за своята кариера, репутация или физическа безопасност. Принуждаването им да се изправят срещу насилника си може да постави репортера в компрометираща позиция. Трябва да поддържате директна комуникация с въпросното лице, освен ако репортерът изрично не поиска друго. + +Има няколко начина, по които можете да реагирате на нарушение на кодекса на поведение: + +* **Дайте публично предупреждение на въпросното лице** и обяснете как поведението му е повлияло негативно на другите, за предпочитане в канала, където се е случило. Когато е възможно, публичната комуникация предава на останалата част от общността, че приемате кодекса за поведение сериозно. Бъдете мили, но твърди в общуването си. + +* **Свържете се лично с въпросното лице**, за да обясните как поведението му е повлияло негативно на другите. Може да искате да използвате личен канал за комуникация, ако ситуацията включва чувствителна лична информация. Ако общувате с някого насаме, добра идея е да изпратите CC на онези, които първи са съобщили за ситуацията, за да знаят, че сте предприели действия. Помолете подалото сигнал лице за съгласие, преди да му изпратите CC. + +Понякога не може да се постигне решение. Въпросното лице може да стане агресивно или враждебно, когато се сблъскаш с него или да не промени поведението си. В тази ситуация може да обмислите предприемането на по-строги действия. Например: + +* **Забрана на въпросното лице** от проекта, наложено чрез временна забрана за участие във всеки аспект на проекта + +* **Забранете за постоянно** лицето от проекта + +Забраната на членове не трябва да се приема с лека ръка и представлява постоянна и непримирима разлика в гледните точки. Трябва да предприемате тези мерки само когато е ясно, че не може да се постигне решение. + +## Вашите отговорности като поддържащ + +Кодексът на поведение не е закон, който се прилага произволно. Вие сте наложителят на кодекса за поведение и е ваша отговорност да следвате правилата, установени от кодекса за поведение. + +Като поддържащ вие установявате насоките за вашата общност и налагате тези насоки в съответствие с правилата, изложени във вашия кодекс за поведение. Това означава да приемате сериозно всеки сигнал за нарушение на кодекса за поведение. На репортера се дължи задълбочено и справедливо разглеждане на жалбата им. Ако установите, че поведението, за което са докладвали, не е нарушение, съобщете им го ясно и обяснете защо няма да предприемете действия по него. Какво ще направят с това зависи от тях: да толерират поведението, с което са имали проблем, или да спрат да участват в общността. + +Докладът за поведение, което _технически_ не нарушава кодекса за поведение, все още може да показва, че има проблем във вашата общност и вие трябва да проучите този потенциален проблем и да действате съответно. Това може да включва преразглеждане на вашия кодекс за поведение, за да се изясни приемливото поведение и/или разговор с лицето, чието поведение е докладвано, и да му кажете, че макар да не е нарушил кодекса за поведение, те заобикалят ръба на очакваното и правят сигурни участниците се чувстват неудобно. + +В крайна сметка, като поддържащ, вие определяте и налагате стандартите за приемливо поведение. Вие имате способността да оформяте ценностите на общността на проекта и участниците очакват от вас да налагате тези ценности по справедлив и равностоен начин. + +## Насърчавайте поведението, което искате да видите в света 🌎 + +Когато даден проект изглежда враждебен или неприветлив, дори ако това е само един човек, чието поведение се толерира от другите, рискувате да загубите много повече сътрудници, някои от които може дори никога да не срещнете. Не винаги е лесно да приемете или наложите кодекс на поведение, но насърчаването на гостоприемна среда ще помогне на вашата общност да расте. diff --git a/_articles/bg/finding-users.md b/_articles/bg/finding-users.md new file mode 100644 index 00000000000..8ea56b9d206 --- /dev/null +++ b/_articles/bg/finding-users.md @@ -0,0 +1,148 @@ +--- +lang: bg +title: Намиране на потребители за вашия проект +description: Помогнете на вашия проект с отворен код да се развие, като го предоставите в ръцете на щастливи потребители. +class: finding +order: 3 +image: /assets/images/cards/finding.png +related: + - beginners + - building +--- + +## Разпространяване на думата + +Няма правило, което да казва, че трябва да рекламирате проект с отворен код, когато стартирате. Има много основателни причини да работите с отворен код, които нямат нищо общо с популярността. Вместо да се надявате, че другите ще намерят и използват вашия проект с отворен код, вие трябва да разпространите думата за вашата упорита работа! + +## Разберете съобщението си + +Преди да започнете действителната работа по популяризиране на вашия проект, трябва да можете да обясните какво прави и защо има значение. + +Какво прави вашия проект различен или интересен? Защо го създадохте? Отговорът на тези въпроси сам ще ви помогне да съобщите значението на вашия проект. + +Не забравяйте, че хората се включват като потребители и в крайна сметка стават сътрудници, защото вашият проект решава проблем вместо тях. Докато мислите за посланието и стойността на вашия проект, опитайте се да ги видите през призмата на това, което _потребителите и сътрудниците_ може да искат. + +Например, @robb използва примери за код, за да съобщи ясно защо неговият проект, [Картография](https://github.com/robb/Cartography), е полезен: + +![Картография README](/assets/images/finding-users/cartography.jpg) + +За по-задълбочено потапяне в съобщенията вижте упражнението на Mozilla ["Личности и пътеки"](https://mozillascience.github.io/working-open-workshop/personas_pathways/) за разработване на потребителски персони. + +## Help people find and follow your project + + + +Помогнете на хората да намерят и запомнят вашия проект, като ги насочите към едно пространство от имена. + +**Имайте ясен манипулатор, за да популяризирате работата си.** Twitter манипулатор, GitHub URL или IRC канал е лесен начин да насочите хората към вашия проект. Тези изходи също дават място за събиране на нарастващата общност на вашия проект. + +Ако все още не желаете да създавате изходи за вашия проект, популяризирайте свой собствен Twitter или GitHub манипулатор във всичко, което правите. Популяризирането на вашия Twitter или GitHub ще позволи на хората да знаят как да се свържат с вас или да следят работата ви. Ако говорите на среща или събитие, уверете се, че вашата информация за контакт е включена във вашата биография или слайдове. + + + +**Помислете за създаване на уебсайт за вашия проект.** Уеб сайтът прави проекта ви по-удобен и лесен за навигация, особено когато е съчетан с ясна документация и уроци. Наличието на уебсайт също предполага, че вашият проект е активен, което ще накара вашата аудитория да се чувства по-комфортно при използването му. Дайте примери, за да дадете на хората идеи как да използват вашия проект. + +[@adrianholovaty](https://news.ycombinator.com/item?id=7531689), съ-създател на Django, каза, че уебсайтът е _"далеч най-доброто нещо, което направихме с Django в ранните дни"_ . + +Ако вашият проект се хоства в GitHub, можете да използвате [GitHub Pages](https://pages.github.com/), за да създадете лесно уебсайт. [Yeoman](http://yeoman.io/), [Vagrant](https://www.vagrantup.com/) и [Middleman](https://middlemanapp.com/) са [няколко примера](https://github.com/showcases/github-pages-examples) от отлични, изчерпателни уебсайтове. + +![Начална страница на Vagrant](/assets/images/finding-users/vagrant_homepage.png) + +Сега, след като имате съобщение за вашия проект и лесен начин за хората да го намерят, нека да излезем и да поговорим с вашата аудитория! + +## Отидете там, където е аудиторията на вашия проект (онлайн) + +Онлайн обхватът е чудесен начин за бързо споделяне и разпространение на информацията. Използвайки онлайн канали, вие имате потенциала да достигнете до много широка аудитория. + +Възползвайте се от съществуващите онлайн общности и платформи, за да достигнете до вашата аудитория. Ако вашият проект с отворен код е софтуерен проект, вероятно можете да намерите аудиторията си в [Stack Overflow](https://stackoverflow.com/), [Reddit](https://www.reddit.com), [Hacker News](https://news.ycombinator.com/) или [Quora](https://www.quora.com/). Намерете каналите, от които смятате, че хората ще имат най-голяма полза или ще бъдат развълнувани от вашата работа. + + + +Вижте дали можете да намерите начини да споделите проекта си по подходящи начини: + +* **Запознайте се с подходящи проекти и общности с отворен код.** Понякога не е нужно директно да рекламирате проекта си. Ако вашият проект е идеален за специалисти по данни, които използват Python, запознайте се с общността за наука за данни на Python. Когато хората ви опознаят, ще се появят естествени възможности да говорите и споделяте работата си. +* **Намерете хора, които се сблъскват с проблема, който вашият проект решава.** Потърсете в свързани форуми за хора, които попадат в целевата аудитория на вашия проект. Отговорете на техния въпрос и намерете тактичен начин, когато е подходящо, да предложите вашия проект като решение. +* **Поискайте обратна връзка.** Представете себе си и работата си на публика, която ще я намери за подходяща и интересна. Бъдете конкретни относно това кой смятате, че ще има полза от вашия проект. Опитайте се да завършите изречението: _"Мисля, че моят проект наистина ще помогне на X, които се опитват да направят Y_". Слушайте и отговаряйте на отзивите на другите, вместо просто да популяризирате работата си. + +Най-общо казано, фокусирайте се върху това да помагате на другите, преди да поискате неща в замяна. Тъй като всеки може лесно да рекламира проект онлайн, ще има много шум. За да се откроите от тълпата, дайте на хората контекст за това кой сте, а не само това, което искате. + +Ако никой не обърне внимание или не отговори на първоначалния ви обхват, не се обезсърчавайте! Повечето стартирания на проекти са итеративен процес, който може да отнеме месеци или години. Ако не получите отговор от първия път, опитайте различна тактика или първо потърсете начини да добавите стойност към работата на другите. Популяризирането и стартирането на вашия проект изисква време и отдаденост. + +## Отидете там, където е аудиторията на вашия проект (офлайн) + +![Публично говорене](/assets/images/finding-users/public_speaking.jpg) + +Офлайн събитията са популярен начин за популяризиране на нови проекти пред публика. Те са чудесен начин да достигнете до ангажирана аудитория и да изградите по-дълбоки човешки връзки, особено ако се интересувате от достигане до разработчици. + +Ако сте [нов в публичното говорене](https://speaking.io/), започнете, като намерите местна среща, която е свързана с езика или екосистемата на вашия проект. + + + +Ако никога преди не сте говорили на събитие, напълно нормално е да се чувствате нервни! Не забравяйте, че публиката ви е там, защото те наистина искат да чуят за работата ви. + +Докато пишете речта си, съсредоточете се върху това, което аудиторията ви ще намери за интересно и от което ще извлече полза. Поддържайте езика си приятелски настроен и достъпен. Усмихвайте се, дишайте и се забавлявайте. + + + +Когато се почувствате готови, обмислете да говорите на конференция, за да популяризирате проекта си. Конференциите могат да ви помогнат да достигнете до повече хора, понякога от цял свят. + +Потърсете конференции, които са специфични за вашия език или екосистема. Преди да изпратите своята реч, проучете конференцията, за да пригодите лекцията си за присъстващите и да увеличите шансовете си да бъдете приети да говорите на конференцията. Често можете да добиете представа за аудиторията си, като погледнете говорителите на конференцията. + + + +## Build a reputation + +В допълнение към стратегиите, описани по-горе, най-добрият начин да поканите хората да споделят и да допринесат за вашия проект е да споделяте и да допринесете за техните проекти. + +Подпомагането на новодошлите, споделянето на ресурси и обмисленият принос към чужди проекти ще ви помогнат да изградите положителна репутация. Това, че сте активен член в общността с отворен код, ще помогне на хората да имат контекст за вашата работа и е по-вероятно да обърнат внимание и да споделят вашия проект. Развитието на връзки с други проекти с отворен код може дори да доведе до официални партньорства. + + + +Никога не е твърде рано или твърде късно да започнете да изграждате репутацията си. Дори ако вече сте стартирали свой собствен проект, продължавайте да търсите начини да помагате на другите. + +Няма еднодневно решение за изграждане на аудитория. Спечелването на доверието и уважението на другите отнема време и изграждането на вашата репутация никога не свършва. + +## Продължавайте! + +Може да отнеме много време, преди хората да забележат вашия проект с отворен код. Това е добре! Някои от най-популярните проекти днес отнеха години, за да достигнат високи нива на активност. Съсредоточете се върху изграждането на взаимоотношения, вместо да се надявате, че вашият проект спонтанно ще спечели популярност. Бъдете търпеливи и продължавайте да споделяте работата си с тези, които я оценяват. diff --git a/_articles/bg/getting-paid.md b/_articles/bg/getting-paid.md new file mode 100644 index 00000000000..d7f074985b8 --- /dev/null +++ b/_articles/bg/getting-paid.md @@ -0,0 +1,178 @@ +--- +lang: bg +title: Получаване на заплащане за работа с отворен код +description: Поддържайте работата си с отворен код, като получите финансова подкрепа за вашето време или за вашия проект. +class: getting-paid +order: 7 +image: /assets/images/cards/getting-paid.png +related: + - best-practices + - leadership +--- + +## Защо някои хора търсят финансова подкрепа + +Голяма част от работата с отворен код е доброволна. Например, някой може да се натъкне на грешка в проект, който използва, и да изпрати бързо решение, или може да му хареса да бърника с проект с отворен код в свободното си време. + + + +Има много причини, поради които човек не би искал да получава заплащане за работата си с отворен код. + +* **Те може вече да имат работа на пълен работен ден, която обичат,** което им позволява да допринасят за отворен код в свободното си време. +* **Харесва им да мислят за отворения код като за хоби** или творческо бягство и не искат да се чувстват финансово задължени да работят по проектите си. +* **Те получават други ползи от приноса си към отворен код,** като например изграждане на репутация или портфолио, усвояване на нови умения или чувство за близост до общност. + + + +За други, особено когато приносът е в ход или изисква значително време, получаването на плащане за принос към отворен код е единственият начин да участват, било защото проектът го изисква, или поради лични причини. + +Поддържането на популярни проекти може да бъде значителна отговорност, като отнема 10 или 20 часа на седмица вместо няколко часа на месец. + + + +Платената работа също дава възможност на хора от различни сфери на живота да дадат значим принос. Някои хора не могат да си позволят да прекарват неплатено време в проекти с отворен код въз основа на текущото си финансово състояние, дълг или семейни или други задължения за грижа. Това означава, че светът никога не вижда приноси от талантливи хора, които не могат да си позволят да отделят доброволно времето си. Това има етични последици, както @ashedryden [описа](https://www.ashedryden.com/blog/the-ethics-of-unpaid-labor-and-the-oss-community), тъй като свършената работа е предубедени в полза на онези, които вече имат предимства в живота, които след това получават допълнителни предимства въз основа на техния доброволен принос, докато други, които не могат да бъдат доброволци, след това не получават по-късни възможности, което засилва текущата липса на разнообразие в отворения код общност. + + + +Ако търсите финансова подкрепа, трябва да обмислите два начина. Можете да финансирате собственото си време като сътрудник или можете да намерите организационно финансиране за проекта. + +## Финансиране на вашето собствено време + +Днес много хора получават заплащане, за да работят на непълен или пълен работен ден с отворен код. Най-често срещаният начин да получите заплащане за времето си е да говорите с вашия работодател. + +По-лесно е да направите аргумент за работа с отворен код, ако вашият работодател действително използва проекта, но бъдете креативни с представянето си. Може би вашият работодател не използва проекта, но той използва Python и поддържането на популярен проект на Python помага за привличането на нови разработчици на Python. Може би това кара вашия работодател да изглежда по-приятелски настроен към разработчиците като цяло. + +Ако нямате съществуващ проект с отворен код, върху който бихте искали да работите, но предпочитате текущата ви работа да е с отворен код, помолете вашия работодател да отвори част от техния вътрешен софтуер. + +Много компании разработват програми с отворен код, за да изградят своята марка и да наемат качествени таланти. + +@hueniverse например установи, че има финансови причини, които да оправдаят [инвестицията на Walmart в отворен код](https://www.infoworld.com/article/2608897/open-source-software/walmart-s-investment-in-open-source-isn-t-cheap.html). И @jamesgpearce установи, че програмата с отворен код на Facebook [има значение](https://opensource.com/business/14/10/head-of-open-source-facebook-oscon) при набирането на персонал: + +> Тя е тясно свързана с нашата хакерска култура и начина, по който нашата организация се възприемаше. Попитахме нашите служители: "Знаехте ли за софтуерната програма с отворен код във Facebook?". Две трети казаха "Да". Половината казаха, че програмата е допринесла положително за решението им да работят за нас. Това не са пределни числа и се надявам, че тенденцията ще продължи. + +Ако вашата компания тръгне по този път, важно е да поддържате ясни границите между общността и корпоративната дейност. В крайна сметка отвореният код се поддържа чрез принос от хора по целия свят и това е по-голямо от която и да е компания или местоположение. + + + +Ако не можете да убедите настоящия си работодател да даде приоритет на работата с отворен код, помислете за намиране на нов работодател, който насърчава приноса на служителите към отворен код. Потърсете компании, които подчертават своята отдаденост на работата с отворен код. Например: + +* Някои компании, като [Netflix](https://netflix.github.io/) или [PayPal](https://paypal.github.io/), имат уебсайтове, които подчертават тяхното участие в отворен код +* [Zalando](https://opensource.zalando.com) публикува своята [политика за принос с отворен код](https://opensource.zalando.com/docs/using/contributing/) за служители + +Проекти, които произхождат от голяма компания, като [Go](https://github.com/golang) или [React](https://github.com/facebook/react), will also likely employ people to work on open source. + +В зависимост от вашите лични обстоятелства можете да опитате да съберете пари независимо, за да финансирате работата си с отворен код. Например: + +* @Homebrew (и [много други поддържащи и организации](https://github.com/sponsors/community)) финансират работата си чрез [Спонсори на GitHub](https://github.com/sponsors) +* @gaearon финансира работата си върху [Redux](https://github.com/reactjs/redux) чрез [кампания за групово финансиране на Patreon](https://redux.js.org/) +* @andrewgodwin финансира работа по миграции на схема на Django [чрез кампания на Kickstarter](https://www.kickstarter.com/projects/andrewgodwin/schema-migrations-for-django) + +И накрая, понякога проекти с отворен код дават премии за проблеми, за които може да обмислите да помогнете. + +* @ConnorChristie успя да получи плащане за [помощ](https://web.archive.org/web/20181030123412/https://webcache.googleusercontent.com/search?strip=1&q=cache:https%3A%2F%2Fgithub.com%2FMARKETProtocol%2FMARKET.js%2Fissues%2F14) @MARKETProtocol работят по своята JavaScript библиотека [чрез награда за gitcoin](https://gitcoin.co/). +* @mamiM направи японски преводи за @MetaMask след [изданието беше финансирано от Bounties Network](https://explorer.bounties.network/bounty/134). + +## Намиране на финансиране за вашия проект + +Освен договореностите за отделни сътрудници, понякога проектите набират пари от компании, физически лица или други за финансиране на текуща работа. + +Организационното финансиране може да отиде за плащане на настоящи сътрудници, покриване на разходите за управление на проекта (като такси за хостинг) или инвестиране в нови функции или идеи. + +Тъй като популярността на отворения код нараства, намирането на финансиране за проекти все още е експериментално, но има няколко общи опции. + +### Съберете пари за работата си чрез кампании за групово финансиране или спонсорство + +Намирането на спонсорство работи добре, ако вече имате силна публика или репутация или проектът ви е много популярен. +Няколко примера за спонсорирани проекти включват: + +* **[webpack](https://github.com/webpack)** събира пари от компании и физически лица [чрез OpenCollective](https://opencollective.com/webpack) +* **[Ruby Together](https://rubytogether.org/),** организация с нестопанска цел, която плаща за работата по [bundler](https://github.com/bundler/bundler), [RubyGems](https://github.com/rubygems/rubygems) и други Ruby инфраструктурни проекти + +### Създайте поток от приходи + +В зависимост от вашия проект може да имате възможност да таксувате за търговска поддръжка, хоствани опции или допълнителни функции. Няколко примера включват: + +* **[Sidekiq](https://github.com/mperham/sidekiq)** предлага платени версии за допълнителна поддръжка +* **[Travis CI](https://github.com/travis-ci)** предлага платени версии на своя продукт +* **[Ghost](https://github.com/TryGhost/Ghost)** е организация с нестопанска цел с платена управлявана услуга + +Някои популярни проекти, като [npm](https://github.com/npm/cli) и [Docker](https://github.com/docker/docker), дори набират рисков капитал, за да подкрепят растежа на своя бизнес. + +### Кандидатствайте за безвъзмездно финансиране + +Някои софтуерни фондации и компании предлагат грантове за работа с отворен код. Понякога грантовете могат да се изплащат на физически лица, без да се създава юридическо лице за проекта. + +* **[Прочетете документите](https://github.com/rtfd/readthedocs.org)** получи субсидия от [Поддръжка на Mozilla Open Source](https://www.mozilla.org/en-US/grants/) +* Работата по **[OpenMRS](https://github.com/openmrs)** е финансирана от [Retreat за отворен код на Stripe](https://stripe.com/blog/open-source-retreat-2016-grantees) +* **[Libraries.io](https://github.com/librariesio)** получи грант от [Фондация Слоун](https://sloan.org/programs/digital-technology) +* **[Python Software Foundation](https://www.python.org/psf/grants/)** предлага грантове за работа, свързана с Python + +За по-подробни опции и казуси @nayafia [написа ръководство](https://github.com/nayafia/lemonade-stand) за получаване на заплащане за работа с отворен код. Различните видове финансиране изискват различни умения, така че преценете силните си страни, за да разберете коя опция работи най-добре за вас. + +## Изграждане на случай за финансова подкрепа + +Независимо дали вашият проект е нова идея или съществува от години, трябва да очаквате да вложите значителни мисли в идентифицирането на вашия целеви финансист и в представянето на убедителни аргументи. + +Независимо дали искате да платите за собственото си време или да наберете средства за проект, трябва да можете да отговорите на следните въпроси. + +### Въздействие + +Защо този проект е полезен? Защо вашите потребители или потенциални потребители го харесват толкова много? Къде ще бъде след пет години? + +### Сцепление + +Опитайте се да съберете доказателства, че вашият проект има значение, независимо дали става дума за показатели, анекдоти или препоръки. Има ли компании или забележителни хора, които използват вашия проект в момента? Ако не, виден човек го е одобрил? + +### Стойност за финансиращия + +До финансиращите, независимо дали вашият работодател или фондация, предоставяща безвъзмездни средства, често се обръщат с възможности. Защо трябва да подкрепят вашия проект пред всяка друга възможност? Как се облагодетелстват те лично? + +### Използване на средства + +Какво точно ще постигнете с предложеното финансиране? Съсредоточете се върху важни етапи или резултати на проекта, вместо да плащате заплата. + +### Как ще получите средствата + +Финансиращият има ли някакви изисквания относно изплащането? Например, може да се наложи да сте организация с нестопанска цел или да имате фискален спонсор с нестопанска цел. Или може би средствата трябва да бъдат дадени на отделен изпълнител, а не на организация. Тези изисквания варират между финансиращите, така че не забравяйте да направите проучването си предварително. + + + +## Експериментирайте и не се отказвайте + +Събирането на пари не е лесно, независимо дали сте проект с отворен код, организация с нестопанска цел или стартиращ софтуер, и в повечето случаи изисква от вас да проявите креативност. Определянето на начина, по който искате да получавате заплащане, извършването на вашите проучвания и поставянето на мястото на вашия финансиращ ще ви помогне да изградите убедителна аргументация за финансиране. diff --git a/_articles/bg/how-to-contribute.md b/_articles/bg/how-to-contribute.md new file mode 100644 index 00000000000..68d7cfbb6c9 --- /dev/null +++ b/_articles/bg/how-to-contribute.md @@ -0,0 +1,526 @@ +--- +lang: bg +title: Как да допринесете за отворения код +description: Искате ли да допринесете за отворен код? Ръководство за правене на приноси с отворен код за начинаещи и за ветерани. +class: contribute +order: 1 +image: /assets/images/cards/contribute.png +related: + - beginners + - building +--- + +## Защо да допринасяте за отворен код? + + + +Приносът към отворен код може да бъде възнаграждаващ начин за учене, преподаване и изграждане на опит в почти всяко умение, което можете да си представите. + +Защо хората допринасят за отворен код? Много причини! + +### Подобрете софтуера, на който разчитате + +Много сътрудници с отворен код започват като потребители на софтуер, за който допринасят. Когато намерите грешка в софтуер с отворен код, който използвате, може да искате да погледнете източника, за да видите дали можете да го коригирате сами. Ако случаят е такъв, тогава връщането на корекцията е най-добрият начин да се уверите, че вашите приятели (и вие самите, когато актуализирате до следващото издание) ще могат да се възползват от нея. + +### Подобрете съществуващите умения + +Независимо дали става въпрос за кодиране, дизайн на потребителски интерфейс, графичен дизайн, писане или организиране, ако търсите практика, има задача за вас по проект с отворен код. + +### Запознайте се с хора, които се интересуват от подобни неща + +Проекти с отворен код с топли, гостоприемни общности карат хората да се връщат с години. Много хора създават приятелства за цял живот чрез участието си в отворен код, независимо дали се срещат по време на конференции или късно вечерни онлайн чатове за бурито. + +### Намерете ментори и учете другите + +Работата с други по споделен проект означава, че ще трябва да обясните как правите нещата, както и да помолите други хора за помощ. Действията на учене и преподаване могат да бъдат удовлетворяваща дейност за всички участници. + +### Изградете публични артефакти, които ви помагат да развиете репутация (и кариера) + +По дефиниция цялата ви работа с отворен код е публична, което означава, че получавате безплатни примери, които да вземете навсякъде като демонстрация на това, което можете да правите. + +### Научете умения за хора + +Отвореният код предлага възможности за практикуване на лидерски и управленски умения, като разрешаване на конфликти, организиране на екипи от хора и приоритизиране на работата. + +### Овластяващо е да можеш да правиш промени, дори малки + +Не е нужно да сте сътрудник през целия живот, за да се насладите на участието в отворен код. Случвало ли ви се е да видите печатна грешка в уебсайт и да ви се иска някой да я поправи? В проект с отворен код можете да направите точно това. Отвореният код помага на хората да се чувстват независими от живота си и начина, по който преживяват света, и това само по себе си е удовлетворяващо. + +## Какво означава да допринасяш + +Ако сте нов сътрудник на отворен код, процесът може да бъде смущаващ. Как намирате правилния проект? Ами ако не знаете как да кодирате? Ами ако нещо се обърка? + +Не се притеснявайте! Има всякакви начини да се включите в проект с отворен код и няколко съвета ще ви помогнат да извлечете максимума от опита си. + +### Не е нужно да добавяте код + +Често срещано погрешно схващане относно приноса към отворен код е, че трябва да допринесете с код. Всъщност често другите части на проекта са [най-пренебрегвани или пренебрегвани](https://github.com/blog/2195-the-shape-of-open-source). Ще направите _огромна_ услуга на проекта, като предложите да се включите с тези видове принос! + + + +Дори ако обичате да пишете код, други видове приноси са чудесен начин да се включите в проект и да се срещнете с други членове на общността. Изграждането на тези взаимоотношения ще ви даде възможности да работите върху други части на проекта. + +### Обичате ли да планирате събития? + +* Организирайте семинари или срещи за проекта, [както @fzamperin направи за NodeSchool](https://github.com/nodeschool/organizers/issues/406) +* Организирайте конференция на проекта (ако има такава) +* Помогнете на членовете на общността да намерят правилните конференции и да представят предложения за изказване + +### Обичате ли да проектирате? + +* Преструктурирайте оформленията, за да подобрите използваемостта на проекта +* Извършете потребителско проучване, за да реорганизирате и прецизирате навигацията или менютата на проекта, [както предлага Drupal](https://www.drupal.org/community-initiatives/drupal-core/usability) +* Съставете ръководство за стил, за да помогнете на проекта да има последователен визуален дизайн +* Създайте изкуство за тениски или ново лого, [както направиха сътрудниците на hapi.js](https://github.com/hapijs/contrib/issues/68) + +### Обичаш ли да пишеш? + +* Напишете и подобрете документацията на проекта, [както @CBID2 направи за документацията на OpenSauced](https://github.com/open-sauced/docs/pull/151) +* Подгответе папка с примери, показващи как се използва проектът +* Стартирайте бюлетин за проекта или подредете акценти от пощенския списък, [както направи @opensauced за своя продукт](https://news.opensauced.pizza/about/) +* Напишете уроци за проекта, [както направиха сътрудниците на PyPA](https://github.com/pypa/python-packaging-user-guide/issues/194) +* Напишете превод за документацията на проекта, [както @frontendwizard направи за инструкциите за CSS Flexbox предизвикателството на freeCodeCamp](https://github.com/freeCodeCamp/freeCodeCamp/pull/19077) + + + +### Обичате ли да организирате? + +* Връзка към дублирани проблеми и предлагане на теми за нови проблеми, за да поддържате организацията +* Прегледайте отворените проблеми и предложете затваряне на стари, [както направи @nzakas за ESLint](https://github.com/eslint/eslint/issues/6765) +* Задавайте изясняващи въпроси по наскоро открити въпроси, за да придвижите дискусията напред + +### Обичате ли да кодирате? + +* Намерете открит проблем, който да решите, [както @dianjin направи за Leaflet](https://github.com/Leaflet/Leaflet/issues/4528#issuecomment-216520560) +* Попитайте дали можете да помогнете за записването на нова функция +* Автоматизирайте настройките на проекта +* Подобрете инструментите и тестването + +### Обичате ли да помагате на хората? + +* Отговорете на въпроси относно проекта напр. Stack Overflow ([като този пример на Postgres](https://stackoverflow.com/questions/18664074/getting-error-peer-authentication-failed-for-user-postgres-when-trying-to-ge)) или Reddit +* Отговаряйте на въпроси за хора по отворени въпроси +* Помогнете за модерирането на дискусионните табла или каналите за разговори + +### Обичате ли да помагате на другите да кодират? + +* Прегледайте кода на изявленията на други хора +* Напишете уроци за това как може да се използва проект +* Предложете да наставлявате друг сътрудник, [както @ereichert направи за @bronzdoc в Rust](https://github.com/rust-lang/book/issues/123#issuecomment-238049666) + +### Не е нужно просто да работите върху софтуерни проекти! + +Докато "отворен код" често се отнася до софтуер, можете да си сътрудничите по почти всичко. Има книги, рецепти, списъци и класове, които се разработват като проекти с отворен код. + +Например: + +* @sindresorhus подготвя [списък с "страхотни" списъци](https://github.com/sindresorhus/awesome) +* @h5bp поддържа [списък с потенциални въпроси за интервю](https://github.com/h5bp/Front-end-Developer-Interview-Questions) за кандидати за фронтенд разработчици +* @stuartlynn и @nicole-a-tesla направиха [колекция от забавни факти за пуфините](https://github.com/stuartlynn/puffin_facts) + +Дори и да сте разработчик на софтуер, работата по проект за документация може да ви помогне да започнете работа с отворен код. Често е по-малко смущаващо да работите по проекти, които не включват код, а процесът на сътрудничество ще изгради вашата увереност и опит. + +## Ориентиране към нов проект + + + +За нещо повече от поправка на печатна грешка, да допринесете за отворен код е като да отидете до група непознати на парти. Ако започнете да говорите за лами, докато те бяха потънали в дискусия за златните рибки, вероятно ще ви погледнат малко странно. + +Преди да се включите сляпо със собствените си предложения, започнете, като се научите как да четете стаята. По този начин увеличавате шансовете вашите идеи да бъдат забелязани и чути. + +### Анатомия на проект с отворен код + +Всяка общност с отворен код е различна. + +Прекарването на години в един проект с отворен код означава, че сте се запознали с един проект с отворен код. Преминете към друг проект и може да откриете, че речникът, нормите и стиловете на комуникация са напълно различни. + +Въпреки това много проекти с отворен код следват подобна организационна структура. Разбирането на различните роли в общността и цялостния процес ще ви помогне бързо да се ориентирате към всеки нов проект. + +Типичен проект с отворен код има следните типове хора: + +* **Автор:** Лицето/лицата или организацията, създали проекта +* **Собственик:** Лицето/лицата, което има административна собственост върху организацията или хранилището (не винаги е същото като оригиналния автор) +* **Поддържащи:** Сътрудници, които са отговорни за управлението на визията и управлението на организационните аспекти на проекта (Те също могат да бъдат автори или собственици на проекта.) +* **Сътрудници:** Всеки, който е допринесъл с нещо обратно към проекта +* **Членове на общността:** Хората, които използват проекта. Те могат да бъдат активни в разговорите или да изразят мнението си за посоката на проекта + +По-големите проекти могат също да имат подкомисии или работни групи, фокусирани върху различни задачи, като инструменти, сортиране, модериране на общността и организиране на събития. Потърсете в уебсайта на даден проект страница за "екип" или в хранилището за документация за управление, за да намерите тази информация. + +Към проекта има и документация. Тези файлове обикновено са изброени в горното ниво на хранилището. + +* **ЛИЦЕНЗ:** По дефиниция всеки проект с отворен код трябва да има [лиценз за отворен код](https://choosealicense.com). Ако проектът няма лиценз, той не е с отворен код. +* **README:** README е ръководството с инструкции, което приветства новите членове на общността в проекта. Той обяснява защо проектът е полезен и как да започнете. +* **ПРИНОС:** Докато README помагат на хората да _използват_ проекта, допринасящите документи помагат на хората да _допринасят_ за проекта. Той обяснява какви видове вноски са необходими и как работи процесът. Въпреки че не всеки проект има ПРИНОСЯЩ файл, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете. Добър пример за ефективно ръководство за принос би било това от [хранилището на документи на Codecademy](https://www.codecademy.com/resources/docs/contribution-guide). +* **CODE_OF_CONDUCT:** Кодексът за поведение определя основните правила за свързаното поведение на участниците и спомага за създаването на приятелска, гостоприемна среда. Въпреки че не всеки проект има файл CODE_OF_CONDUCT, присъствието му сигнализира, че това е приветлив проект, за който можете да допринесете. +* **Друга документация:** Може да има допълнителна документация, като уроци, инструкции или политики за управление, особено за по-големи проекти като [Astro Docs](https://docs.astro.build/en/contribute/#contributing-to-docs). + +И накрая, проектите с отворен код използват следните инструменти за организиране на дискусия. Четенето на архивите ще ви даде добра представа за това как общността мисли и работи. + +* **Проследяване на проблеми:** Където хората обсъждат въпроси, свързани с проекта. +* **Заявки за изтегляне:** Когато хората обсъждат и преглеждат промените, които са в ход, независимо дали са за подобряване на реда код на сътрудника, използването на граматика, използването на изображения и т.н. Някои проекти, като [MDN Web Docs](https://github.com/mdn/content/blob/main/.github/workflows/markdown-lint-fix.yml), използват определени потоци за действие на GitHub, за да автоматизират и ускорят своите прегледи на кода. +* **Дискусионни форуми или пощенски списъци:** Някои проекти могат да използват тези канали за теми за разговор (например _"Как да..."_ или _"Какво мислиш за..."_ вместо грешка отчети или заявки за функции). Други използват инструмента за проследяване на проблеми за всички разговори. Добър пример за това би бил [седмичният бюлетин на CHAOSS](https://chaoss.community/news/) +* **Синхронен чат канал:** Някои проекти използват чат канали (като Slack или IRC) за непринуден разговор, сътрудничество и бърз обмен. Добър пример за това би била [общността на Discord на EddieHub](http://discord.eddiehub.org/). + +## Намиране на проект, за който да допринесете + +Сега, след като разбрахте как работят проектите с отворен код, време е да намерите проект, за който да допринесете! + +Ако никога преди не сте допринасяли за отворения код, приемете съвет от президента на САЩ Джон Ф. Кенеди, който веднъж каза: "Не питайте какво вашата страна може да направи за вас – попитайте какво можете да направите вие за вашата страна."_ + + + +Приносът към отворения код се случва на всички нива, във всички проекти. Не е нужно да мислите прекалено много какъв точно ще бъде първият ви принос или как ще изглежда. + +Вместо това започнете, като помислите за проектите, които вече използвате или искате да използвате. Проектите, за които ще участвате активно, са тези, към които се връщате. + +В рамките на тези проекти, всеки път, когато се хванете, че мислите, че нещо може да бъде по-добро или различно, действайте според инстинкта си. + +Отвореният код не е изключителен клуб; направено е от хора точно като вас. "Отворен код" е просто фантастичен термин за третиране на световните проблеми като поправими. + +Може да сканирате README и да намерите повредена връзка или правописна грешка. Или сте нов потребител и сте забелязали, че нещо е счупено, или проблем, който смятате, че наистина трябва да бъде в документацията. Вместо да го игнорирате и да продължите напред, или да помолите някой друг да го поправи, вижте дали можете да помогнете, като се включите. Това е смисълът на отворения код! + +> Според проучване, проведено от Игор Щайнмахер и други изследователи на компютърните науки, [28% от случайните приноси](https://www.igor.pro.br/publica/papers/saner2016.pdf) в отворен код са документация, като като корекции на печатни грешки, преформатиране или писане на превод. + +Ако търсите съществуващи проблеми, които можете да коригирате, всеки проект с отворен код има страница `/contribute`, която подчертава лесни за начинаещи проблеми, с които можете да започнете. Отидете до главната страница на хранилището в GitHub и добавете `/contribute` в края на URL адреса (например [`https://github.com/facebook/react/contribute`](https://github.com/facebook/react/contribute)). + +Можете също да използвате един от следните ресурси, за да ви помогне да откриете и допринесете за нови проекти: + +* [GitHub Explore](https://github.com/explore/) +* [Open Source Friday](https://opensourcefriday.com) +* [First Timers Only](https://www.firsttimersonly.com/) +* [CodeTriage](https://www.codetriage.com/) +* [24 Pull Requests](https://24pullrequests.com/) +* [Up For Grabs](https://up-for-grabs.net/) +* [First Contributions](https://firstcontributions.github.io) +* [SourceSort](https://web.archive.org/web/20201111233803/https://www.sourcesort.com/) +* [OpenSauced](https://opensauced.pizza/) + +### Контролен списък, преди да допринесете + +Когато намерите проект, за който искате да допринесете, направете бързо сканиране, за да се уверите, че проектът е подходящ за приемане на приноси. В противен случай вашата упорита работа може никога да не получи отговор. + +Ето един удобен контролен списък, за да оцените дали даден проект е добър за нови сътрудници. + +**Отговаря на определението за отворен код** + +
+ + +
+ +**Проектът активно приема вноски** + +Погледнете активността на комит в главния клон. В GitHub можете да видите тази информация в раздела Insights на началната страница на хранилище, като например [Virtual-Coffee](https://github.com/Virtual-Coffee/virtualcoffee.io/pulse) + +
+ + +
+ +
+ + +
+ +
+ + +
+ +След това разгледайте проблемите на проекта. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +Сега направете същото за заявките за изтегляне на проекта. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Проектът е приветлив** + +Проект, който е приятелски настроен и гостоприемен, сигнализира, че те ще бъдат възприемчиви към нови сътрудници. + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ + + +## Как да изпратите принос + +Намерихте проект, който харесвате, и сте готови да дадете своя принос. Най-накрая! Ето как да получите своя принос по правилния начин. + +### Ефективна комуникация + +Независимо дали сте сътрудник еднократно, или се опитвате да се присъедините към общност, работата с други е едно от най-важните умения, които ще развиете в отворен код. + + + +Преди да отворите проблем или заявка за изтегляне, или да зададете въпрос в чата, имайте предвид тези моменти, за да помогнете на вашите идеи да се реализират ефективно. + +**Дайте контекст.** Помогнете на другите да навлязат бързо. Ако попаднете на грешка, обяснете какво се опитвате да направите и как да я възпроизведете. Ако предлагате нова идея, обяснете защо смятате, че би била полезна за проекта (не само за вас!). + +> 😇 _"X не се случва, когато направя Y"_ +> +> 😢 _"X е повреден! Моля, поправете го."_ + +**Напишете си домашното предварително.** Добре е да не знаете нещата, но покажете, че сте опитали. Преди да поискате помощ, не забравяйте да проверите README на проекта, документацията, проблемите (отворени или затворени), пощенския списък и потърсете в интернет за отговор. Хората ще го оценят, когато демонстрирате, че се опитвате да учите. + +> 😇 _"Не съм сигурен как да внедря X. Проверих помощните документи и не намерих никакви споменавания."_ +> +> 😢 _"Как да направя X?"_ + +**Поддържайте заявките кратки и директни.** Подобно на изпращането на имейл, всеки принос, без значение колко прост или полезен, изисква преглед от някой друг. Много проекти имат повече входящи заявки, отколкото хора, които могат да помогнат. Бъдете кратки. Ще увеличите шанса някой да може да ви помогне. + +> 😇 _"Бих искал да напиша урок за API."_ +> +> 😢 _"Онзи ден карах по магистралата и спрях за газ и тогава ми хрумна тази невероятна идея за нещо, което трябва да направим, но преди да обясня това, нека ви покажа..."_ + +**Пазете цялата комуникация публична.** Въпреки че е изкушаващо, не се свързвайте лично с поддържащите, освен ако не трябва да споделите чувствителна информация (като проблем със сигурността или сериозно нарушение на поведението). Когато поддържате разговора публичен, повече хора могат да научат и да се възползват от вашия обмен. Дискусиите могат сами по себе си да бъдат принос. + +> 😇 _(като коментар) "@-maintainer Здравейте! Как да продължим с този PR?"_ +> +> 😢 _(като имейл) "Здравейте, съжалявам, че ви безпокоя по имейл, но се чудех дали сте имали възможност да прегледате моя PR"_ + +**Добре е да задавате въпроси (но бъдете търпеливи!).** Всеки е бил нов в проекта в някакъв момент и дори опитните сътрудници трябва да навлизат в крак, когато разглеждат нов проект. По същия принцип дори дългогодишните поддържащи не винаги са запознати с всяка част от проекта. Покажете им същото търпение, което бихте искали те да проявяват към вас. + +> 😇 _"Благодаря, че разгледахте тази грешка. Следвах вашите предложения. Ето резултата."_ +> +> 😢 _"Защо не можете да решите проблема ми? Това не е ли вашият проект?"_ + +**Уважавайте решенията на общността.** Вашите идеи може да се различават от приоритетите или визията на общността. Те могат да предложат обратна връзка или да решат да не следват вашата идея. Въпреки че трябва да обсъждате и търсите компромис, поддържащите трябва да живеят с вашето решение по-дълго, отколкото вие ще го направите. Ако не сте съгласни с тяхната посока, винаги можете да работите върху своя собствена вилица или да започнете свой собствен проект. + +> 😇 _"Разочарован съм, че не можете да подкрепите моя случай на употреба, но както обяснихте, той засяга само малка част от потребителите, разбирам защо. Благодаря, че ме изслушахте."_ +> +> 😢 _"Защо не подкрепите моя случай на употреба? Това е неприемливо!"_ + +**Преди всичко го поддържайте елегантно.** Отвореният код се състои от сътрудници от цял свят. Контекстът се губи между езиците, културите, географията и часовите зони. Освен това писмената комуникация прави по-трудно предаването на тон или настроение. Предполагайте добри намерения в тези разговори. Добре е учтиво да отхвърлите идея, да поискате повече контекст или да изясните допълнително позицията си. Просто се опитайте да оставите интернет по-добро място, отколкото когато сте го намерили. + +### Събиране на контекст + +Преди да предприемете нещо, направете бърза проверка, за да се уверите, че идеята ви не е била обсъждана другаде. Прегледайте README на проекта, проблеми (отворени и затворени), пощенски списък и Stack Overflow. Не е нужно да прекарвате часове в разглеждане на всичко, но бързото търсене на няколко ключови термина върши дълъг път. + +Ако не можете да намерите идеята си другаде, вие сте готови да предприемете ход. Ако проектът е в GitHub, вероятно ще комуникирате, като направите следното: + +* **Повдигане на проблем:** Това е като започване на разговор или дискусия +* **Заявките за изтегляне** са за започване на работа по решение. +* **Канали за комуникация:** Ако проектът има определен Discord, IRC или Slack канал, помислете дали да започнете разговор или да поискате разяснение относно вашия принос. + +Преди да отворите проблем или заявка за изтегляне, проверете допринасящите документи на проекта (обикновено файл, наречен CONTRIBUTING или в README), за да видите дали трябва да включите нещо конкретно. Например, те могат да поискат да следвате шаблон или да изискват да използвате тестове. + +Ако искате да направите значителен принос, отворете проблем, който да попитате, преди да работите по него. Полезно е да гледате проекта известно време (в GitHub, [можете да щракнете върху "Гледане"](https://help.github.com/articles/watching-repositories/), за да бъдете уведомени за всички разговори) и да стигнете до познавайте членовете на общността, преди да вършите работа, която може да не бъде приета. + + + +### Отваряне на проблем + +Обикновено трябва да отворите проблем в следните ситуации: + +* Докладвайте за грешка, която не можете да разрешите сами +* Обсъдете тема или идея на високо ниво (например общност, визия или политики) +* Предложете нова функция или друга идея за проект + +Съвети за комуникация по проблеми: + +* **Ако видите отворен проблем, с който искате да се заемете**, коментирайте проблема, за да уведомите хората, че работите по него. По този начин е по-малко вероятно хората да дублират вашата работа. +* **Ако даден проблем е открит преди известно време,** е възможно той да се адресира някъде другаде или вече да е разрешен, така че коментирайте, за да поискате потвърждение, преди да започнете работа. +* **Ако сте отворили проблем, но сте разбрали отговора по-късно сами,** коментирайте проблема, за да уведомите хората, след което затворете проблема. Дори документирането на този резултат е принос към проекта. + +### Отваряне на заявка за изтегляне + +Обикновено трябва да отворите заявка за изтегляне в следните ситуации: + +* Изпратете малки корекции като печатна грешка, повредена връзка или очевидна грешка. +* Започнете работа по принос, който вече е поискан или който вече сте обсъждали в даден брой. + +Заявката за изтегляне не трябва да представлява завършена работа. Обикновено е по-добре да отворите заявка за изтегляне рано, така че другите да могат да гледат или да дадат обратна връзка за напредъка ви. Просто го отворете като "чернова" или маркирайте като "WIP" (Работа в процес) в реда за тема или в секциите "Бележки към рецензентите", ако са предоставени (или можете просто да създадете свой собствен. Подобно на това: `**## Бележки към рецензента**`). Винаги можете да добавите още ангажименти по-късно. + +Ако проектът е в GitHub, ето как да изпратите заявка за изтегляне: + +* **[Разклонете хранилището](https://guides.github.com/activities/forking/)** и го клонирайте локално. Свържете вашето локално към оригиналното хранилище "нагоре по веригата", като го добавите като дистанционно. Изтегляйте често промените от "нагоре по веригата", така че да сте в течение, така че когато изпратите заявката си за изтегляне, конфликтите при сливане ще бъдат по-малко вероятни. (Вижте по-подробни инструкции [тук](https://help.github.com/articles/syncing-a-fork/).) +* **[Създайте клон](https://guides.github.com/introduction/flow/)** за вашите редакции. +* **Посочете всички съответни проблеми** или подкрепяща документация във вашия PR (например "Затваря #37.") +* **Включете екранни снимки преди и след**, ако вашите промени включват разлики в HTML/CSS. Плъзнете и пуснете изображенията в тялото на вашата заявка за изтегляне. +* **Тествайте промените си!** Стартирайте промените си срещу всички съществуващи тестове, ако съществуват, и създайте нови, когато е необходимо. Важно е да се уверите, че вашите промени не нарушават съществуващия проект. +* **Допринесете в стила на проекта** според възможностите си. Това може да означава използване на отстъпи, точка и запетая или коментари по различен начин, отколкото бихте направили във вашето собствено хранилище, но улеснява поддържащия да слива, другите да разбират и поддържат в бъдеще. + +Ако това е първата ви заявка за изтегляне, вижте [Направете заявка за изтегляне](http://makeapullrequest.com/), която @kentcdodds създаде като видеоурок с инструкции. Можете също така да практикувате да правите заявка за изтегляне в хранилището [Първи вноски](https://github.com/Roshanjossey/first-contributions), създадено от @Roshanjossey. + +## Какво се случва, след като изпратите своя принос + +Преди да започнем да празнуваме, едно от следните ще се случи, след като изпратите своя принос: + +### 😭 Не получавате отговор + +Надяваме се, че сте [проверили проекта за признаци на активност](#контролен-списък-преди-да-допринесете), преди да направите принос. Дори при активен проект обаче е възможно вашият принос да не получи отговор. + +Ако не сте получили отговор повече от седмица, е честно да отговорите учтиво в същата тема, като помолите някого за преглед. Ако знаете името на подходящия човек, който да прегледа вашия принос, можете да го споменете с @ в тази нишка. + +**Не се свързвайте лично с този човек**; не забравяйте, че публичната комуникация е жизненоважна за проектите с отворен код. + +Ако дадете учтиво напомняне и все още не получите отговор, възможно е никой никога да не отговори. Чувството не е страхотно, но не позволявайте това да ви обезсърчава! 😄 Има много възможни причини, поради които не сте получили отговор, включително лични обстоятелства, които може да са извън вашия контрол. Опитайте се да намерите друг проект или начин да допринесете. Ако не друго, това е добра причина да не инвестирате твърде много време в даването на принос, преди другите членове на общността да са ангажирани и отзивчиви. + +### 🚧 Някой иска промени във вашия принос + +Обичайно е да бъдете помолени да направите промени във вашия принос, независимо дали това е обратна връзка относно обхвата на вашата идея или промени в кода ви. + +Когато някой поиска промени, бъдете отзивчиви. Те са отделили време да прегледат приноса ви. Да отвориш PR и да си тръгнеш е лоша форма. Ако не знаете как да правите промени, проучете проблема и след това поискайте помощ, ако имате нужда от нея. Добър пример за това би била [обратната връзка, която друг сътрудник е дал на @a-m-lamb относно тяхната заявка за изтегляне към документите на Codecademy](https://github.com/Codecademy/docs/pull/3239#pullrequestreview-1628036286). + +Ако вече нямате време да работите по проблема поради причини като разговорът продължава от месеци и обстоятелствата ви са се променили или не можете да намерите решение, уведомете поддържащия, за да може отворете проблема за някой друг, като [@RitaDee направи за проблем в хранилището за приложения на OpenSauced](https://github.com/open-sauced/app/issues/1656#issuecomment-1729353346). + +### 👎 Вашият принос не се приема + +Вашият принос може или не може да бъде приет в крайна сметка. Надяваме се, че вече не сте вложили твърде много работа в него. Ако не сте сигурни защо не е приет, е напълно разумно да помолите поддържащия за обратна връзка и разяснение. В крайна сметка обаче ще трябва да уважите, че това е тяхно решение. Не спорете и не бъдете враждебни. Винаги сте добре дошли да се разклоните и да работите върху собствената си версия, ако не сте съгласни! + +### 🎉 Вашият принос се приема + +Ура! Успешно направихте принос с отворен код! + +## Направи го! 🎉 + +Независимо дали току-що сте направили първия си принос с отворен код или търсите нови начини да допринесете, надяваме се, че сте вдъхновени да предприемете действие. Дори ако вашият принос не е бил приет, не забравяйте да благодарите, когато поддържащият положил усилия да ви помогне. Отвореният код е направен от хора като вас: един проблем, заявка за изтегляне, коментар или дай пет наведнъж. diff --git a/_articles/bg/index.html b/_articles/bg/index.html new file mode 100644 index 00000000000..699f7d67dc3 --- /dev/null +++ b/_articles/bg/index.html @@ -0,0 +1,6 @@ +--- +layout: index +title: Ръководства за отворен код +lang: bg +permalink: /bg/ +--- diff --git a/_articles/bg/leadership-and-governance.md b/_articles/bg/leadership-and-governance.md new file mode 100644 index 00000000000..93d1e55d6ea --- /dev/null +++ b/_articles/bg/leadership-and-governance.md @@ -0,0 +1,156 @@ +--- +lang: bg +title: Лидерство и управление +description: Разрастващите се проекти с отворен код могат да се възползват от формалните правила за вземане на решения. +class: leadership +order: 6 +image: /assets/images/cards/leadership.png +related: + - best-practices + - metrics +--- + +## Разбиране на управлението за вашия разрастващ се проект + +Вашият проект се разраства, хората са ангажирани и вие сте ангажирани да поддържате това нещо. На този етап може да се чудите как да включите редовни сътрудници на проекта във вашия работен процес, независимо дали става дума за даване на достъп за ангажимент или разрешаване на дебати в общността. Ако имате въпроси, ние имаме отговори. + +## Какви са примерите за официални роли, използвани в проекти с отворен код? + +Много проекти следват подобна структура за роли на сътрудници и признание. + +Какво всъщност означават тези роли обаче, зависи изцяло от вас. Ето няколко типа роли, които може да разпознаете: + +* **Поддържащ** +* **Сътрудник** +* **Комитер** + +**За някои проекти "поддържащите"** са единствените хора в проект с достъп за ангажиране. В други проекти те са просто хората, които са изброени в README като поддържащи. + +Поддържащият не е задължително да е някой, който пише код за вашия проект. Може да е някой, който е свършил много работа по евангелизирането на вашия проект, или писмена документация, която е направила проекта по-достъпен за другите. Независимо от това, което прави всеки ден, поддържащият вероятно е някой, който се чувства отговорен за посоката на проекта и се е ангажирал да го подобри. + +**"Сътрудник" може да бъде всеки**, който коментира проблем или заявка за изтегляне, хора, които добавят стойност към проекта (независимо дали става въпрос за сортиране на проблеми, писане на код или организиране на събития), или всеки с обединена заявка за изтегляне (може би най-тясната дефиниция на сътрудник). + + + +**Терминът "извършител"** може да се използва за разграничаване на достъпа за ангажиране, който е специфичен тип отговорност, от други форми на принос. + +Въпреки че можете да дефинирате ролите си в проекта както желаете, [помислете дали да не използвате по-широки дефиниции](../how-to-contribute/#какво-означава-да-допринасяш), за да насърчите повече форми на принос. Можете да използвате лидерски роли, за да признаете официално хора, които са направили изключителен принос към вашия проект, независимо от техните технически умения. + + + +## Как да формализирам тези лидерски роли? + +Формализирането на вашите лидерски роли помага на хората да се чувстват собственост и казва на другите членове на общността към кого да търсят помощ. + +За по-малък проект определянето на лидери може да бъде толкова просто, колкото добавянето на техните имена към вашия README или текстов файл CONTRIBUTORS. + +За по-голям проект, ако имате уебсайт, създайте страница на екип или избройте ръководителите на проекта си там. Например [Postgres](https://github.com/postgres/postgres/) има [изчерпателна екипна страница](https://www.postgresql.org/community/contributors/) с кратки профили за всеки участник. + +Ако вашият проект има много активна общност на сътрудници, можете да сформирате "основен екип" от поддържащи или дори подкомитети от хора, които поемат отговорност за различни проблемни области (например сигурност, сортиране на проблеми или поведение на общността). Позволете на хората да се самоорганизират и доброволно изпълняват ролите, които ги вълнуват най-много, вместо да ги възлагат. + + + +Лидерските екипи може да искат да създадат определен канал (като в IRC) или да се срещат редовно, за да обсъждат проекта (като в Gitter или Google Hangout). Можете дори да направите тези срещи публични, така че други хора да могат да слушат. [Cucumber-ruby](https://github.com/cucumber/cucumber-ruby), например, [поема работно време всяка седмица](https://github.com/cucumber/cucumber-ruby/blob/HEAD/CONTRIBUTING.md#talking-with-other-devs). + +След като сте установили лидерски роли, не забравяйте да документирате как хората могат да ги постигнат! Установете ясен процес за това как някой може да стане поддържащ или да се присъедини към подкомисия във вашия проект и го напишете във вашия GOVERNANCE.md. + +Инструменти като [Vossibility](https://github.com/icecrime/vossibility-stack) могат да ви помогнат публично да проследите кой (или не) прави принос към проекта. Документирането на тази информация избягва възприемането на общността, че поддържащите са клика, която взема решенията си частно. + +И накрая, ако проектът ви е в GitHub, помислете за преместване на проекта от личния ви акаунт в организация и добавяне на поне един резервен администратор. [Организациите на GitHub](https://help.github.com/articles/creating-a-new-organization-account/) улесняват управлението на разрешения и множество хранилища и защитават наследството на вашия проект чрез [споделена собственост](../building-community/#споделете-собствеността-върху-вашия-проект). + +## Кога трябва да дам на някого достъп за ангажиране? + +Някои хора смятат, че трябва да дадете достъп за ангажиране на всеки, който направи принос. Това може да насърчи повече хора да почувстват собственост върху вашия проект. + +От друга страна, особено за по-големи, по-сложни проекти, може да искате да дадете достъп за ангажиране само на хора, които са демонстрирали своя ангажимент. Няма един правилен начин да го направите - направете това, което ви прави най-удобно! + +Ако вашият проект е в GitHub, можете да използвате [защитени клонове](https://help.github.com/articles/about-protected-branches/), за да управлявате кой може да насочва към определен клон и при какви обстоятелства. + + + +## Какви са някои от общите структури на управление за проекти с отворен код? + +Има три общи структури на управление, свързани с проекти с отворен код. + +* **BDFL:** BDFL означава "Доброжелателен диктатор за цял живот". При тази структура един човек (обикновено първоначалният автор на проекта) има последната дума за всички основни решения по проекта. [Python](https://github.com/python) е класически пример. По-малките проекти вероятно са BDFL по подразбиране, защото има само един или двама поддържащи. Проект, който произхожда от компания, може също да попадне в категорията BDFL. + +* **Меритокрация:** (Забележка: терминът "меритокрация" носи отрицателни конотации за някои общности и има [сложна социална и политическа история](http://geekfeminism.wikia.com/wiki/Meritocracy).) ** При меритокрацията на активните участници в проекти (тези, които демонстрират "заслуги") се дава официална роля за вземане на решения. Решенията обикновено се вземат въз основа на чист консенсус при гласуване. Концепцията за меритокрация е въведена от [Фондация Apache](https://www.apache.org/); [всички проекти на Apache](https://www.apache.org/index.html#projects-list) са меритокрации. Вноски могат да се правят само от лица, представляващи себе си, а не от компания. + +* **Либерален принос:** При либерален модел на принос хората, които вършат най-много работа, се признават за най-влиятелни, но това се основава на текуща работа, а не на исторически принос. Решенията за големи проекти се вземат въз основа на процес на търсене на консенсус (обсъждане на основните оплаквания), а не на чисто гласуване, и се стремят да включват възможно най-много гледни точки на общността. Популярни примери за проекти, които използват либерален модел на принос, включват [Node.js](https://foundation.nodejs.org/) и [Rust](https://www.rust-lang.org/). + +Кое трябва да използвате? От теб зависи! Всеки модел има предимства и компромиси. И въпреки че в началото може да изглеждат доста различни, и трите модела имат повече общо, отколкото изглежда. Ако се интересувате от приемането на един от тези модели, вижтеthese templates: + +* [BDFL model template](http://oss-watch.ac.uk/resources/benevolentdictatorgovernancemodel) +* [Meritocracy model template](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel) +* [Node.js's liberal contribution policy](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) + +## Имам ли нужда от документи за управление, когато стартирам проекта си? + +Няма подходящ момент да запишете управлението на вашия проект, но е много по-лесно да го дефинирате, след като видите как се развива динамиката на вашата общност. Най-добрата (и най-трудната) част от управлението с отворен код е, че е оформено от общността! + +Някои ранни документи обаче неизбежно ще допринесат за управлението на вашия проект, така че започнете да записвате каквото можете. Например, можете да дефинирате ясни очаквания за поведение или как работи вашият процес на сътрудник, дори при стартирането на вашия проект. + +Ако сте част от компания, стартираща проект с отворен код, струва си да проведете вътрешна дискусия преди стартирането за това как вашата компания очаква да поддържа и да взема решения за напредъка на проекта. Можете също така да искате публично да обясните нещо конкретно за това как вашата компания ще (или няма!) да бъде включена в проекта. + + + +## Какво се случва, ако корпоративните служители започнат да изпращат вноски? + +Успешните проекти с отворен код се използват от много хора и компании и някои компании може в крайна сметка да имат потоци от приходи, които в крайна сметка да са свързани с проекта. Например, една компания може да използва кода на проекта като един компонент в предлагането на търговска услуга. + +Тъй като проектът се използва по-широко, хората, които имат опит в него, стават все по-търсени - вие може да сте един от тях! - и понякога ще получават заплащане за работата, която вършат в проекта. + +Важно е търговската дейност да се третира като нормална и просто като още един източник на енергия за развитие. Разбира се, платените разработчици не трябва да получават специално отношение спрямо неплатените; всеки принос трябва да бъде оценен според техническите си качества. Въпреки това, хората трябва да се чувстват комфортно да участват в търговска дейност и да се чувстват комфортно да посочват своите случаи на употреба, когато спорят в полза на определено подобрение или функция. + +"Комерсиален" е напълно съвместим с "отворен код". "Търговски" просто означава, че някъде има замесени пари – че софтуерът се използва в търговията, което е все по-вероятно, тъй като даден проект получава приемане. (Когато софтуер с отворен код се използва като част от продукт с неотворен код, цялостният продукт все още е "патентован" софтуер, въпреки че, подобно на отворен код, може да се използва за търговски или нетърговски цели.) + +Като всеки друг, комерсиално мотивираните разработчици печелят влияние в проекта чрез качеството и количеството на техния принос. Очевидно програмист, който получава заплащане за времето си, може да е в състояние да направи повече от някой, който не получава заплащане, но това е добре: плащането е само един от многото възможни фактори, които могат да повлияят на това колко прави някой. Поддържайте дискусиите по проекта си фокусирани върху приноса, а не върху външните фактори, които позволяват на хората да направят този принос. + +## Нуждая ли се от юридическо лице, което да поддържа моя проект? + +Нямате нужда от юридическо лице, за да поддържате вашия проект с отворен код, освен ако не боравите с пари. + +Например, ако искате да създадете търговски бизнес, ще искате да създадете C Corp или LLC (ако сте базирани в САЩ). Ако просто работите по договор, свързан с вашия проект с отворен код, можете да приемате пари като едноличен собственик или да създадете LLC (ако сте базирани в САЩ). + +Ако искате да приемате дарения за вашия проект с отворен код, можете да настроите бутон за дарение (с помощта на PayPal или Stripe, например), но парите няма да се приспадат от данъци, освен ако не сте квалифицирана организация с нестопанска цел (501c3, ако вие сте в САЩ). + +Много проекти не желаят да преминат през неприятностите при създаването на организация с нестопанска цел, така че вместо това намират фискален спонсор с нестопанска цел. Фискален спонсор приема дарения от ваше име, обикновено в замяна на процент от дарението. [Software Freedom Conservancy](https://sfconservancy.org/), [Apache Foundation](https://www.apache.org/), [Eclipse Foundation](https://eclipse.org/org/foundation/), [Linux Foundation](https://www.linuxfoundation.org/projects) и [Open Collective](https://opencollective.com/opensource) са примери за организации, които служат като фискални спонсори за проекти с отворен код. + + + +Ако вашият проект е тясно свързан с определен език или екосистема, може да има и свързана софтуерна основа, с която можете да работите. Например [Python Software Foundation](https://www.python.org/psf/) помага за поддръжката на [PyPI](https://pypi.org/), мениджъра на пакети на Python и [Node.js Foundation](https://foundation.nodejs.org/) помага за поддръжката на [Express.js](https://expressjs.com/), базирана на възли рамка. diff --git a/_articles/bg/legal.md b/_articles/bg/legal.md new file mode 100644 index 00000000000..2e56c75652d --- /dev/null +++ b/_articles/bg/legal.md @@ -0,0 +1,160 @@ +--- +lang: bg +title: Правната страна на отворения код +description: Всичко, което някога сте се чудили за правната страна на отворения код, и няколко неща, които не сте се чудили. +class: legal +order: 10 +image: /assets/images/cards/legal.png +related: + - contribute + - leadership +--- + +## Разбиране на правните последици от отворения код + +Споделянето на вашата творческа работа със света може да бъде вълнуващо и възнаграждаващо изживяване. Това може да означава и куп правни неща, за които не сте знаели, че трябва да се тревожите. За щастие, с това ръководство не е нужно да започвате от нулата. (Преди да се задълбочите, не забравяйте да прочетете нашия [отказ от отговорност](/notices/).) + +## Защо хората се интересуват толкова много от правната страна на отворения код? + +Радвам се, че попита! Когато правите творческо произведение (като писане, графики или код), това произведение е под изключителни авторски права по подразбиране. Тоест законът предполага, че като автор на вашето произведение вие имате думата какво другите могат да правят с него. + +Като цяло това означава, че никой друг не може да използва, копира, разпространява или модифицира вашата работа, без да бъде изложен на риск от премахване, разклащане или съдебни спорове. + +Отвореният код обаче е необичайно обстоятелство, тъй като авторът очаква други да използват, променят и споделят работата. Но тъй като правното подразбиране все още е изключително авторско право, трябва изрично да дадете тези разрешения с лиценз. + +Тези правила се прилагат и когато някой допринася за вашия проект. Без лиценз или друго споразумение всички приноси са изключителна собственост на техните автори. Това означава, че никой – дори вие – не може да използва, копира, разпространява или променя техния принос. + +И накрая, вашият проект може да има зависимости с лицензионни изисквания, за които не сте знаели. Общността на вашия проект или политиките на вашия работодател може също да изискват вашият проект да използва конкретни лицензи с отворен код. Ще разгледаме тези ситуации по-долу. + +## Публичните GitHub проекти с отворен код ли са? + +Когато [създадете нов проект](https://help.github.com/articles/creating-a-new-repository/) в GitHub, имате опцията да направите хранилището **частно** или **публично**. + +![Създаване на хранилище](/assets/images/legal/repo-create-name.png) + +**Да направите своя проект в GitHub публичен не е същото като да лицензирате проекта си.** Публичните проекти са обхванати от [Условията за ползване на GitHub](https://help.github.com/en/github/site-policy/github-Terms-of-service#3-ownership-of-content-right-to-post-and-license-grants), което позволява на другите да преглеждат и разклоняват вашия проект, но иначе работата ви идва без разрешения. + +Ако искате други да използват, разпространяват, модифицират или допринасят обратно към вашия проект, трябва да включите лиценз с отворен код. Например, някой не може законно да използва която и да е част от вашия GitHub проект в своя код, дори ако е публичен, освен ако изрично не му дадете правото да го направи. + +## Просто ми дайте обобщение за това, от което се нуждая, за да защитя проекта си. + +Имате късмет, защото днес лицензите за отворен код са стандартизирани и лесни за използване. Можете да копирате и поставите съществуващ лиценз директно във вашия проект. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) са [популярни лицензи за отворен код](https://innovationgraph.github.com/global-metrics/licenses), но има и други опции за избор. Можете да намерите пълния текст на тези лицензи и инструкции как да ги използвате на [choosealicense.com](https://choosealicense.com/). + +Когато създадете нов проект в GitHub, ще бъдете [помолени да добавите лиценз](https://help.github.com/articles/open-source-licensing/). + + + +## Кой лиценз с отворен код е подходящ за моя проект? + +Трудно е да сгрешите с [MIT License](https://choosealicense.com/licenses/mit/), ако започвате с празен лист. Той е кратък, лесен за разбиране и позволява на всеки да прави каквото и да е, стига да пази копие от лиценза, включително вашето известие за авторски права. Ще можете да пуснете проекта под различен лиценз, ако някога се наложи. + +В противен случай изборът на правилния лиценз с отворен код за вашия проект зависи от вашите цели. + +Вашият проект много вероятно има (или ще има) **зависимости**, всяка от които ще има собствен лиценз с отворен код с условия, които трябва да спазвате. Например, ако сте с отворен код за Node.js проект, вероятно ще използвате библиотеки от Node Package Manager (npm). + +Зависимости с **разрешителни лицензи** като [MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/), [ISC](https://choosealicense.com/licenses/isc) и [BSD](https://choosealicense.com/licenses/bsd-3-clause) ви позволяват да лицензирате проекта си както искате. + +Зависимостите с **лицензи за авторско право** изискват по-голямо внимание. Включително всяка библиотека със "силен" лиценз за копиралефт като [GPLv2](https://choosealicense.com/licenses/gpl-2.0), [GPLv3](https://choosealicense.com/licenses/gpl-3.0), или [AGPLv3](https://choosealicense.com/licenses/agpl-3.0) изисква да изберете идентичен или [съвместим лиценз](https://www.gnu.org/licenses/license-list.en.html#GPLCompatibleLicenses) за вашия проект. Библиотеки с "ограничен" или "слаб" лиценз за копиралефт като [MPL 2.0](https://choosealicense.com/licenses/mpl-2.0/) и [LGPL](https://choosealicense.com/licenses/lgpl-3.0/) могат да бъдат включени в проекти с произволен лиценз, при условие че следвате [допълнителните правила](https://fossa.com/blog/all-about-copyleft-licenses/#:~:text=weak%20copyleft%20licenses%20also%20obligate%20users%20to%20release%20their%20changes.%20however%2C%20this%20requirement%20applies%20to%20a%20narrower%20set%20of%20code.) посочват те. + +Можете също така да разгледате **общностите**, които се надявате да използвате и да допринесете за вашия проект: + +* **Искате ли вашият проект да бъде използван като зависимост от други проекти?** Вероятно най-добре е да използвате най-популярния лиценз в съответната общност. Например [MIT](https://choosealicense.com/licenses/mit/) е най-популярният лиценз за [npm библиотеки](https://libraries.io/search?platforms=NPM). +* **Искате ли вашият проект да се хареса на големия бизнес?** Големият бизнес може да се утеши от изричен патентен лиценз от всички сътрудници. В този случай [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) покрива вас (и тях). +* **Искате ли вашият проект да се хареса на сътрудници, които не искат техният принос да се използва в софтуер със затворен код?** [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) или (ако те също не желаят да допринасят за услуги със затворен код) [AGPLv3](https://choosealicense.com/licenses/agpl-3.0/) ще мине добре. + +Вашата **компания** може да има правила за лицензиране на проекти с отворен код. Някои компании изискват вашите проекти да носят разрешителен лиценз, за да позволят интеграция с фирмените продукти на компанията. Други политики налагат силен лиценз за копиралефт и споразумение за допълнителен сътрудник (вижте по-долу), така че само вашата компания може да използва проекта в софтуер със затворен код. Организациите може също така да имат определени стандарти, цели за социална отговорност или нужди от прозрачност, които може да изискват конкретна стратегия за лицензиране. Говорете с [правния отдел на вашата компания](#моят-проект-има-ли-нужда-от-споразумение-за-допълнителен-сътрудник) за насоки. + +Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на един от лицензите, споменати по-горе, ще направи вашия проект GitHub с отворен код. Ако искате да видите други опции, вижте [choosealicense.com](https://choosealicense.com), за да намерите правилния лиценз за вашия проект, дори ако [не е софтуер](https://choosealicense.com/non-software/). + +## Какво ще стане, ако искам да сменя лиценза на моя проект? + +Повечето проекти никога не се нуждаят от промяна на лицензи. Но понякога обстоятелствата се променят. + +Например, докато вашият проект расте, той добавя зависимости или потребители, или вашата компания променя стратегии, всяка от които може да изисква или иска различен лиценз. Освен това, ако сте пропуснали да лицензирате проекта си от самото начало, добавянето на лиценз е на практика същото като промяната на лицензите. Има три основни неща, които трябва да имате предвид, когато добавяте или променяте лиценза на вашия проект: + +**Сложно е.** Определянето на съвместимостта и съответствието на лиценза и кой притежава авторските права може да стане сложно и объркващо много бързо. Преминаването към нов, но съвместим лиценз за нови версии и приноси е различно от повторното лицензиране на всички съществуващи приноси. Включете юридическия си екип при първия намек за всяко желание за промяна на лицензи. Дори ако имате или можете да получите разрешение от притежателите на авторските права на вашия проект за промяна на лиценза, помислете за въздействието на промяната върху другите потребители и сътрудници на вашия проект. Мислете за промяната на лиценза като за "управленско събитие" за вашия проект, което е по-вероятно да протече гладко с ясна комуникация и консултация със заинтересованите страни във вашия проект. Още повече причина да изберете и използвате подходящ лиценз за вашия проект от самото му начало! + +**Съществуващият лиценз на вашия проект.** Ако съществуващият лиценз на вашия проект е съвместим с лиценза, който искате да промените, можете просто да започнете да използвате новия лиценз. Това е така, защото ако лиценз A е съвместим с лиценз B, вие ще спазвате условията на A, докато спазвате условията на B (но не непременно обратното). Така че, ако в момента използвате разрешителен лиценз (напр. MIT), можете да промените на лиценз с повече условия, стига да запазите копие от лиценза на MIT и всички свързани бележки за авторски права (т.е. да продължите да спазвате минималните условия на лиценза на MIT). Но ако текущият ви лиценз не е разрешителен (напр. copyleft или нямате лиценз) и не сте единственият притежател на авторските права, не можете просто да промените лиценза на вашия проект на MIT. По същество, с разрешителен лиценз, притежателите на авторските права на проекта са дали предварително разрешение за промяна на лицензите. + +**Съществуващи носители на авторски права на вашия проект.** Ако вие сте единственият сътрудник на вашия проект, тогава вие или вашата компания сте единственият носител на авторските права на проекта. Можете да добавите или промените какъвто лиценз вие или вашата компания искате. В противен случай може да има други притежатели на авторски права, от които се нуждаете от съгласие, за да промените лицензите. Кои са те? [Хората, които имат ангажименти във вашия проект](https://github.com/thehale/git-authorship) е добро място да започнете. Но в някои случаи авторските права ще се държат от работодателите на тези хора. В някои случаи хората ще са направили само минимален принос, но няма твърдо и бързо правило, че приносите под определен брой редове код не са обект на авторско право. Какво да правя? Зависи. За сравнително малък и млад проект може да е възможно да накарате всички съществуващи сътрудници да се съгласят с промяна на лиценза в проблем или заявка за изтегляне. За големи и дълготрайни проекти може да се наложи да потърсите много сътрудници и дори техните наследници. Mozilla отне години (2001-2006), за да прелицензира Firefox, Thunderbird и свързания софтуер. + +Като алтернатива можете да накарате сътрудниците предварително да одобрят определени промени в лиценза чрез споразумение за допълнителен сътрудник ([вижте по-долу](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Това измества малко сложността на промяната на лицензите. Ще имате нужда от повече помощ от вашите адвокати предварително и все пак ще искате да комуникирате ясно със заинтересованите страни във вашия проект, когато извършвате промяна на лиценза. + +## Моят проект има ли нужда от споразумение за допълнителен сътрудник? + +Вероятно не. За по-голямата част от проектите с отворен код лицензът с отворен код имплицитно служи както за входящ (от сътрудници), така и за изходящ (към други сътрудници и потребители) лиценз. Ако вашият проект е в GitHub, Общите условия на GitHub правят "inbound=outbound" [изрично по подразбиране](https://help.github.com/en/github/site-policy/github-terms-of-service#6-contributions-under-repository-license). + +Допълнително споразумение за сътрудник – често наричано Споразумение за лиценз на сътрудник (CLA) – може да създаде административна работа за поддържащите проекта. Колко работа добавя едно споразумение зависи от проекта и изпълнението. Обикновено споразумение може да изисква сътрудниците да потвърдят с едно щракване, че имат правата, необходими за принос съгласно лиценза за отворен код на проекта. По-сложно споразумение може да изисква правен преглед и подписване от работодателите на сътрудниците. + +Освен това, чрез добавяне на "бумащина", която според някои е ненужна, трудна за разбиране или несправедлива (когато получателят на споразумението получава повече права от сътрудниците или обществеността чрез лиценза за отворен код на проекта), допълнително споразумение за сътрудник може да се възприеме като недружелюбно към общността на проекта. + + + +Някои ситуации, в които може да искате да обмислите споразумение за допълнителен сътрудник за вашия проект, включват: + +* Вашите адвокати искат всички сътрудници изрично да приемат (_подписват_, онлайн или офлайн) условията за принос, може би защото смятат, че самият лиценз за отворен код не е достатъчен (въпреки че е!). Ако това е единствената грижа, споразумение за сътрудник, което потвърждава лиценза за отворен код на проекта, трябва да е достатъчно. [Лицензионното споразумение за jQuery Individual Contributor](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) е добър пример за леко споразумение за допълнителен сътрудник. +* Вие или вашите адвокати искате разработчиците да декларират, че всеки ангажимент, който правят, е разрешен. Изискването за [Сертификат за произход на разработчици](https://developercertificate.org/) е колко проекта постигат това. Например общността Node.js [използва](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) DCO [вместо](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) от техния предишен CLA. Една проста опция за автоматизиране на прилагането на DCO във вашето хранилище е [DCO Probot](https://github.com/probot/dco). +* Вашият проект използва лиценз с отворен код, който не включва изрично предоставяне на патент (като MIT) и се нуждаете от разрешение за патент от всички сътрудници, някои от които може да работят за компании с големи патентни портфейли, които биха могли да бъдат използвани за насочване към вас или други сътрудници и потребители на проекта. [Лицензионното споразумение за личен сътрудник на Apache](https://www.apache.org/licenses/icla.pdf) е често използвано допълнително споразумение за сътрудник, което има предоставяне на патент, отразяващо това, което се намира в Лиценза на Apache 2.0. +* Вашият проект е под лиценз за копиралефт, но също така трябва да разпространявате собствена версия на проекта. Ще трябва всеки сътрудник да ви прехвърли авторски права или да ви предостави (но не на обществеността) разрешителен лиценз. [Споразумението за сътрудник на MongoDB](https://www.mongodb.com/legal/contributor-agreement) е пример за този тип споразумение. +* Смятате, че вашият проект може да се наложи да промени лицензите през целия си живот и искате участниците да се съгласят предварително с такива промени. + +Ако все пак трябва да използвате допълнително споразумение за сътрудници с вашия проект, обмислете използването на интеграция като [CLA помощник](https://github.com/cla-assistant/cla-assistant), за да сведете до минимум разсейването на сътрудниците. + +## Какво трябва да знае правният екип на моята компания? + +Ако пускате проект с отворен код като служител на компанията, първо, вашият правен екип трябва да знае, че сте проект с отворен код. + +За добро или лошо, помислете да ги уведомите дори ако това е личен проект. Вероятно имате "споразумение за интелектуална собственост на служителите" с вашата компания, което им дава известен контрол върху вашите проекти, особено ако изобщо са свързани с бизнеса на компанията или използвате ресурси на компанията за разработване на проекта. Вашата компания _би трябвало_ лесно да ви даде разрешение и може би вече го е направила чрез удобно за служителите IP споразумение или фирмена политика. Ако не, можете да преговаряте (например да обясните, че вашият проект служи на целите на компанията за професионално обучение и развитие за вас) или да избягвате да работите по проекта си, докато не намерите по-добра компания. + +**Ако търсите проект с отворен код за вашата компания**, тогава определено ги уведомете. Вашият правен екип вероятно вече има политики за това какъв лиценз с отворен код (и може би допълнително споразумение за сътрудници) да използва въз основа на бизнес изискванията и експертния опит на компанията за гарантиране, че вашият проект е в съответствие с лицензите на неговите зависимости. Ако не, вие и те имате късмет! Вашият правен екип трябва да е нетърпелив да работи с вас, за да разберете тези неща. Някои неща, за които да помислите: + +* **Материал на трета страна:** Вашият проект има ли зависимости, създадени от други или по друг начин включва или използва чужд код? Ако те са с отворен код, ще трябва да спазвате лицензите за отворен код на материалите. Това започва с избора на лиценз, който работи с лицензи с отворен код на трети страни ([вижте по-горе](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). Ако вашият проект модифицира или разпространява материал с отворен код на трета страна, вашият правен екип също ще иска да знае, че отговаряте на други условия на лицензите за отворен код на трета страна, като запазване на бележки за авторски права. Ако вашият проект използва чужд код, който няма лиценз с отворен код, вероятно ще трябва да помолите поддържащите трети страни да [добавят лиценз с отворен код](https://choosealicense.com/no-license/#for-users), и ако не можете да получите такъв, спрете да използвате техния код във вашия проект. + +* **Търговски тайни:** Помислете дали има нещо в проекта, което компанията не иска да направи достъпно за широката общественост. Ако е така, можете да отворите останалата част от проекта си, след като извлечете материала, който искате да запазите поверителен. + +* **Патенти:** Вашата компания кандидатства ли за патент, за който отвореният код на вашия проект би представлявал [публично разкриване](https://en.wikipedia.org/wiki/Public_disclosure)? За съжаление може да бъдете помолени да изчакате (или може би компанията ще преразгледа разумността на приложението). Ако очаквате принос към вашия проект от служители на компании с големи патентни портфейли, вашият правен екип може да поиска да използвате лиценз с изрично предоставяне на патент от сътрудници (като Apache 2.0 или GPLv3) или допълнително споразумение за сътрудници ([вижте по-горе](#кой-лиценз-с-отворен-код-е-подходящ-за-моя-проект)). + +* **Търговски марки:** Проверете отново дали името на вашия проект [не е в конфликт със съществуващи търговски марки](../starting-a-project/#избягване-на-конфликти-с-имена). Ако използвате търговските марки на собствената си компания в проекта, проверете дали това не предизвиква конфликти. [FOSSmarks](http://fossmarks.org/) е практическо ръководство за разбиране на търговските марки в контекста на безплатни проекти с отворен код. + +* **Поверителност:** Вашият проект събира ли данни за потребители? "Домашен телефон" към фирмени сървъри? Вашият правен екип може да ви помогне да спазвате фирмените политики и външните разпоредби. + +Ако пускате първия проект с отворен код на вашата компания, горното е повече от достатъчно, за да преминете (но не се притеснявайте, повечето проекти не би трябвало да предизвикват големи притеснения). + +В по-дългосрочен план вашият правен екип може да направи повече, за да помогне на компанията да извлече повече от участието си в отворен код и да остане в безопасност: + +* **Правила за приноса на служителите:** Помислете за разработване на корпоративна политика, която определя как вашите служители допринасят за проекти с отворен код. Ясната политика ще намали объркването сред вашите служители и ще им помогне да допринесат за проекти с отворен код в най-добрия интерес на компанията, независимо дали като част от работата им или в свободното им време. Добър пример е [Модел IP и политика за принос с отворен код](https://processmechanics.com/2015/07/23/a-model-ip-and-open-source-contribution-policy/) на Rackspace. + + + +* **Какво да публикувате:** [(Почти) всичко?](http://tom.preston-werner.com/2011/11/22/open-source-everything.html) Ако вашият правен екип разбира и е инвестирани в стратегията на вашата компания за отворен код, те ще могат най-добре да помогнат, вместо да пречат на вашите усилия. +* **Съответствие:** Дори ако вашата компания не пуска проекти с отворен код, тя използва чужд софтуер с отворен код. [Осъзнаването и процесът](https://www.linuxfoundation.org/blog/blog/why-companies-that-use-open-source-need-a-compliance-program/) могат да предотвратят главоболия, забавяния на продукти и съдебни дела . + + + +* **Патенти:** Вашата компания може да пожелае да се присъедини към [Open Invention Network](https://www.openinventionnetwork.com/), споделен защитен патентен пул за защита на използването на големи проекти с отворен код от членовете, или да проучи друго [алтернативно патентно лицензиране](https://www.eff.org/document/hacking-patent-system-2016). +* **Управление:** Особено ако и когато има смисъл да се премести проект към [юридическо лице извън компанията](../leadership-and-governance/#нуждая-ли-се-от-юридическо-лице-което-да-поддържа-моя-проект). diff --git a/_articles/bg/maintaining-balance-for-open-source-maintainers.md b/_articles/bg/maintaining-balance-for-open-source-maintainers.md new file mode 100644 index 00000000000..d6cf1585838 --- /dev/null +++ b/_articles/bg/maintaining-balance-for-open-source-maintainers.md @@ -0,0 +1,220 @@ +--- +lang: bg +untranslated: true +title: Поддържане на баланс за поддържащите отворен код +description: Съвети за самообслужване и избягване на прегаряне като поддържащ. +class: balance +order: 0 +image: /assets/images/cards/maintaining-balance-for-open-source-maintainers.png +--- + +Тъй като популярността на проекта с отворен код нараства, става важно да поставите ясни граници, които да ви помогнат да поддържате баланс, за да останете освежени и продуктивни в дългосрочен план. + +За да придобием представа за опита на поддържащите и техните стратегии за намиране на баланс, проведохме семинар с 40 членове на общността на поддържащите, което ни позволи да се поучат от техния опит от първа ръка с бърнаут в отворен код и практиките, които са им помогнали да поддържат баланс в работата си. Тук влиза в действие концепцията за лична екология. + +И така, какво е лична екология? Като описано от Rockwood Leadership Institute, то включва "поддържане на баланс, темпо и ефективност за поддържане на енергията ни през целия живот." Това рамкира нашите разговори, помагайки на поддържащите да разпознаят своите действия и приноси като части от по-голяма екосистема, която се развива с течение на времето. Бърнаут, синдром в резултат на хроничен стрес на работното място, както [дефиниран от СЗО](https://icd.who.int/browse11/l-m/en#/http://id.who.int/icd/entity/129180281) , не е необичайно сред поддържащите. Това често води до загуба на мотивация, невъзможност за фокусиране и липса на съпричастност към сътрудниците и общността, с която работите. + + + +Възприемайки концепцията за лична екология, поддържащите могат проактивно да избягват прегарянето, да дават приоритет на грижата за себе си и да поддържат чувство за баланс, за да вършат най-добрата си работа. + +## Съвети за самообслужване и избягване на прегаряне като поддържащ персонал: + +### Определете вашите мотивации за работа с отворен код + +Отделете време, за да помислите кои части от поддръжката с отворен код ви зареждат с енергия. Разбирането на вашата мотивация може да ви помогне да приоритизирате работата по начин, който ви държи ангажирани и готови за нови предизвикателства. Независимо дали става въпрос за положителната обратна връзка от потребителите, радостта от сътрудничеството и общуването с общността или удовлетворението от гмуркането в кода, разпознаването на вашите мотивации може да ви помогне да насочите фокуса си. + +### Помислете какво ви кара да излизате от баланс и да сте стресирани + +Важно е да разберем какво ни кара да изгаряме. Ето няколко общи теми, които видяхме сред поддържащите отворен код: + +* **Липса на положителна обратна връзка:** Много по-вероятно е потребителите да се свържат, когато имат оплакване. Ако всичко работи добре, те са склонни да мълчат. Може да е обезкуражаващо да видите нарастващ списък от проблеми без положителната обратна връзка, показваща как вашият принос прави разликата. + + + +* **Да не казваш "не":** Може да е лесно да поемеш повече отговорности, отколкото би трябвало за проект с отворен код. Независимо дали е от потребители, сътрудници или други поддържащи – ние не винаги можем да оправдаем техните очаквания. + + + +* **Да работиш сам:** Да си поддържащ може да бъде невероятно самотен. Дори ако работите с група поддържащи, последните няколко години бяха трудни за свикване на разпределени екипи лично. + + + +* **Няма достатъчно време или ресурси:** Това е особено вярно за поддържащи доброволци, които трябва да жертват свободното си време, за да работят по проект. + + + +* **Противоречиви изисквания:** Отвореният код е пълен с групи с различни мотивации, които могат да бъдат трудни за ориентиране. Ако ви се плаща да работите с отворен код, интересите на вашия работодател понякога могат да бъдат в противоречие с общността. + + + +### Внимавайте за признаци на прегаряне + +Можете ли да поддържате темпото си 10 седмици? 10 месеца? 10 години? + +Има инструменти като [Burnout Checklist](https://governingopen.com/resources/signs-of-burnout-checklist.html) от [@shaunagm](https://github.com/shaunagm), които могат да ви помогнат помислете върху текущото си темпо и вижте дали има някакви корекции, които можете да направите. Някои поддържащи също използват технология за носене, за да проследяват показатели като качество на съня и променливост на сърдечната честота (и двете свързани със стреса). + + + +### От какво се нуждаете, за да продължите да поддържате себе си и общността си? + +Това ще изглежда различно за всеки поддържащ и ще се променя в зависимост от вашата фаза от живота и други външни фактори. Но ето няколко теми, които чухме: + +* **Разчитайте на общността:** Делегирането и намирането на сътрудници може да облекчи работното натоварване. Наличието на множество точки за контакт за даден проект може да ви помогне да си починете, без да се притеснявате. Свържете се с други поддържащи и по-широката общност – в групи като [Maintainer Community](http://maintainers.github.com/). Това може да бъде чудесен ресурс за партньорска подкрепа и обучение. + + Можете също така да търсите начини да се ангажирате с потребителската общност, така че да можете редовно да чувате обратна връзка и да разбирате въздействието на вашата работа с отворен код. + +* **Разгледайте финансирането:** Независимо дали търсите малко пари за пица или се опитвате да преминете на пълен работен ден към отворен код, има много ресурси, които да ви помогнат! Като първа стъпка помислете дали да не включите [Спонсорите на GitHub](https://github.com/sponsors), за да позволите на други да спонсорират вашата работа с отворен код. Ако обмисляте да преминете към пълен работен ден, кандидатствайте за следващия кръг на [GitHub Accelerator](http://accelerator.github.com/). + + + +* **Използвайте инструменти:** Разгледайте инструменти като [GitHub Copilot](https://github.com/features/copilot/) и [GitHub Actions](https://github.com/features/actions), за да автоматизирате светски задачи и освободете времето си за по-значими приноси. + + + +* **Почивка и презареждане:** Отделете време за вашите хобита и интереси извън отворен код. Вземете почивни дни, за да се отпуснете и да се подмладите – и задайте своя [статус в GitHub](https://docs.github.com/account-and-profile/setting-up-and-managing-your-github-profile/customizing-your-profile/personalizing-your-profile#setting-a-status), за да отразява вашата наличност! Добрият нощен сън може да направи голяма разлика в способността ви да поддържате усилията си в дългосрочен план. + + Ако намирате определени аспекти от вашия проект за особено приятни, опитайте се да структурирате работата си, така че да можете да я изживявате през целия си ден. + + + +* **Задайте граници:** Не можете да кажете "да" на всяка молба. Това може да бъде толкова просто, колкото да кажете: "Не мога да стигна до това в момента и нямам планове за бъдещето" или да посочите какво искате да правите и какво да не правите в README. Например, можете да кажете: "Аз обединявам само PR-и, които имат ясно изброени причини, поради които са направени", или "Преглеждам проблемите само в четвъртък от 18 до 19 часа". Това определя очакванията за другите и ви дава нещо да посочите в други моменти, за да помогнете за намаляване на изискванията от сътрудници или потребители във вашето време. + + + + Научете се да сте твърди в спирането на токсичното поведение и негативните взаимодействия. Добре е да не давате енергия на неща, които не ви интересуват. + + + + + +Не забравяйте, че личната екология е постоянна практика, която ще се развива, докато напредвате във вашето пътуване с отворен код. Като приоритизирате грижата за себе си и поддържате чувството за баланс, можете да допринесете за общността с отворен код ефективно и устойчиво, гарантирайки както вашето благополучие, така и успеха на вашите проекти в дългосрочен план. + +## Допълнителни ресурси + +* [Maintainer Community](http://maintainers.github.com/) +* [The social contract of open source](https://snarky.ca/the-social-contract-of-open-source/), Brett Cannon +* [Uncurled](https://daniel.haxx.se/uncurled/), Daniel Stenberg +* [How to deal with toxic people](https://www.youtube.com/watch?v=7lIpP3GEyXs), Gina Häußge +* [SustainOSS](https://sustainoss.org/) +* [Rockwood Art of Leadership](https://rockwoodleadership.org/art-of-leadership/) +* [Saying No](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=Saying%20No%20%7C%20Mike%20McQuaid), Mike McQuaid +* [Governing Open](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,Governance%20of%20Open%20Source%20Software,-governingopen.com) +* Workshop agenda was remixed from [Mozilla's Movement Building from Home](https://docs.google.com/document/d/1esQQBJXQi1x_-1AcRVPiCRAEQYO4Qlvali0ylCvKa_s/edit?pli=1#:~:text=a%20mixed%20list.-,It%E2%80%99s%20a%20wrap%3A%20Movement%2DBuilding%20from%20Home,-foundation.mozilla.org) series + +## Сътрудници + +Много благодаря на всички поддържащи, които споделиха своя опит и съвети с нас за това ръководство! + +Това ръководство е написано от [@abbycabs](https://github.com/abbycabs) с принос от: + +[@agnostic-apollo](https://github.com/agnostic-apollo) +[@AndreaGriffiths11](https://github.com/AndreaGriffiths11) +[@antfu](https://github.com/antfu) +[@anthonyronda](https://github.com/anthonyronda) +[@CBID2](https://github.com/CBID2) +[@Cli4d](https://github.com/Cli4d) +[@confused-Techie](https://github.com/confused-Techie) +[@danielroe](https://github.com/danielroe) +[@Dexters-Hub](https://github.com/Dexters-Hub) +[@eddiejaoude](https://github.com/eddiejaoude) +[@Eugeny](https://github.com/Eugeny) +[@ferki](https://github.com/ferki) +[@gabek](https://github.com/gabek) +[@geromegrignon](https://github.com/geromegrignon) +[@hynek](https://github.com/hynek) +[@IvanSanchez](https://github.com/IvanSanchez) +[@karasowles](https://github.com/karasowles) +[@KoolTheba](https://github.com/KoolTheba) +[@leereilly](https://github.com/leereilly) +[@ljharb](https://github.com/ljharb) +[@nightlark](https://github.com/nightlark) +[@plarson3427](https://github.com/plarson3427) +[@Pradumnasaraf](https://github.com/Pradumnasaraf) +[@RichardLitt](https://github.com/RichardLitt) +[@rrousselGit](https://github.com/rrousselGit) +[@sansyrox](https://github.com/sansyrox) +[@schlessera](https://github.com/schlessera) +[@shyim](https://github.com/shyim) +[@smashah](https://github.com/smashah) +[@ssalbdivad](https://github.com/ssalbdivad) +[@The-Compiler](https://github.com/The-Compiler) +[@thehale](https://github.com/thehale) +[@thisisnic](https://github.com/thisisnic) +[@tudoramariei](https://github.com/tudoramariei) +[@UlisesGascon](https://github.com/UlisesGascon) +[@waldyrious](https://github.com/waldyrious) + много други! diff --git a/_articles/bg/metrics.md b/_articles/bg/metrics.md new file mode 100644 index 00000000000..47b617ee8dc --- /dev/null +++ b/_articles/bg/metrics.md @@ -0,0 +1,128 @@ +--- +lang: bg +title: Показатели за отворен код +description: Вземете информирани решения, за да помогнете на вашия проект с отворен код да процъфтява, като измервате и проследявате неговия успех. +class: metrics +order: 9 +image: /assets/images/cards/metrics.png +related: + - finding + - best-practices +--- + +## Защо да измервате нещо? + +Данните, когато се използват разумно, могат да ви помогнат да вземете по-добри решения като поддържащ отворен код. + +С повече информация можете: + +* Разберете как потребителите реагират на нова функция +* Разберете откъде идват новите потребители +* Идентифицирайте и решете дали да поддържате извънреден случай на употреба или функционалност +* Определете количествено популярността на вашия проект +* Разберете как се използва вашият проект +* Събирайте пари чрез спонсорства и безвъзмездни средства + +Например [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Analytics.md) открива, че Google Анализ им помага да приоритизират работата: + +> Homebrew се предоставя безплатно и се управлява изцяло от доброволци в свободното им време. В резултат на това нямаме ресурсите да направим подробни потребителски проучвания на потребителите на Homebrew, за да решим как най-добре да проектираме бъдещи функции и да дадем приоритет на текущата работа. Анонимните обобщени потребителски анализи ни позволяват да приоритизираме поправки и функции въз основа на това как, къде и кога хората използват Homebrew. + +Популярността не е всичко. Всеки влиза в отворен код по различни причини. Ако целта ви като поддържащ отворен код е да покажете работата си, да сте прозрачни относно кода си или просто да се забавлявате, показателите може да не са важни за вас. + +Ако се интересувате от разбирането на вашия проект на по-дълбоко ниво, прочетете за начини да анализирате дейността на вашия проект. + +## Откритие + +Преди някой да може да използва или да допринесе обратно за вашия проект, той трябва да знае, че той съществува. Запитайте се: _хората намират ли този проект?_ + +![Графика на трафика](/assets/images/metrics/repo_traffic_graphs_tooltip.png) + +Ако вашият проект се хоства в GitHub, [можете да видите](https://help.github.com/articles/about-repository-graphs/#traffic) колко хора попадат на вашия проект и откъде идват. От страницата на вашия проект щракнете върху "Прозрения", след това върху "Трафик". На тази страница можете да видите: + +* **Общ брой показвания на страници:** Ви казва колко пъти е бил прегледан вашият проект + +* **Общ брой уникални посетители:** Ви казва колко души са видели проекта Ви + +* **Препоръчващи сайтове:** Ви казва откъде идват посетителите. Този показател може да ви помогне да разберете къде да достигнете до аудиторията си и дали усилията ви за промоция работят. + +* **Популярно съдържание:** Ви казва къде отиват посетителите във вашия проект, разбити по показвания на страници и уникални посетители. + +[Звездите на GitHub](https://help.github.com/articles/about-stars/) също могат да помогнат за предоставяне на основна мярка за популярност. Въпреки че звездите на GitHub не са непременно свързани с изтегляния и използване, те могат да ви кажат колко хора обръщат внимание на работата ви. + +Може също да искате да [проследите откриваемостта на конкретни места](https://opensource.com/business/16/6/pirate-metrics): например Google PageRank, трафик от препоръчани потребители от уебсайта на вашия проект или препоръчани потребители от други отворени изходни проекти или уебсайтове. + +## Използване + +Хората намират вашия проект в това диво и лудо нещо, което наричаме интернет. В идеалния случай, когато видят вашия проект, те ще се почувстват принудени да направят нещо. Вторият въпрос, който ще искате да зададете е: _хората използват ли този проект?_ + +Ако използвате мениджър на пакети, като npm или RubyGems.org, за разпространение на вашия проект, може да сте в състояние да проследявате изтеглянията на вашия проект. + +Всеки мениджър на пакети може да използва малко по-различна дефиниция на "изтегляне" и изтеглянията не са непременно свързани с инсталиранията или използването, но предоставя някаква базова линия за сравнение. Опитайте да използвате [Libraries.io](https://libraries.io/), за да проследявате статистическите данни за използването в много популярни мениджъри на пакети. + +Ако вашият проект е в GitHub, отворете отново страницата "Трафик". Можете да използвате [графиката за клониране](https://github.com/blog/1873-clone-graphs), за да видите колко пъти вашият проект е бил клониран за даден ден, разбити на общия брой клонинги и уникални клонинги. + +![Графика за клониране](/assets/images/metrics/clone_graph.png) + +Ако употребата е ниска в сравнение с броя на хората, които са открили вашия проект, трябва да имате предвид два проблема. Или: + +* Вашият проект не преобразува успешно вашата аудитория, или +* Привличате грешната аудитория + +Например, ако вашият проект попадне на първа страница на Hacker News, вероятно ще видите скок в откриването (трафик), но по-нисък процент на реализация, защото достигате до всички в Hacker News. Ако обаче вашият Ruby проект бъде представен на Ruby конференция, е по-вероятно да видите висок процент на реализация от целева аудитория. + +Опитайте се да разберете откъде идва вашата аудитория и помолете другите за обратна връзка на страницата на вашия проект, за да разберете с кой от тези два проблема се сблъсквате. + +След като разберете, че хората използват вашия проект, може да искате да опитате да разберете какво правят с него. Надграждат ли го, като разклоняват вашия код и добавят функции? Използват ли го за наука или за бизнес? + +## Задържане + +Хората намират вашия проект и го използват. Следващият въпрос, който ще искате да си зададете, е: _хората допринасят ли обратно за този проект?_ + +Никога не е твърде рано да започнете да мислите за сътрудници. Без други хора да се намесят, рискувате да се поставите в нездравословна ситуация, в която вашият проект е _популярен_ (много хора го използват), но не е _поддържан_ (няма достатъчно време за поддръжка, за да отговори на търсенето). + +Задържането също така изисква [приток на нови сътрудници](http://blog.abigailcabunoc.com/increasing-developer-engagement-at-mozilla-science-learning-advocacy#contributor-pathways_2), тъй като предишните активни сътрудници в крайна сметка ще продължат напред към други неща. + +Примери за показатели на общността, които може да искате да проследявате редовно, включват: + +* **Общ брой сътрудници и брой ангажименти на сътрудник:** Ви казва колко сътрудници имате и кой е повече или по-малко активен. В GitHub можете да видите това под "Прозрения" -> "Сътрудници". В момента тази графика отчита само сътрудници, които са се ангажирали с клона по подразбиране на хранилището. + +![Графика на сътрудник](/assets/images/metrics/repo_contributors_specific_graph.png) + +* **Първи, случайни и повторни сътрудници:** Помага ви да проследите дали получавате нови сътрудници и дали те се връщат. (Случайните сътрудници са сътрудници с малък брой ангажименти. Дали това е един комит, по-малко от пет ангажимента или нещо друго зависи от вас.) Без нови сътрудници общността на вашия проект може да изпадне в застой. + +* **Брой отворени проблеми и отворени заявки за изтегляне:** Ако тези числа станат твърде високи, може да се нуждаете от помощ при сортирането на проблеми и прегледите на кода. + +* **Брой _отворени_ проблеми и _отворени_ заявки за изтегляне:** Отворените проблеми означават, че някой се интересува достатъчно от вашия проект, за да отвори проблем. Ако този брой се увеличи с течение на времето, това предполага, че хората се интересуват от вашия проект. + +* **Видове приноси:** Например ангажименти, коригиране на правописни грешки или грешки или коментиране на проблем. + + + +## Поддържаща дейност + +И накрая, ще искате да затворите цикъла, като се уверите, че поддържащите вашия проект са в състояние да се справят с обема на получените вноски. Последният въпрос, който ще искате да си зададете е: _отговарям ли (или ние) на нашата общност?_ + +Неотзивчивите поддържащи се превръщат в пречка за проекти с отворен код. Ако някой изпрати принос, но никога не получи отговор от поддържащия, той може да се почувства обезсърчен и да напусне. + +[Изследване от Mozilla](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) предполага, че отзивчивостта на поддържащия е критичен фактор за насърчаване на повтарящи се приноси. + +Помислете за [проследяване колко време отнема на вас (или на друг поддържащ) да отговорите на приносите](https://github.blog/2023-07-19-metrics-for-issues-pull-requests-and-discussions/), дали проблем или заявка за изтегляне. Отговорът не изисква предприемане на действие. Може да бъде толкова просто, колкото да кажете: _"Благодаря за вашето изпращане! Ще прегледам това през следващата седмица."_ + +Можете също да измерите времето, необходимо за преминаване между етапите в процеса на принос, като например: + +* Средно време, през което проблемът остава отворен +* Дали проблемите се затварят от PRте +* Дали остарелите проблеми се затварят +* Средно време за обединяване на заявка за изтегляне + +## Използвайте 📊, за да научите за хората + +Разбирането на показателите ще ви помогне да изградите активен, разрастващ се проект с отворен код. Дори и да не проследявате всеки показател на таблото за управление, използвайте рамката по-горе, за да фокусирате вниманието си върху типа поведение, което ще помогне на вашия проект да процъфтява. + +[CHAOSS](https://chaoss.community/) е гостоприемна общност с отворен код, фокусирана върху анализи, показатели и софтуер за здравето на общността. diff --git a/_articles/bg/starting-a-project.md b/_articles/bg/starting-a-project.md new file mode 100644 index 00000000000..78b5be61f7b --- /dev/null +++ b/_articles/bg/starting-a-project.md @@ -0,0 +1,356 @@ +--- +lang: bg +title: Стартиране на проект с отворен код +description: Научете повече за света на отворения код и се пригответе да стартирате свой собствен проект. +class: beginners +order: 2 +image: /assets/images/cards/beginner.png +related: + - finding + - building +--- + +## "Какво" и "защо" на отворения код + +Значи обмисляте да започнете с отворен код? Честито! Светът оценява вашия принос. Нека поговорим какво е отворен код и защо хората го правят. + +### Какво означава "отворен код"? + +Когато даден проект е с отворен код, това означава, че **всеки е свободен да използва, изучава, променя и разпространява вашия проект за всякакви цели.** Тези разрешения се прилагат чрез [лиценз за отворен код](https://opensource.org/licenses). + +Отвореният код е мощен, защото намалява бариерите пред приемането и сътрудничеството, позволявайки на хората да разпространяват и подобряват проекти бързо. Също така защото дава на потребителите потенциал да контролират собствените си компютри, в сравнение със затворения код. Например, бизнес, използващ софтуер с отворен код, има опцията да наеме някой, който да направи персонализирани подобрения на софтуера, вместо да разчита изключително на продуктовите решения на доставчик със затворен код. + +_Свободен софтуер_ се отнася до същия набор от проекти като _отворен код_. Понякога също така ще видите [тези термини](https://en.wikipedia.org/wiki/Free_and_open-source_software) комбинирани като "свободен софтуер с отворен код" (FOSS) или "безплатен софтуер с отворен код" (FLOSS). _Безплатно_ и _libre_ се отнасят за свободата, [не за цената](#отворен-код-означава-ли-безплатно). + +### Защо хората отварят кода на работата си? + + + +[Има много причини](https://ben.balter.com/2015/11/23/why-open-source/), поради които дадено лице или организация би искала да отвори проект с отворен код. Някои примери включват: + +* **Сътрудничество:** Проектите с отворен код могат да приемат промени от всеки по света. [Exercism](https://github.com/exercism/), например, е платформа за упражнения по програмиране с над 350 участници. + +* **Приемане и ремиксиране:** Проектите с отворен код могат да се използват от всеки за почти всякакви цели. Хората дори могат да го използват за изграждане на други неща. [WordPress](https://github.com/WordPress), например, стартира като разклонение на съществуващ проект, наречен [b2](https://github.com/WordPress/book/blob/HEAD/Content/Part%201/2-b2-cafelog.md). + +* **Прозрачност:** Всеки може да провери проект с отворен код за грешки или несъответствия. Прозрачността има значение за правителства като [България](https://medium.com/@bozhobg/bulgaria-got-a-law-requiring-open-source-98bf626cf70a) или [Съединените щати](https://sourcecode.cio.gov/), регулирани отрасли като банкиране или здравеопазване и софтуер за сигурност като [Да шифроваме](https://github.com/letsencrypt). + +Отвореният код също не е само за софтуер. Можете да отворите всичко - от набори от данни до книги. Разгледайте [GitHub Explore](https://github.com/explore) за идеи какво още можете да отворите. + +### Отворен код означава ли "безплатно"? + +Едно от най-големите предимства на отворения код е, че не струва пари. "Безплатно" обаче е страничен продукт от общата стойност на отворения код. + +Тъй като [лицензът с отворен код изисква](https://opensource.org/definition-annotated/) всеки да може да използва, променя и споделя вашия проект за почти всякакви цели, самите проекти обикновено са безплатни. Ако използването на проекта струва пари, всеки може законно да направи копие и вместо това да използва безплатната версия. + +В резултат на това повечето проекти с отворен код са безплатни, но "безплатно" не е част от определението за отворен код. Има начини за таксуване за проекти с отворен код индиректно чрез двойно лицензиране или ограничени функции, като същевременно се спазва официалното определение за отворен код. + +## Трябва ли да стартирам собствен проект с отворен код? + +Краткият отговор е да, защото независимо от резултата, стартирането на собствен проект е чудесен начин да научите как работи отвореният код. + +Ако никога преди не сте отваряли проект с отворен код, може да се притеснявате какво ще кажат хората или дали някой изобщо ще забележи. Ако това звучи като вас, не сте сами! + +Работата с отворен код е като всяка друга творческа дейност, независимо дали е писане или рисуване. Може да ви е страшно да споделяте работата си със света, но единственият начин да станете по-добри е да практикувате – дори и да нямате публика. + +Ако все още не сте убедени, отделете малко време, за да помислите какви може да са вашите цели. + +### Поставяне на вашите цели + +Целите могат да ви помогнат да разберете върху какво да работите, на какво да кажете "не" и къде имате нужда от помощ от другите. Започнете, като се запитате _защо използвам този проект с отворен код?_ + +Няма един правилен отговор на този въпрос. Може да имате множество цели за един проект или различни проекти с различни цели. + +Ако единствената ви цел е да покажете работата си, може дори да не искате принос и дори да го кажете във вашия README. От друга страна, ако искате сътрудници, ще инвестирате време в ясна документация и ще накарате новодошлите да се почувстват добре дошли. + + + +С разрастването на проекта ви, общността ви може да се нуждае от нещо повече от код - от вас. Отговарянето на проблеми, прегледът на кода и евангелизирането на вашия проект са важни задачи в проект с отворен код. + +Макар че времето, което отделяте за задачи, които не са свързани с кодиране, ще зависи от размера и обхвата на вашия проект, вие трябва да сте подготвени като поддържащ да се справите с тях сами или да намерите някой, който да ви помогне. + +**Ако сте част от компания, предлагаща проект с отворен код,** се уверете, че вашият проект разполага с необходимите вътрешни ресурси, за да процъфтява. Ще искате да определите кой е отговорен за поддържането на проекта след стартирането и как ще споделите тези задачи с вашата общност. + +Ако имате нужда от специален бюджет или персонал за промоция, операции и поддържане на проекта, започнете тези разговори отрано. + + + +### Принос към други проекти + +Ако целта ви е да научите как да си сътрудничите с други или да разберете как работи отворен код, помислете дали да допринесете за съществуващ проект. Започнете с проект, който вече използвате и харесвате. Приносът към проект може да бъде толкова прост, колкото коригиране на правописни грешки или актуализиране на документация. + +Ако не сте сигурни как да започнете като сътрудник, вижте нашето [Как да допринесете за ръководство с отворен код](../how-to-contribute/). + +## Стартиране на ваш собствен проект с отворен код + +Няма идеално време за отваряне на вашата работа. Можете да отворите кода на идея, в процес на работа или след години на затворен код. + +Най-общо казано, трябва да отворите своя проект, когато се чувствате комфортно другите да гледат и дават обратна връзка за работата ви. + +Без значение на кой етап решите да отворите проекта си, всеки проект трябва да включва следната документация: + +* [Open source license](https://help.github.com/articles/open-source-licensing/#where-does-the-license-live-on-my-repository) +* [README](https://help.github.com/articles/create-a-repo/#commit-your-first-change) +* [Contributing guidelines](https://help.github.com/articles/setting-guidelines-for-repository-contributors/) +* [Code of conduct](../code-of-conduct/) + +Като поддържащ, тези компоненти ще ви помогнат да съобщите очакванията, да управлявате приносите и да защитите законните права на всички (включително вашите собствени). Те значително увеличават шансовете ви за положително преживяване. + +Ако вашият проект е в GitHub, поставянето на тези файлове в основната ви директория с препоръчаните файлови имена ще помогне на GitHub да ги разпознае и автоматично да ги покаже на вашите читатели. + +### Избор на лиценз + +Лицензът с отворен код гарантира, че други могат да използват, копират, модифицират и допринасят обратно към вашия проект без последствия. Освен това ви предпазва от трудни правни ситуации. **Трябва да включите лиценз, когато стартирате проект с отворен код.** + +Легалната работа не е забавна. Добрата новина е, че можете да копирате и поставите съществуващ лиценз във вашето хранилище. Ще отнеме само минута, за да защитите упоритата си работа. + +[MIT](https://choosealicense.com/licenses/mit/), [Apache 2.0](https://choosealicense.com/licenses/apache-2.0/) и [GPLv3](https://choosealicense.com/licenses/gpl-3.0/) са най-популярните лицензи с отворен код, но [има и други опции](https://choosealicense.com), от които да избирате. + +Когато създавате нов проект в GitHub, ви се дава възможност да изберете лиценз. Включването на лиценз с отворен код ще направи вашия проект GitHub отворен код. + +![Изберете лиценз](/assets/images/starting-a-project/repository-license-picker.png) + +Ако имате други въпроси или притеснения относно правните аспекти на управлението на проект с отворен код, [ние ще ви покрием](../legal/). + +### Напишете README + +README правят повече от това да обяснят как да използвате вашия проект. Те също така обясняват защо вашият проект има значение и какво могат да правят вашите потребители с него. + +В README опитайте да отговорите на следните въпроси: + +* Какво прави този проект? +* Защо този проект е полезен? +* Как да започна? +* Къде мога да получа повече помощ, ако имам нужда от нея? + +Можете да използвате вашия README, за да отговорите на други въпроси, като например как се справяте с приносите, какви са целите на проекта и информация за лицензи и приписване. Ако не искате да приемате принос или вашият проект все още не е готов за производство, запишете тази информация. + + + +Понякога хората избягват да пишат README, защото смятат, че проектът е незавършен или не искат приноси. Всичко това са много добри причини да напиша такъв. + +За повече вдъхновение опитайте да използвате [ръководството "Направете README" на @dguo](https://www.makeareadme.com/) или [шаблона README](https://gist.github.com/PurpleBooth/109311bb0361f32d87a2) на @PurpleBooth за да напишете пълен README. + +Когато включите файл README в основната директория, GitHub автоматично ще го покаже на началната страница на хранилището. + +### Напишете вашите указания за принос + +CONTRIBUTING файл казва на вашата публика как да участва във вашия проект. Например можете да включите информация за: + +* Как да подадете доклад за грешка (опитайте да използвате [шаблони за заявка за проблем и изтегляне](https://github.com/blog/2111-issue-and-pull-request-templates)) +* Как да предложим нова функция +* Как да настроите вашата среда и да стартирате тестове + +В допълнение към техническите подробности, файлът CONTRIBUTING е възможност да съобщите вашите очаквания за приноси, като например: + +* Типовете приноси, които търсите +* Вашата пътна карта или визия за проекта +* Как сътрудниците трябва (или не трябва) да се свързват с вас + +Използването на топъл, приятелски тон и предлагането на конкретни предложения за принос (като например писане на документация или създаване на уебсайт) може да помогне много на новодошлите да се почувстват добре дошли и развълнувани да участват. + +Например [Active Admin](https://github.com/activeadmin/activeadmin/) започва [своето ръководство за принос](https://github.com/activeadmin/activeadmin/blob/HEAD/CONTRIBUTING.md) с: + +> Първо, благодаря ви, че обмислихте да допринесете за Active Admin. Именно хора като вас правят Active Admin толкова страхотен инструмент. + +В най-ранните етапи на вашия проект, вашият CONTRIBUTING файл може да бъде прост. Винаги трябва да обяснявате как да докладвате бъгове или проблеми с файлове, както и всякакви технически изисквания (като тестове), за да направите принос. + +С течение на времето може да добавите други често задавани въпроси към вашия CONTRIBUTING файл. Записването на тази информация означава, че по-малко хора ще ви задават едни и същи въпроси отново и отново. + +За повече помощ при писането на вашия CONTRIBUTING файл вижте @nayafia [шаблон за ръководство за допринасяне](https://github.com/nayafia/contributing-template/blob/HEAD/CONTRIBUTING-template.md) или @mozilla ["Как да Създайте CONTRIBUTING.md"](https://mozillascience.github.io/working-open-workshop/contributing/). + +Връзка към вашия ПРИНОСЕН файл от вашия README, така че повече хора да го видят. Ако [поставите файла CONTRIBUTING в хранилището на вашия проект](https://help.github.com/articles/setting-guidelines-for-repository-contributors/), GitHub автоматично ще се свърже с вашия файл, когато участник създаде проблем или отваря заявка за изтегляне. + +![Указания за принос](/assets/images/starting-a-project/Contributing-guidelines.jpg) + +### Създаване на кодекс на поведение + + + +И накрая, кодексът на поведение помага да се определят основните правила за поведение на участниците във вашия проект. Това е особено ценно, ако стартирате проект с отворен код за общност или компания. Кодексът на поведение ви дава възможност да улесните здравословното, конструктивно поведение в общността, което ще намали стреса ви като поддържащ. + +За повече информация вижте нашето [Ръководство за кодекс на поведение](../code-of-conduct/). + +В допълнение към комуникацията _как_ очаквате да се държат участниците, кодексът за поведение също има тенденция да описва към кого се отнасят тези очаквания, кога се прилагат и какво да направите, ако възникне нарушение. + +Подобно на лицензите с отворен код, има и нововъзникващи стандарти за кодекси за поведение, така че не е нужно да пишете свои собствени. [Споразумението на сътрудниците](https://contributor-covenant.org/) е код за поведение, който се използва от [над 40 000 проекта с отворен код](https://www.contributor-covenant.org/adopters), включително Kubernetes, Rails и Swift. Без значение кой текст използвате, трябва да сте готови да наложите своя кодекс на поведение, когато е необходимо. + +Поставете текста директно във файл CODE_OF_CONDUCT във вашето хранилище. Съхранявайте файла в главната директория на вашия проект, за да е лесен за намиране, и свържете към него от вашия README. + +## Наименуване и брандиране на вашия проект + +Брандирането е повече от крещящо лого или закачливо име на проект. Става въпрос за това как говорите за вашия проект и до кого достигате с вашето послание. + +### Избор на правилното име + +Изберете име, което е лесно за запомняне и в идеалния случай дава някаква представа какво прави проектът. Например: + +* [Sentry](https://github.com/getsentry/sentry) следи приложенията за докладване на сривове +* [Thin](https://github.com/macournoyer/thin) е бърз и лесен Ruby уеб сървър + +Ако надграждате върху съществуващ проект, използването на тяхното име като префикс може да ви помогне да изясните какво прави вашият проект (например [node-fetch](https://github.com/bitinn/node-fetch) носи `window .fetch` към Node.js). + +Помислете за яснотата преди всичко. Каламбурите са забавни, но не забравяйте, че някои вицове може да не се преведат в други култури или хора с различен опит от вашия. Някои от вашите потенциални потребители може да са служители на компанията: не искате да ги карате да се чувстват неудобно, когато трябва да обясняват вашия проект по време на работа! + +### Избягване на конфликти с имена + +[Проверете за проекти с отворен код с подобно име](http://ivantomic.com/projects/ospnc/), особено ако споделяте същия език или екосистема. Ако името ви се припокрива с популярен съществуващ проект, може да объркате аудиторията си. + +Ако искате уебсайт, Twitter манипулатор или други свойства да представляват вашия проект, уверете се, че можете да получите имената, които искате. В идеалния случай [запазете тези имена сега](https://instantdomainsearch.com/) за спокойствие, дори ако все още не възнамерявате да ги използвате. + +Уверете се, че името на вашия проект не нарушава никакви търговски марки. Една компания може да поиска от вас да премахнете проекта си по-късно или дори да предприеме съдебни действия срещу вас. Просто не си струва риска. + +Можете да проверите [WIPO Global Brand Database](http://www.wipo.int/branddb/en/) за конфликти на търговски марки. Ако сте в компания, това е едно от нещата, с които вашият [правен екип може да ви помогне](../legal/). + +И накрая, направете бързо търсене в Google за името на вашия проект. Ще могат ли хората лесно да намерят вашия проект? Показва ли се нещо друго в резултатите от търсенето, което не бихте искали да виждат? + +### Как пишете (и кодирате) също влияе върху вашата марка! + +През целия живот на вашия проект ще пишете много: README, уроци, документи на общността, отговаряне на проблеми, може би дори бюлетини и пощенски списъци. + +Независимо дали става въпрос за официална документация или случаен имейл, вашият стил на писане е част от марката на вашия проект. Помислете как бихте могли да възприемете публиката си и дали това е тонът, който искате да предадете. + + + +Използването на топъл, приобщаващ език (като "тях", дори когато се отнася до един човек) може много да помогне на вашия проект да се почувства добре дошъл за новите сътрудници. Придържайте се към простия език, тъй като много от вашите читатели може да не са носители на английски език. + +Освен начина, по който пишете думи, вашият стил на кодиране може също да стане част от марката на вашия проект. [Angular](https://angular.io/guide/styleguide) и [jQuery](https://contribute.jquery.org/style-guide/js/) са два примера за проекти със строги стилове и насоки за кодиране. + +Не е необходимо да пишете стилово ръководство за вашия проект, когато току-що започвате, и може да откриете, че така или иначе ви харесва да включвате различни стилове на кодиране във вашия проект. Но трябва да предвидите как вашият стил на писане и кодиране може да привлече или обезсърчи различни типове хора. Най-ранните етапи на вашия проект са вашата възможност да създадете прецедента, който искате да видите. + +## Вашият контролен списък преди стартиране + +Готови ли сте да отворите вашия проект? Ето контролен списък за помощ. Поставете отметка във всички квадратчета? Готови сте за работа! [Щракнете върху "публикувай"](https://help.github.com/articles/making-a-private-repository-public/) и се потупайте по рамото. + +**Документация** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Код** + +
+ + +
+ +
+ + +
+ +
+ + +
+ +**Хора** + +Ако сте физическо лице: + +
+ + +
+ +Ако сте компания или организация: + +
+ + +
+ +
+ + +
+ +
+ + +
+ +
+ + +
+ +## Направи го! + +Поздравления за първия ви проект с отворен код. Без значение от резултата, публичната работа е дар за общността. С всеки ангажимент, коментар и заявка за изтегляне вие създавате възможности за себе си и за другите да се учат и да растат. diff --git a/_data/locales/bg.yml b/_data/locales/bg.yml new file mode 100644 index 00000000000..f2b963f522f --- /dev/null +++ b/_data/locales/bg.yml @@ -0,0 +1,31 @@ +en: + locale_name: Български + nav: + about: Относно нас + contribute: Допринеси + index: + lead: Софтуерът с отворен код е създаден от хора точно като теб. Научи как да стартираш и развиеш своя проект. + opensourcefriday: Петък е! Инвестирай няколко часа, като допринесеш за софтуера, който използвате и обичате + article: + table_of_contents: Съдържание + back_to_all_guides: Назад към всички ръководства + related_guides: Свързани ръководства + footer: + contribute: + heading: Допринеси + description: Искате ли да направите предложение? Това съдържание е с отворен код. Помогнете ни да го подобрим. + button: Допринеси + subscribe: + heading: Поддържай връзка + description: Бъди първите, който ще научи за най-новите съвети и ресурси с отворен код на GitHub. + label: Имейл адрес + button: Абонирай се + byline: + # [code], [love], and [github] will be replaced by octicons + format: "[code] с [love] от [github] и [приятели]" + # Label for code octicon + code_label: code + # Label for love octicon + love_label: love + # Label for the contributors link + friends_label: friends