Какво означава да си поддържащ на код?

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

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

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

Документиране на вашите процеси

Записването на нещата е едно от най-важните неща, които можете да направите като поддържащ на код.

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

Записването на нещата ви улеснява да кажете „не“, когато нещо не се вписва в обхвата ви. Освен това улеснява хората да се включат и да помогнат. Никога не знаете кой може да чете или използва вашия проект.

Дори и да не използвате пълни абзаци, писането на точки е по-добре, отколкото да не пишете изобщо.

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

Запишете визията на вашия проект

Започнете, като напишете целите на вашия проект. Добавете ги към вашия README или създайте отделен файл, наречен VISION. Ако има други фактори, които биха могли да помогнат, като пътна карта на проекта, направете и тях публични.

Наличието на ясна, документирана визия ви държи фокусирани и ви помага да избегнете „да не ви се изплъзне целта“ от приноса на другите.

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

Съобщете вашите очаквания

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

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

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

Всичко това е напълно наред! Просто се уверете, че другите хора знаят за това.

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

Ето някои правила, които си струва да имате предвид:

• Как се преглежда и приема принос (Имат ли нужда от тестове? Шаблон за проблем?)
• Типовете приноси, които ще приемете (Искате ли помощ само за определена част от вашия код?)
• Когато е уместно да се проследи (например, „Можете да очаквате отговор от поддържащия в рамките на 7 дни. Ако не сте чули нищо дотогава, не се колебайте да пингвате темата.“)
• Колко време отделяте за проекта (например, „Прекарваме само около 5 часа на седмица в този проект“)

Jekyll, CocoaPods, and Homebrew са някои примери за проекти с ясни правила за поддържащите и сътрудниците.

Поддържайте публична комуникация

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

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

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

Да се ​​научим да казваме не

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

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

Да кажете „не“ не е забавно, но „Вашият принос не отговаря на критериите за този проект“ изглежда по-малко лично от „Не харесвам вашия принос“.

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

Поддържайте разговора приятелски

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

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

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

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

Don’t leave an unwanted contribution open because you feel guilty or want to be nice. Over time, your unanswered issues and PRs will make working on your project feel that much more stressful and intimidating.

Най-добре е незабавно да затворите приноси, които знаете, че не искате да приемете. Ако вашият проект вече страда от голямо изоставане или списък с функции за внедряване, @steveklabnik има предложения за how to triage issues efficiently.

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

Ако не искате да приемете принос:

• Благодари им за техния принос
• Обяснете защо не се вписва в обхвата на проекта и предложете ясни предложения за подобрение, ако можете. Бъдете мили, но твърди.
• Връзка към съответната документация, ако я имате. Ако забележите повтарящи се искания за неща, които не искате да приемете, добавете ги в документацията си, за да избегнете повтаряне.
• Затворете заявката

Не трябва да имате повече от 1-2 изречения, за да отговорите. Например, когато потребител на целъри съобщи за грешка, свързана с Windows, @berkerpeksag отговаря с:

Ако мисълта да кажете „не“ ви ужасява, не сте сами. Като @jessfraz казва:

Говорил съм с поддържащи кодове от множество различни проекти с отворен код, Mesos, Kubernetes, Chromium, и всички те са съгласни, че една от най-трудните части да си поддържащ код е да кажеш „Не“ на пачове, които не работят.

Не се чувствайте виновни, че не искате да приемете нечий принос. Първото правило на отворения код, съгласно с @shykes: “Не е временно, да завинаги е.” Въпреки че съпричастността към ентусиазма на друг човек е нещо добро, отхвърлянето на принос не е същото като отхвърлянето на човека зад него.

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

Бъди проактивен

За да намалите обема на нежеланите приноси на първо място, обяснете процеса на вашия проект за подаване и приемане на приноси във вашето ръководство за приноси.

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

• Попълнете проблем или PR шаблон/контролен списък
• Отворете проблем, преди да изпратите PR

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

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

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

