Што значыць быць мэйнтэйнерам?
Калі вы падтрымліваеце апенсорс-праект, якім карыстаецца мноства людзей, магчыма, вы заўважылі, што сталі менш пісаць код і больш адказваць на ішю.
На ранніх стадыях праекта вы эксперыментуеце з новымі ідэямі і прымаеце рашэнні, засноўваючыся на ўласных перавагах. Па меры росту папулярнасці вашага праекта вы будзеце больш працаваць са сваімі карыстальнікамі і кантрыб’ютарамі.
Для падтрымкі праекту патрабуецца нешта большае, чым проста код. Гэтыя задачы часта бываюць нечаканымі, але яны не менш важныя для расце праекта. Мы сабралі некалькі спосабаў аблегчыць ваша жыццё — ад дакументавання працэсаў да прыцягнення вашай супольнасці.
Дакументаванне працэсаў
Як мэйнтэйнеру вам трэба будзе шмат пісаць, - гэта адна з найбольш галоўных вашых задач.
Дакументацыя не толькі растлумачвае вашу галаву, але і дапамагае іншым людзям зразумець, што вам трэба ці чаго вы чакаеце, яшчэ да таго, як яны спытаюць.
На лісце лягчэй сказаць “не”, калі нешта не ўпісваецца ў рамкі праекта. Гэта таксама дапаможа людзям далучыцца і дапамагчы вам. Бо ніколі не ведаеш, хто можа цікавіцца ці выкарыстоўваць ваш праект.
Нават калі вы не збіраецеся пісаць шмат тэксту, накіда з асноўнымі тэзамі будзе цалкам дастаткова, прынамсі гэта лепш, чым нічога.
Не забывайце абнаўляць дакументацыю. Калі не заўсёды атрымліваецца гэта зрабіць, выдаліце састарэлую дакументацыю або пакажыце, што яна састарэлая, такім чынам удзельнікі могуць дапамагчы з гэтым.
Запішыце бачанне праекта
Пачніце са складання мэт вашага праекта. Дадайце іх у свой README або стварыце асобны файл з імем VISION. Калі ёсць іншая падобная інфармацыя, якая можа дапамагчы, напрыклад план развіцця (дарожная карта) праекту, то таксама зрабіце іх агульнадаступнымі.
Наяўнасць дакладнага і задакументаванай канцэпцыі праекта дапаможа вам засяродзіцца на галоўным і пазбегнуць “некантралюемага росту праекта” ад удзелу іншых людзей.
Напрыклад, @lord выявіў, што бачанне праекту дапамагло яму зразумець правільна расставіць прыярытэты. Як новы мэйнтэйнер, ён шкадаваў, што не прасачыў за распаўзаннем межаў праекта, калі атрымаў свой першы запыт на рэалізацыю новай функцыянальнасці ў Slate.
Паведаміце пра свае чаканні
Напісанне правілаў можа стамляць вас. Часам вам можа здацца, што вы сочыце за паводзінамі іншых людзей або забіваеце ўсю весялосць.
Аднак справядлівае выкананне добра складзеных правіл пашыраюць магчымасці мэйнтэйнераў. Гэта пазбавіць вас ад уцягвання ў малапрыемныя справы.
Большасць людзей, якія сутыкаюцца з вашым праектам, нічога не ведаюць пра вас ці вашыя абставіны. Яны могуць меркаваць, што вам плацяць за працу над праектам, асабліва калі яны яго рэгулярна выкарыстоўваюць і належаць на яго. Можа быць, калісьці вы надалі шмат часу свайму праекту, але зараз занятыя новай працай ці сямейнымі заняткамі.
Усё гэта абсалютна нармальна! Толькі дайце ведаць аб гэтым іншым людзям.
Калі вы займаецеся праектам нерэгулярна ці на добраахвотных пачатках, сапраўды прызнайце, колькі ў вас ёсць чакай. Не варта блытаць наяўныя ў вас час і час, які, на вашую думку, патрабуецца для праекту ці ад вас чакаюць іншыя.
Вось некалькі правіл, якія варта ўсталяваць:
- Як разглядаецца і прымаецца ўклад (Ці трэба напісаць тэсты? Шаблон ішью?)
- Тыпы ўкладаў, якія вы прымаеце (Вам патрэбна дапамога толькі з пэўнай часткай вашага кода?)
- Калі варта распачаць наступныя дзеянні (напрыклад, «Вы можаце чакаць адказу ад мэйнтэйнера на працягу 7 дзён. Калі пасля гэтага часу вы не атрымалі адказ, не саромейцеся ўздымаць тэму».)
- Колькі часу вы марнуеце на праект (напрыклад, «Мы марнуем на гэты праект усяго каля 5 гадзін у тыдзень»)
Jekyll, CocoaPods і Homebrew — гэта некалькі прыкладаў праектаў з асноўнымі правіламі для суправаджаюць і ўдзельнікаў.
Падтрымлівайце публічнасць абмеркаванняў
Не забывайце таксама фіксаваць свае гутаркі. Там, дзе гэта магчыма, дзяліцеся інфармацыяй аб сваім праекце публічна. Калі нехта спрабуе звязацца з вамі напрамую, каб абмеркаваць рэалізацыю новай функцыянальнасці або атрымаць дапамогу, ветліва накіруйце яго на агульнадаступны канал сувязі, такі як спіс рассылкі або ішю.
Калі вы сустракаецеся з іншымі мэйнтэйнерамі або прымаеце важнае рашэнне ў прыватным парадку, запісвайце ўсё, нават калі гэта проста публікацыя вашых нататак.
Такім чынам, любы, хто далучыцца да вашай суполкі, будзе мець доступ да той жа інфармацыі, што і той, хто быў там гадамі.
Навучыцеся казаць «не»
Вы ўсё запісалі. У ідэальным свеце ўсё б прачыталі дакументацыю, але вось толькі ў рэальнасці вам давядзецца нагадваць людзям пра яе існаванне.
Аднак спасылка на пісьмовыя тлумачэнні дапаможа абязлічыць сітуацыі, калі трэба забяспечыць выкананне правіл.
Таксама саму адмову варта зрабіць як мага менш асабістай, напрыклад, замест «Мне не падабаецца ваш фундуш» нашмат лепш напісаць «Ваш фундуш не адпавядае крытэрам гэтага праекту».
Адмаўляць дастасавальна ў шматлікіх сітуацыях, з якімі вы сутыкнецеся як мэйнтэйнер, напрыклад, калі хтосьці просіць рэалізаваць новую функцыянальнасць, якая не ўпісваецца ў праект, або замінае абмеркаванню, або выконвае непатрэбную для іншых працу.
Падтрымлівайце сяброўскую гутарку
Як правіла, у ішью і пул-рэквестах вы будзеце практыкавацца адмаўляць людзям. Як мэйнтэйнер праекта, вы непазбежна будзеце атрымліваць непатрэбныя прапановы.
Магчыма ўклад моцна мяняе сутнасць праекта або не адпавядае вашаму бачанню. Можа ідэя добрая, але рэалізацыя вымушае жадаць лепшага.
Незалежна ад прычыны, трэба з разуменнем ставіцца да прапанаваных змен, якія не адпавядаюць стандартам вашага праекта.
Калі бачыце ўклад, які не збіраецеся прымаць, першай рэакцыяй можа быць праігнараваць яго ці прыкінуцца, што яго няма. Аднак гэта можа пакрыўдзіць аўтара, і нават дэматываваць патэнцыйных кантрыб’ютараў.
Не пакідайце непатрэбным уклад адкрытым з-за пачуцця віны або ветлівасці. З часам усе пакінутыя без адказу ышшу і PR толькі ўскладняць і замарудзяць вашу працу над праектам.
Калі вы разумееце, што не зможаце прыняць фундуш, лепш адразу яго зачыніце. Калі ў вашым праекце ўжо назапасілася вялікая колькасць неразгледжаных заявак, у @steveklabnik ёсць прапановы па эфектыўным сартаванні ішю.
Акрамя таго, ігнараванне ўкладаў аказвае адмоўнае ўздзеянне на вашу супольнасць. Удзел у праекце можа быць страшным, асабліва першы раз. Нават калі вы не збіраецеся прымаць фундуш, падзякуйце яго аўтара за выяўленую цікавасць. Гэта вялікі камплімент!
Калі вы не хочаце прымаць уклад:
- Падзякуйце аўтара за працу
- Растлумачце, чаму ён не ўпісваецца у рамкі праекта, і, калі можаце, падрыхтуйце канкрэтныя прапановы па паляпшэнні. Будзьце добразычлівымі, але паслядоўнымі.
- Дайце спасылку на адпаведную дакументацыю, калі яна ў вас ёсць. Калі вы заўважаеце паўторныя непажаданыя пул-рэквесты, напішыце пра гэта ў дакументацыі.
- Закрыйце пул-рэквест
Дастаткова 1-2 сказаў для адказу. Напрыклад, калі карыстальнік celery паведаміў пра памылку, звязаную з Windows, @berkerpeksag адказаў:
Калі думка пра тое, каб сказаць «не», палохае вас, вы не самотныя. Як выказаўся @jessfraz:
Я размаўляў з мейнтэйнерамі з некалькіх розных опенсорс-праектаў, Mesos, Kubernetes, Chromium, і ўсе яны згаджаюцца з тым, што адна з самых складаных частак працы мейнтэйнера — гэта адмовіцца ад непатрэбных патчаў.
Не адчувайце сябе вінаватым з-за таго, што не хочаце прымаць чыйсьці ўклад. Першае правіла опенсорсу, згодна @shykes: «Не — часова, так — назаўжды». Спачуваць энтузіязму іншага чалавека — гэта добра, адмаўляцца ад яго ўкладу не значыць адхіляць яго аўтара.
У канчатковым выніку, калі ўклад недастаткова добры, вы не абавязаны яго прымаць. Будзьце добрыя і спагадлівыя, калі людзі ўносяць свой уклад у ваш праект, але прымайце толькі тыя змены, якія, на вашу думку, зробяць ваш праект лепшым. Чым часцей вы будзеце казаць «не», тым лягчэй гэта будзе атрымлівацца. Абяцаю.
Будзьце ініцыятыўным(ай)
Перш за ўсё, каб зменшыць колькасць непажаданых укладаў, распішыце працэс адпраўкі і прыняцця ўкладаў у сваім кіраўніцтве па ўдзеле вашага праекта.
Калі вам прыходзяць занадта шмат няякасных укладаў, запатрабуйце ад кантрыб’ютараў выканаць шэраг умоў, напрыклад:
- Запоўніць шаблон/кантрольны спіс для ў ішью або пул-рэквест
- Адкрыць ішью перад адпраўкай пул-рэквеста
Калі людзі не выконваюць вашыя правілы, неадкладна зачыніце ішью і пакажыце ім на папярэднія патрабаванні.
Спачатку такі падыход можа здацца суровым, але насамрэч праактыўнасць карысная для абодвух бакоў. Гэта змяншае верагоднасць таго, што хтосьці выдаткуе марна шмат гадзін працы на непатрэбны для вас пул-рэквест. А яшчэ вам зменшыцца нагрузка.
Часам, калі вы кажаце “не”, патэнцыйны кантрыб’ютар можа знервавацца або раскрытыкаваць ваша рашэнне. Калі яго паводзіны становяцца варожымі, прыміце меры, каб разрадзіць сітуацыю або нават выдаліце яго з вашага супольнасці, калі ён не гатовы да канструктыўнага супрацоўніцтва.
Прыміце настаўніцтва
Магчыма, хтосьці з вашай супольнасці рэгулярна адпраўляе ўклады, якія не адпавядаюць стандартам вашага праекта. Не толькі аўтар, але мэйнтэйнер можа быць расчараваны, калі ўвесь час даводзіцца адмаўляць у прыняцці фундуша.
Калі вы бачыце, што хтосьці з энтузіязмам падыходзіць да вашага праекту, але яго праца патрабуе дапрацоўкі, будзьце цярплівыя. Выразна растлумачце ў кожнай сітуацыі, чаму іх уклад не адпавядае чаканням праекта. Паспрабуйце прапанаваць людзям лягчэйшую або меней расплывістую задачу, напрыклад, ышу з цэтлікам “good first issue”, каб набрацца досведу і паспрабаваць сябе. Калі ў вас ёсць час, падумайце аб настаўніцтве ў іх першым укладзе, або знайдзіце каго-небудзь у вашым супольнасці, хто пагадзіўся стаць ментарам.
Выкарыстоўвайце сілу супольнасці
Неабавязкова ўсё рабіць самому. Супольнасць вашага праекта існуе не проста так! Нават калі ў вас яшчэ няма актыўных кантрыб’ютараў, але затое ёсць шмат карыстальнікаў, паспрабуйце прыцягнуць іх.
Размяркуйце працоўную нагрузку
Калі вы шукаеце, хто мог бы дапамагчы, пачніце з роспытаў.
Адзін са спосабаў прыцягнуць новых кантрыб’ютараў — дадаць ярлык на тыя ішью, якія досыць простыя для пачаткоўцаў. Затым GitHub будзе адлюстроўваць іх у розных месцах сайта, робячы тым самым іх больш заўважнымі.
Калі вы бачыце, што новыя кантрыб’ютары неаднаразова ўносяць свой уклад, прызнайце іх працу, прапанаваўшы больш адказнасці. Задакументуйце, як людзі могуць заняць кіруючыя ролі, калі захочуць.
Падахвочванне іншых падзяліць валоданне праектам можа значна зменшыць вашу нагрузку, як выявіла @lmccart у сваім праекце p5.js.
Калі вам трэба адысці ад праекту, няхай гэта будзе зрабіць перапынак ці назаўжды пакінуць яго, няма нічога ганебнага ў тым, каб папрасіць кагосьці іншага ўзяць на сябе вашыя абавязкі.
Калі іншыя людзі поўныя энтузіязму адносна напрамкі развіцця праекта, дайце ім доступ да адпраўкі комітаў або афіцыйна перадайце кантроль камусьці іншаму. Калі хтосьці фаркнуў ваш праект і пачаў актыўна займацца яго копіяй, падумайце аб тым, каб пазначыць спасылку на яго ва ўжо вашым (арыгінальным) праекце. Выдатна, што так шмат людзей жадаюць, каб ваш праект працягваў развівацца!
@progrium выявіў, што дакументаванне бачання яго праекту Dokku дапамагло дасягнуць гэтых мэтаў нават пасля таго, як ён сышоў з праекту:
Я напісаў вікі-старонку з апісаннем таго, што я хацеў зрабіць і чаму. Чамусьці для мяне стала нечаканасцю, што мэйнтэйнеры пачалі рухаць праект у гэтым кірунку! Усё адбывалася менавіта так, як я хацеў? Не заўсёды. Але ўсё ж наблізіла праект да таго, што я напісаў.
Дазвольце іншым ствараць патрэбныя ім рашэнні
Калі патэнцыйны кантрыб’ютар прытрымліваецца іншага меркавання, што павінен рабіць ваш праект, вы можаце мякка падштурхнуць яго да працы над уласным форкам.
Не варта ўспрымаць копіі праекту чымсьці дрэнным. Магчымасць капіяваць і змяняць праекты - адна з лепшых асаблівасцяў апенсорсу. Садзейнічанне чальцоў вашай супольнасці да працы над уласным форкам можа даць ім неабходную творчую аддушыну, без шкоды вашаму праекту.
Тое ж самае ставіцца да карыстача, якому сапраўды трэба рашэнне, але для стварэння якога ў вас проста няма рэсурсаў. Прапаноўваючы API-інтэрфейсы і хукі для кастамізацыі, можна дапамагчы іншым карыстальнікам вырашыць іх задачы без неабходнасці напрамую змяняць зыходны код. @orta выявіў, што заахвочванне плагінаў для CocoaPods прывяло да «некаторым з самых цікавых ідэй»:
Амаль непазбежна, што калі праект становіцца вялікім, мэйнтэйнеры павінны стаць больш кансерватыўнымі датычна новага кода. Вы навучыцеся адмаўляць, нягледзячы на тое, што ў многіх людзей ёсць разумныя прычыны. Так што ў выніку вы ператвараеце свой інструмент у платформу.
Задзейнічайце робатаў
Падобна да таго, як ёсць задачы, з якімі вам могуць дапамагчы іншыя людзі, так і ёсць задачы, якія не павінен выконваць ні адзін чалавек. Робаты - вашыя сябры. Выкарыстоўвайце іх, каб аблегчыць сабе жыццё ў якасці мэйнтэйнера.
Патрабуйце тэсты і іншыя праверкі для паляпшэння якасці кода
Адзін з найбольш важных спосабаў аўтаматызацыі праекта - гэта напісанне тэстаў.
Тэсты дапамагаюць удзельнікам адчуваць сябе ўпэўнена ў тым, што ў выніку новых зменаў нічога не было зламана. Яны таксама аблягчаюць разгляд і прыняцце ўкладаў. Чым больш актыўна вы будзеце рэагаваць, тым больш зацікаўленым можа быць ваша супольнасць.
Наладзьце аўтатэсты, якія будуць запускацца на ўсіх уваходных фундушаў, і пераканайцеся, што яны могуць быць выкананыя кантрыб’ютарамі лакальна. Патрабуйце, каб увесь код ад кантрыб’ютараў праходзіў тэсты, да таго, як яны адпраўляць сам уклад. Вы дапаможаце ўсталяваць мінімальны стандарт якасці для ўсіх якія адпраўляюцца фундушаў. Абавязковыя праверкі статуту на GitHub дапамогуць прасачыць за тым, што ніякія змены не будуць аб’яднаныя без праходжання тэстаў.
Калі вы дадаеце тэсты, абавязкова растлумачце, як яны працуюць у файле CONTRIBUTING.
Выкарыстоўвайце прылады для аўтаматызацыі асноўных задач суправаджэння
Што добра ў падтрымцы папулярнага праекта, дык гэта тое, што іншыя мэйнтэйнеры, верагодна, сутыкаліся з аналагічнымі праблемамі і вырашылі іх.
Існуе мноства інструментаў, якія дапамагаюць аўтаматызаваць некаторыя аспекты работ па суправаджэнні. Некалькі прыкладаў:
- semantic-release аўтаматызуе вашыя рэлізы
- mention-bot згадвае патэнцыйных рэўюераў для пул-рэквеста
- Danger дапамагае аўтаматызаваць праверку кода
- no-response закрывае ішью, калі аўтар не падаў дадатковую інфармацыю
- dependabot штодня ідзе за актуальнасцю залежнасцяў, і калі знаходзіць нешта новае, то адкрывае асобныя пул-рэквесты
Для паведамленняў аб памылках і іншых агульных праблем на GitHub ёсць шаблоны для ішью і пул-рэквеста, якія можна стварыць для спрашчэння ўзаемадзеяння з супольнасцю. @TalAter стварыў Кіраўніцтва Choose Your Own Adventure, каб дапамагчы вам напісаць уласныя шаблоны ішью і пул-рэквеста.
Для кіравання апавяшчэннямі па электроннай пошце вы можаце наладзіць фільтры электроннай пошты, каб адсартаваць іх па прыярытэце.
Калі вы хочаце яшчэ крыху прасунуцца, кіраўніцтва па стылі і лінтэры дапамогуць стандартаваць уклады ў праект і спрасціць іх прагляд і прыняцце.
Аднак, калі вашыя стандарты занадта складаныя, яны могуць павялічыць перашкоды на шляху да ўдзелу. Пераканайцеся, што вы дадаеце толькі неабходныя правілы, каб аблегчыць усім жыццё.
Калі вы не ведаеце, якія прылады выкарыстоўваць, паглядзіце на досвед іншых папулярных праектаў, асабліва ў вашай экасістэме. Напрыклад, як выглядае працэс удзелу ў іншых модуляў Node? Выкарыстанне падобных інструментаў і падыходаў таксама зробіць ваш працэс больш знаёмым для патэнцыйных кантрыб’ютараў.
Узяць паўзу - гэта нармальна
Калісьці апенсорс-праца прыносіла вам радасць. А магчыма зараз вы пачынаеце адчуваць сябе вінаватым ці не ідзіце на кантакт.
Магчыма, вы адчуваеце сябе пабітым ці вас не пакідае расце пачуццё страху, калі думаеце аб сваіх праектах. А між тым ішью і пул-рэквесты назапашваюцца.
Выгаранне - рэальная і распаўсюджаная праблема пры працы над апенсорсам, асабліва сярод мэйнтэйняў. Ваша шчасце як мэйнтэйнера - няўхільная ўмова для выжывання любога апенсорс-праекта.
Хоць гэта само сабой зразумела, але рабіце перапынак! Не трэба чакаць, пакуль вы адчуеце выгаранне, каб узяць водпуск. @brettcannon, распрацоўшчык ядра Python, вырашыў узяць адпачынак на месяц пасля 14 гадоў валанцёрскай працы ў апенсорсе.
Як і любы іншы від працы, рэгулярныя перапынкі дазваляюць вам заставацца бадзёрым, шчаслівым і захопленым сваёй працай.
Часам бывае цяжка зрабіць перапынак у апенсорс-працы, калі здаецца, што вы патрэбны ўсім. Людзі могуць нават паспрабаваць прымусіць вас адчуць сябе вінаватым за тое, што вы часова адышлі ад справаў.
Паспрабуйце знайсці падтрымку для сваіх карыстальнікаў і супольнасці падчас вашага адсутнасці ў праекце. Калі вы не можаце знайсці неабходную падтрымку, усё роўна вазьміце паўзу. Але абавязкова папярэдзьце людзей аб вашым адпачынку, каб іх не бянтэжыла адсутнасць вашай рэакцыі.
Перапынкі адносяцца не толькі да водпуску. Калі вы не жадаеце займацца апенсорсам па выходных ці ў працоўны час, паведаміце пра гэта людзям, каб яны ведалі, што вас не трэба турбаваць.
Беражы сябе ў першую чаргу!
Падтрымка папулярнага праекта патрабуе іншых навыкаў, чым на ранніх этапах развіцця, але гэта не памяншае карысць апісаных вышэй парад. Як мэйнтэйнер, вы будзеце практыкаваць лідэрскія і асабістыя навыкі на такім узроўні, які мала каму ўдаецца выпрабаваць. Хоць кіраваць праектам не заўсёды лёгка, выбудоўванне выразных межаў і адэкватная ацэнка сваіх сіл дапамогуць вам заставацца шчаслівымі, бадзёрымі і прадуктыўнымі.
