Как да привлечете нови сътрудници към вашия проект с отворен код

Трудно е да привлечете сътрудници във вашия FOSS проект - особено тези, които са нови с отворен код.

Ръководителите на проекти често обсъждат как да направят своите проекти с отворен код по-удобни за начинаещи, така че те могат да привлекат нови участници и да ги накарат да се почувстват добре дошли. Но този диалог често се хваща в капан в самата ехо кама на поддържащите. Вместо това трябва да се включи другата страна: самите нови участници.

През краткото си време като сътрудник с отворен код разгледах множество проекти и допринесох и за няколко от тях. В тази публикация ще се опитам да изброя това, което ми се хареса като нов сътрудник и какво не. И ще използвам няколко проекта като казуси.

Съвет №1: Етикетиране на начинаещи проблеми по подходящ начин

Това определено е най-важното съображение за мен като потенциален сътрудник.

Етикетите улесняват намирането на проблеми, които могат да послужат като плажна глава за първи принос. Ако вашият проект няма такива, той значително повдига лентата за принос към него.

Много е трудно някой, непознат с вашата кодова база, да прецени трудността на даден проблем. Така че обобщеният етикет като исканата помощ не е достатъчно полезен сам по себе си. Опитайте да използвате по-конкретни етикети, като добри първи грешки, лесни, ниско висящи плодове и др., За да съобщите, че проблемът е достатъчно лесен за първоначален принос.

Съвет №2: Създайте правилни указания за принос

Добре написаният Contributing.md може да опише работния процес, който поддръжниците на вашия проект очаквано ще следват. Това е лесно за документиране и ще спести на двете страни значителен период от време.

Посочете дали сътрудникът е длъжен да работи върху отделен клон за всеки брой, или да съкрати своите ангажименти и да промени отново промените си, преди да изпрати PR. Опитайте да свържете подходящи уроци за всеки от тези процеси, в случай че сътрудникът все още не е запознат с тях.

Съвет №3: Документирайте дизайна, архитектурата и структурата на вашия проект

Наличието на документ, който дава преглед на високо ниво на дизайна и архитектурата на вашия проект, може да спести на двете страни много време.

Вместо да обяснявате едно и също нещо отново и отново на всеки нов сътрудник, обърнете внимание на често задавани въпроси и създайте често задавани въпроси точно там на вашия README.md.

Най-стръмната бариера за повечето нови сътрудници е навигацията в плътни кодови бази. Помогнете на новодошлите да намерят пътя си, като предлагат описание на структурата на вашата папка.

Много нови сътрудници са млади разработчици, които може би все още не знаят много общи архитектурни и дизайнерски модели. Създайте документи, които подчертават тези решения и мотивите зад тях.

Съвет №4: Поставете ясен Кодекс на поведение

Създайте правилен кодекс за поведение, който изрично посочва правила във вашата FOSS общност. Много нови сътрудници, включително и мен, се страхуват да не се отнасят лошо или да гледат надолу, докато се опитват да дадат своя принос.

Кодексът ви за поведение, който пояснява как да подадете сигнал за нарушения, може да помогне на хората да се чувстват в безопасност. Това също води до извикване на лошо поведение на всяка стъпка, независимо от ръста на участващия човек, и предприемане на подходящи действия.

Съвет №5: Създайте шаблони за заявки и проблеми за изтегляне

Правилният шаблон за издаване може да помогне на хората да опишат по-добре средата, необходима за възпроизвеждане на бъг. След това сътрудниците могат да започнат незабавно да работят по въпроса, без да е необходимо да събират информация от различни места. Това спестява време и за двете страни.

Подобен аргумент може да се направи за шаблони за заявки за изтегляне. Ясно очертайте какво се очаква, когато сътрудник изпрати PR, включително формата на съобщението си за ангажиране, тестов план, направените промени. Това ще помогне и за преглед на кода, което ще спести още повече време на всички.

Съвет № 6: Приоритизирайте отговарянето на заявките за изтегляне

Да бъдеш поддръжник на популярен проект на FOSS е невероятно много работа. Повечето хора не получават заплати, за да допринесат за FOSS - поддържащи и сътрудници. Повечето поддържащи не разполагат с достатъчно време за преглед на всички PR с една и съща проверка.

Поставете приоритет на PR, за да могат участниците да разберат предварително дали могат да очакват да получат обратна връзка за нисък приоритет / лесно отстраняване на грешки.

Съвет № 7: Добре дошли всички видове приноси

Нашата област има гадна тенденция да гледаме надолу на преводи без код. Моля, не позволявайте на вашия проект да стане плячка за този манталитет.

Насърчавайте всички видове приноси, независимо дали са документация, код, коригиране на печатни грешки, тестове - изобщо всичко.

Съвет № 8: Наградете нови сътрудници

Ако имате бюджет, наградете нови сътрудници, като им изпратите суинг, като стикери или ризи.

Ако бюджетът ви не позволява това, тогава обикновеният вик или споменаване в блог или в социалните медии също може да измине дълъг път. Ще ги накара да осъзнаят, че техният принос - без значение голям или малък - не се пренебрегва и че те се оценяват.

Това създава усещане за принадлежност, което може да ги вдъхнови да допринесат повече.

Кент С. Додс направи прекрасна спецификация с отворен код за това: Всички сътрудници.

Добро начало може да бъде поддържането на списък на участниците в уебсайта на вашия проект и / или хранилище.

И накрая, никога не боли да си спомним, че всички някога са били младши разработчици. В определен момент те се нуждаеха от помощ, за да стигнат до нивото, което са днес.

Този прост факт може да измине дълъг път в установяването на здравословна култура на менторство във вашата организация с отворен код. Да се ​​отнасяме с уважение към всички - независимо от техния произход - е от решаващо значение за реализирането на успешен проект с отворен код.

Аз туитах горното време назад, когато тъкмо започнах да допринасям за FOSS. Но оттогава много неща се промениха. Най-накрая заключих:

Отвореният код е много повече за хората, отколкото някога за кода.

Послепис Опитвам се да създам списък на FOSS проекти, които са подходящи за начинаещи. Ако вашият проект с отворен код има материали, отнасящи се до нови сътрудници, моля, помислете за откриване на проблем в това хранилище.

Вик към Дан Абрамов, Кент К. Додс и Куинси Ларсън за това, че ми помогнаха с това парче, като предоставиха техните перспективи като поддържащи.

Ако имате допълнителни съвети за добавяне към тази публикация, не се колебайте да се свържете с мен или да отговорите по-долу.

И ако ви е било полезно, моля, докоснете или кликнете върху „︎❤“, за да помогнете за популяризирането на това парче пред другите.