Прегърнете менторството

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

Ако видите, че някой е развълнуван от вашия проект, но има нужда от малко практика, бъдете търпеливи. Обяснете ясно във всяка ситуация защо вашият принос не отговаря на очакванията на проекта. Опитайте да им дадете по-лесна или по-малко двусмислена задача, като например проблем, отбелязан като „good first issue“, за да ги загреете. Ако имате време, обмислете да ги наставлявате чрез първия им принос или намерете някой друг във вашата общност, който е готов да ги наставлява.

Използвайте общността си

Не е нужно да правите всичко сами. Вашата проектна общност съществува с причина! Дори ако все още нямате активна общност от сътрудници, ако имате много потребители, оставете ги да работят.

Споделете натоварването

Ако търсите други да се присъединят, започнете, като разпитате наоколо.

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

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

Насърчаване на другите да споделят собствеността върху проекта може значително да намали вашето работното натоварване, както @lmccart откри в своя проект, p5.js.

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

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

@progrium found that документира визията за своя проект, Dokku, помогна на тези цели да продължат да съществуват дори след като се оттегли от проекта:

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

Оставете другите да създават решенията, от които се нуждаят

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

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

Същото важи и за потребител, който наистина иска решение, което вие просто нямате възможност да създадете. Предлагането на адаптивни API и hooks може да помогне на другите да посрещнат собствените си нужди, без да се налага директно да променят източника. @orta установи, че насърчаването на плъгини за CocoaPods доведе до “някои от най-интересните идеи”:

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

Доведете роботите

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

Изисквайте тестове и други проверки, за да подобрите качеството на вашия код

Един от най-важните начини, по които можете да автоматизирате проекта си, е чрез добавяне на тестове.

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

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

Ако добавяте тестове, не забравяйте да обясните как работят във вашия CONTRIBUTING файл.

Използвайте инструменти за автоматизиране на основните задачи по поддръжката

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

Има различни налични инструменти, които да помогнат за автоматизирането на някои аспекти на работата по поддръжката. Няколко примера:

• semantic-release автоматизира вашите издания
• mention-bot споменава потенциални рецензенти за заявки за изтегляне
• Danger помага за автоматизирането на прегледа на кода
• no-response затваря въпроси, при които авторът не е отговорил на искане за повече информация
• dependabot проверява вашите файлове за зависимости всеки ден за остарели изисквания и отваря индивидуални заявки за изтегляне за всяко, което открие

За доклади за грешки и други общи приноси GitHub има Issue Templates and Pull Request Templates, които можете да създадете, за да рационализирате комуникацията, която получавате. @TalAter създаде Изберете свое собствено ръководство за приключение за да ви помогне да напишете вашия проблем и PR шаблони.

За да управлявате вашите имейл известия, можете да настроите имейл филтри, за да организирате по приоритет.

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

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

Ако не сте сигурни кои инструменти да използвате, вижте какво правят други популярни проекти, особено тези във вашата екосистема. Например, как изглежда процесът на принос за други модули на Node? Използването на подобни инструменти и подходи също така ще направи вашия процес по-познат на вашите сътрудници.

Добре е да натиснете пауза

Работата с отворен код някога ви е носила радост. Може би сега започва да ви кара да се чувствате отбягващи или виновни.

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

Измореностa е реален и широко разпространен проблем в работата с отворен код, особено сред поддържащите. Като поддържащ, вашето щастие е неподлежащо на обсъждане изискване за оцеляването на всеки проект с отворен код.

Въпреки че трябва да се разбира от само себе си, вземете си почивка! Не трябва да чакате, като се почувствате изморени, за да си вземете ваканция. @brettcannon, разработчик на ядрото на Python, реши да си вземе едномесечна ваканция след 14 години доброволен OSS работа.

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

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

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

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

Погрижете се първо за себе си!

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

Back to all guides