Zarządzanie ochotnikami Osiąganie konsensu co do potrzeb projektu oraz doprowadzanie do wspólnej pracy nad ich zaspokajaniem wymaga więcej niż tylko świetnej atmosfery i braku oczywistej dysfunkcji. Wymaga to jednej lub kilku osób świadomie zarządzających wszystkimi zaangażowanymi ludźmi. Zarządzanie ochotnikami nie jest może technicznym rzemiosłem w takim sensie jak programowanie komputera, ale jest rzemiosłem w tym sensie, że można je ulepszać przez naukę i praktykę. Ten rozdział jest zbiorem specyficznych technik zarządzania ochotnikami. Czerpie on, zapewne mocniej niż poprzednie rozdziały, z doświadczeń projektu Subversion jako studium przypadku, po części dlatego, że pracowałem nad nim w trakcie pisania tej książki i miałem wszystkie pierwotne źródła pod ręką, a częściowo dlatego, że bardziej akceptowalne jest wrzucanie kamyków krytyki do własnego ogródka niż do cudzych. Jednak widziałem też w rozmaitych innych projektach zalety stosowania - oraz konsekwencje nie stosowania - podanych poniżej zaleceń; tam, gdzie będzie politycznie możliwe przedstawienie przykładów z niektórych tych projektów, uczynię to. Skoro już mowa o polityce, to warto w tym miejscu spojrzeć z bliska na to wieloznaczne słowo. Wielu inżynierów lubi myśleć, że politykowanie to coś, co robią inni. "Ja tylko dbam o dobro projektu, a on uprawia politykę." Wydaje mi się, że ta niechęć do polityki (lub tego, co się uważa za politykę) jest szczególnie silna wśród inżynierów, ponieważ wierzą oni, że niektóre rozwiązania są obiektywnie lepsze niż inne. Jeśli więc ktoś działa z pobudek, które wyglądają na pozamerytoryczne - na przykład dbanie o swoją pozycję, zmniejszanie cudzego wpływu, wyraźne paktowanie lub unikanie ranienia cudzych uczuć - inni uczestnicy projektu mogą się poczuć poirytowani. Naturalnie to rzadko powstrzymuje ich przed zachowywaniem się w ten sam sposób, gdy chodzi o ich własne żywotne interesy. Jeżeli uważasz "politykowanie" za coś wstrętnego i masz nadzieję, że utrzymasz swój projekt z dala od tego, to lepiej od razu daj sobie spokój. Polityka jest nieunikniona wszędzie tam, gdzie tylko ludzie muszą razem zarządzać wspólnymi zasobami. Jest absolutnie racjonalne, że jednym z czynników wpływających na proces decyzyjny każdego z uczestników jest kwestia jak dane wydarzenie może wpłynąć na jego przyszłe wpływy w projekcie. Ostatecznie jeśli wierzysz w swoje przekonania i umiejętności, jak czyni to większość programistów, to potencjalna utrata wpływu musi być uważana za - w pewnym sensie - rezultat techniczny. Podobne rozumowanie tyczy się też innych zachowań, które z wierzchu mogą się wydawać "czystą" polityką. W rzeczywistości coś takiego jak czysta polityka w ogóle nie istnieje: przede wszystkim dokładnie z tego powodu, że wydarzenia mają wielorakie konsekwencje w realnym świecie i ludzie stają się ich politycznie świadomi. Polityka to w końcu zwyczajne uznanie faktu, że trzeba brać pod uwagę wszystkie konsekwencje danej decyzji. Jeśli decyzja taka prowadzi do stanu, który większość uczestników uważa za technicznie satysfakcjonujący, ale wymaga zmian w relacjach władzy, która pozostawi najważniejsze osoby w poczuciu izolacji, to to drugie jest równie istotne jak to pierwsze. Ignorowanie tego nie jest wielkoduszne tylko krótkowzroczne. Czytając więc poniższe rady i pracując w swoim projekcie pamiętaj, że nikt nie jest ponad polityką. Sprawianie wrażenia, że jest się ponad nią, jest jedynie szczególną strategią polityczną, czasem bardzo użyteczną, ale nigdy nie jest to prawda. Polityka to po prostu to, co zachodzi gdy ludzie się nie zgadzają, a projekty, które odnoszą sukcesy, to te, które wykorzystują mechanizmy polityczne do konstruktywnego załatwiania problemów. Najlepsze wykorzystywanie ochotników Dlaczego ochotnicy pracują nad projektami wolnego oprogramowania? Nad tym pytaniem szczegółowo zastanawiali się, z interesującymi wynikami, Karim Lakhani i Robert G. Wolf w tekście pod tytułem Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects. Zobacz . Gdy się ich o to zapyta, wielu ochotników twierdzi, że robi to, bo chce tworzyć dobre oprogramowanie lub mieć osobisty udział w naprawianiu błędów, które im przeszkadzają. Ale to zwykle nie jest cała prawda. W końcu czy potrafilibyście sobie wyobrazić sobie kogoś, kto pozostaje w projekcie nawet jeśli nikt nigdy ani słowem nie docenił jego pracy ani nie wysłuchał jego głosu w dyskusji? Oczywiście, że nie. Jest jasne, że ludzie poświęcają czas na wolne oprogramowanie z powodów wykraczających poza abstrakcyjną chęć tworzenia dobrego kodu. Rozumienie rzeczywistych motywacji ochotników pomoże ci tak zorganizować projekt, aby ich przyciągać i utrzymywać. Pragnienie tworzenia dobrych programów może być jedną z tych motywacji, wraz z wyzwaniami i edukacyjną wartością pracy nad trudnymi problemami. Ale ludzie mają też wbudowaną potrzebę współpracy z innymi ludźmi oraz wyrażania i zdobywania szacunku poprzez wspólne działania. Grupy zaangażowane we współpracę muszą wytworzyć takie normy zachowania, które zapewniają zdobywanie i utrzymywanie statusu w wyniku działań, które pomagają w osiąganiu celów grupy. Te normy nie zawsze powstają same z siebie. Na przykład w niektórych projektach - doświadczeni twórcy otwartego oprogramowania potrafią prawdopodobnie bez zastanowienia wskazać kilka z nich - ludzie najwyraźniej czują, że podnoszą swój status pisząc często i obszernie. Nie dochodzą do tego wniosku przez przypadek; dochodzą do tego ponieważ są nagradzani szacunkiem za wysuwanie długiej i rozbudowanej argumentacji, niezależnie od tego, czy to faktycznie w czymś pomaga. Oto niektóre techniki tworzenia atmosfery, w której działania mające na celu zdobywanie szacunku są jednocześnie konstruktywne. Delegacja Delegacja nie jest jedynie sposobem rozdzielania zadań; to także narzędzie polityczne i społeczne. Kiedy prosisz kogoś o zrobienie czegoś, zastanów się nad wszelkimi tego skutkami. Najbardziej oczywistym skutkiem jest to, że jeśli się zgodzi, to on się tym zajmuje, a nie ty. Ale jednocześnie otrzymuje komunikat o twoim zaufaniu, że wykona to zadanie. Ponadto, jeśli przekazałeś tę prośbę na forum publicznym, to wie również, że inni członkowie grupy także dowiedzieli się o tym, że mu zaufałeś. Może też odczuwać pewną presję żeby się zgodzić, co oznacza, że musisz pytać w taki sposób, aby pozwolić mu łagodnie odmówić jeśli naprawdę nie chce tego zrobić. Jeśli zadanie wymaga koordynacji z innymi uczestnikami projektu, to w praktyce proponujesz, aby zwiększył swoje zaangażowanie, stworzył więzy, które w innym wypadku mogłyby wcale nie powstać, i zapewne stał się autorytetem w jakiejś części projektu. To dodatkowe zaangażowanie może go zniechęcić lub sprawić, że w wyniku ogólnego wzrostu poczucia zaangażowania stanie się bardziej aktywny także w innych sprawach. Z powodu wszystkich tych efektów często jest sens poprosić kogoś innego, aby coś zrobił, nawet jeśli wiesz, że sam zrobiłbyś to szybciej lub lepiej. Oczywiście czasem jest na to także ścisły argument związany z wydajnością ekonomiczną: prawdopodobnie koszt skorzystania z okazji do wykonania tego samodzielnie byłby zbyt wysoki - może być do zrobienia coś jeszcze ważniejszego, czym mógłbyś się zająć w tym czasie. Ale nawet kiedy ten argument nie wchodzi w grę, to i tak możesz zechcieć poprosić kogoś innego o zajęcie się tym zadaniem, ponieważ na dłuższą metę chcesz wciągnąć tę osobę głębiej w projekt, nawet jeśli oznacza to poświęcenia na początku dodatkowego czasu na opiekowanie się nim. Sprawdza się także technika odwrotna: jeśli czasem zgodzisz się wziąć za pracę, na którą ktoś inny nie ma ochoty lub czasu, to uzyskasz jego dobrą wolę oraz szacunek. Delegacja i zastępstwo nie ograniczają się tylko do wykonywania konkretnych zadań; służą także do zachęcania ludzi do silniejszego zaangażowania się w projekt. Wyraźnie odróżniaj prośby od wyznaczania Czasem można słusznie oczekiwać, że dana osoba zgodzi się przyjąć zadanie. Na przykład jeśli ktoś wprowadził do kodu błąd lub nadesłał kod, który jest w oczywisty sposób niezgodny z zasadami projektu, to wystarczy wskazać problem i odtąd zachowywać się tak, jakbyś zakładał, że ta osoba się nim zajmie. Ale są też inne sytuacje, w których wcale nie jest jasne, czy masz prawo oczekiwać działania. Ta osoba może zrobić to, o co prosisz, albo nie. Ponieważ nikt nie lubi być lekceważony, to musisz uważać na różnicę między tymi dwoma typami sytuacji i odpowiednio wyrażać swoje oczekiwania. Rzeczą, która niemal zawsze wzbudza u ludzi natychmiastową irytację, jest prośba o wykonanie czegoś wyrażona w taki sposób, jakbyś uważał, że należy to do czyichś obowiązków, podczas gdy ta osoba wcale tak nie myśli. Na przykład przypisanie komuś obsługi zgłoszeń jest szczególnie podatnym gruntem dla tego rodzaju zadrażnień. Uczestnicy projektu zwykle wiedzą, kto jest w danej dziedzinie ekspertem, więc gdy napływa zgłoszenie błędu, to jest najczęściej jedna lub dwie osoby, o których wszyscy wiedzą, że zapewne szybko to naprawi. Jeśli jednak przydzielisz jednej z tych osób zadanie bez jej uprzedniej zgody, to może się poczuć postawiona w niewygodnej pozycji. Odczuwa wówczas nacisk związany z oczekiwaniami, ale może też mieć wrażenie, że jest w efekcie ukarana za swoje umiejętności. W końcu umiejętności zdobywa się przez naprawianie błędów, więc może ktoś inny by się tym zajął! (Zauważ, że systemy śledzenia zgłoszeń, które automatycznie przypisują zgłoszenia konkretnym osobom na podstawie informacji w raporcie błędu, są mniej podatne na wywoływanie urazów, bo wszyscy wiedzą, że to przypisanie nastąpiło w ramach automatycznego procesu i nie jest wskaźnikiem ludzkich oczekiwań.) Chociaż byłoby miło rozdzielać zadania tak równo, jak to tylko możliwe, to w niektórych przypadkach zależy nam po prostu na tym, żeby namówić osobę, która może naprawić błąd, aby zrobiła to jak najszybciej. Ponieważ nie można sobie pozwolić na stratę czasu, żeby za każdym razem kontaktować się w sprawie takiego przydziału ("Czy mógłbyś spojrzeć na ten błąd?" "Tak." "W porządku, wobec tego przydzielam go tobie." "Dobrze."), powinieneś po prostu przydzielać zadania w formie prośby, nie wywierając presji. Praktycznie wszystkie systemy śledzenia zgłoszeń umożliwiają dodanie komentarza do zlecenia. W takim komentarzu można napisać coś w rodzaju:
Przydzielam go tobie, jkowalski, ponieważ najlepiej znasz się na tym kodzie. Nie miej jednak oporów przed odrzuceniem tego, jeśli nie masz czasu na to spojrzeć. (I daj mi znać jeśli nie chcesz dostawać takich zadań w przyszłości.)
To wyraźnie oddziela zgłoszenie zlecenia od przyjęcia tego zgłoszenia przez odbiorcę. W tym wypadku publicznością jest nie tylko on, ale wszyscy: cała grupa widzi publiczne potwierdzenie jego umiejętności, ale zarazem jest jasne, że ma on prawo przyjąć lub odmówić przyjęcia tego obowiązku. Pilnuj swojego delegata Kiedy poprosisz kogoś o zrobienie czegoś, to pamiętaj o tym i pilnuj go, cokolwiek by się nie działo. Większość próśb zgłasza się na forach publicznych, zwykle mają one mniej więcej taką formę: "Czy możesz się zająć sprawą X? Tak czy owak daj nam znać; nie będzie problemu jeśli nie możesz, chcemy tylko wiedzieć." Możesz otrzymać na to odpowiedź lub nie. Jeśli dostaniesz odzew, a odpowiedź jest negatywna, to kółko się zamyka - musisz spróbować innej strategii poradzenia sobie z tym X. Jeśli odpowiedź jest pozytywna, to miej oko na rozwój sprawy i komentuj czy widzisz postępy, czy nie (każdy pracuje lepiej kiedy wie, że ktoś docenia jego pracę). Jeśli przez kilka dni nie otrzymujesz żadnej odpowiedzi, to zapytaj znowu lub wyślij wiadomość, że nie otrzymałeś odpowiedzi i szukasz kogoś innego do wykonania tego zadania. Albo zrób to sam, ale i tak upewnij się, że nie dostałeś odpowiedzi na swoje zapotrzebowanie. Celem publicznego poinformowania o braku odpowiedzi nie jest upokarzanie, powinieneś więc zadbać o takie sformułowanie twoich uwag, żeby nie sprawiały takiego wrażenia. Chodzi tylko o pokazanie, że zwracasz uwagę na to o co prosiłeś, i że odnotowałeś reakcję jaką na to otrzymałeś. To zwiększa szanse, że następnym razem ktoś się zgodzi, ponieważ ludzie spostrzegą (nawet jeśli tylko nieświadomie), że raczej zauważysz to co zrobią, ponieważ zauważyłeś znacznie drobniejszy fakt, że ktoś nie odpowiedział. Zwracaj uwagę kto jest zainteresowany Inną rzeczą, która sprawia ludziom przyjemność, jest dostrzeganie ich zainteresowań - ogólnie mówiąc im więcej aspektów czyjejś osobowości zauważysz i zapamiętasz, tym bardziej komfortowo się ta osoba poczuje i tym chętniej będzie chciała pracować w grupach, do których należysz. Na przykład w projekcie Subversion pojawił się ostry podział między ludźmi, którzy chcieli ukończyć ostateczną wersję 1.0 (co faktycznie zrobiliśmy), a tymi, którzy chcieli przede wszystkim dodawać nowe funkcje i pracować nad interesującymi problemami, ale nie interesowało ich zanadto kiedy pojawi się wydanie 1.0. Żadne z tych stanowisk nie jest lepsze ani gorsze niż to drugie; to tylko dwa różne typy twórców i oba wykonują w projekcie wiele pracy. Ale natychmiast dowiedzieliśmy się jak ważne jest aby nie zakładać, że wszyscy podzielają entuzjazm z pogoni za wersją 1.0. Media elektroniczne bywają bardzo zwodnicze: możesz odczuwać atmosferę wspólnego celu, gdy w rzeczywistości jest on podzielany tylko przez ludzi z którymi akurat rozmawiałeś, a pozostali mają zupełnie inne priorytety. Im lepsze masz rozeznanie w tym, czego ludzie oczekują od projektu, tym bardziej efektywnie możesz ich o coś prosić. Nawet zwykłe okazanie zrozumienia czego chcą, bez wiązania tego z żadnymi prośbami, jest użyteczne, ponieważ utwierdza każdego w przekonaniu, że nie jest jedynie kolejnym elementem jednolitej masy. Pochwały i krytyka Pochwały i krytyka nie są przeciwieństwami; pod wieloma względami są do siebie bardzo podobne. Oba te zjawiska są przede wszystkim formami okazywania uwagi i są najbardziej efektywne, gdy odnoszą się raczej do konkretów niż gdy dotyczą ogółów. Oba powinny być stosowane w konkretnych celach. Oba może dotknąć inflacja: zbyt wiele zbyt częstych pochwał obniża ich wartość; to samo dotyczy krytykowania, chociaż w praktyce krytyka zwykle występuje w reakcji na coś i dlatego jest nieco bardziej odporna na dewaluację. Istotną cechą kultury technicznej jest to, że szczegółowa, pozbawiona emocji krytyka jest często traktowana jako rodzaj pochwały (jak to zostało omówione w sekcji , ), ponieważ jest skutkiem uznania, że praca jej adresata jest warta czasu poświęconego na jej analizę. Aby jednak tak się stało, muszą być spełnione oba warunki: szczegółowość i brak emocji. Na przykład jeśli ktoś wprowadzi do kodu niedbałą zmianę, to jest bezużyteczne (i wręcz szkodliwe) komentowanie tego słowami "To jest niedbałe". W końcu niedbałość jest charakterystyką osoby, nie jej pracy, a jest istotne aby skupiać swoje reakcje właśnie na pracy. Znacznie bardziej efektywne jest opisanie wszystkiego, co jest złego w tej zmianie, taktownie i bez napastliwości. Jeśli to trzecia lub czwarta pod rząd niestaranna zmiana autorstwa tej samej osoby, to należy o tym napisać - nadal bez złości - na końcu swojej krytyki, aby dać znać, że została odnotowana taka prawidłowość. Jeśli ktoś pod wpływem krytyki nie poprawia się, to rozwiązaniem nie jest silniejsza krytyka. Wyjściem dla grupy jest usunięcie tej osoby z pozycji niekompetencji w sposób, który minimalizuje urażenie uczuć tak bardzo, jak to tylko możliwe; przykłady na to znajdziesz w sekcji dalej w tym rozdziale. Taka sytuacja jest mimo wszystko rzadkością. Większość ludzi całkiem nieźle reaguje na krytykę, która jest konkretna, szczegółowa i zawiera jasne (nawet jeśli nie wypowiedziane) oczekiwania na temat poprawy. Pochwały oczywiście nie ranią niczyich uczuć, ale to nie znaczy, że powinny być stosowane mniej rozważnie niż krytyka. Pochwała to narzędzie: zanim go użyjesz, spytaj sam siebie dlaczego chcesz go użyć. Co do zasady, nie jest dobrym pomysłem chwalić ludzi za to co robią zazwyczaj, lub za takie działania, które stanowią normalną i oczekiwaną część uczestnictwa w grupie. Gdybyś tak robił, nie wiedziałbyś gdzie się zatrzymać: czy należy chwalić wszystkich za robienie zwyczajnych rzeczy? Ostatecznie jeśli pominiesz niektórych ludzi, to będą się zastanawiać dlaczego. Znacznie lepiej jest wypowiadać pochwały i wyrażać wdzięczność oszczędnie, jako reakcję na niezwykły lub nieoczekiwany wysiłek, w ramach zachęty do dalszych takich działań. Gdy widać, że uczestnik projektu na stałe wszedł na wyższy poziom produktywności, to odpowiednio podnieś swój próg pochwał dla tej osoby. Powtarzanie pochwał za normalne zachowanie i tak stopniowo staje się bezwartościowe. Taka osoba powinna zamiast tego odczuć, że jej nowy poziom produktywności jest teraz uznawany za normalny i naturalny, a tylko praca wykraczająca ponad ten poziom powinna zostać specjalnie zauważona. To oczywiście wcale nie znaczy, że wkład tej osoby nie powinien zostać odnotowany. Pamiętaj jednak, że jeśli projekt jest zbudowany prawidłowo, to wszystko co ta osoba robi już i tak jest widoczne, więc grupa o tym wszystkim wie (i ta osoba wie, że reszta grupy to wie). Poza tym istnieją także inne sposoby zauważania cudzej pracy niż bezpośrednia pochwała. Możesz na przykład przelotnie wspomnieć w trakcie rozmowy na związany temat, że wykonała ona wiele pracy w danym zakresie i jest w tych sprawach ekspertem; możesz publicznie konsultować się z nią w pewnych kwestiach dotyczących kodu; lub, zapewne najbardziej efektywnie, możesz w widoczny sposób wykorzystać wykonaną przez nią pracę, aby wiedziała, że inni bez obaw polegają na owocach jej pracy. Zapewne nie trzeba tego wszystkiego robić w żaden planowy sposób. Ktoś, kto regularnie dostarcza dużego wkładu do projektu, będzie o tym wiedział i domyślnie zajmie wpływową pozycję. Zazwyczaj nie potrzeba podejmować specjalnych kroków, aby to zapewnić, chyba że poczujesz, że z jakiegoś powodu jest on niedoceniany. Zapobiegaj terytorializmowi Uważaj na uczestników, którzy próbują zasadzać się na wyłączność w pewnych obszarach projektu, i którzy - jak się zdaje - chcą tam robić wszystko, posuwając się aż do agresywnego przejmowania pracy rozpoczętej przez innych. Takie zachowanie z początku może się wydawać nawet zdrowe. W końcu na pierwszy rzut oka wygląda na to, że bierze na siebie większą odpowiedzialność i wykazuje zwiększoną aktywność w danym obszarze. Ale na dłuższą metę jest to destrukcyjne. Kiedy ludzie wyczuwają znak "zakaz wstępu", trzymają się z daleka. To powoduje spadek przeglądów w tej części projektu i jej zwiększoną podatność na defekty, ponieważ samotny programista staje się najsłabszym ogniwem. Co gorsza, następuje też pęknięcie ducha równości i współpracy w projekcie. Teoretycznie zawsze powinno być tak, że dowolny uczestnik może pomagać w każdym zadaniu kiedy tylko zechce. Oczywiście w praktyce dzieje się nieco inaczej: w niektórych obszarach ludzie mają większe lub mniejsze wpływy, a osoby nie będące ekspertami często mają wzgląd na ekspertów w pewnych częściach projektu. Jednak wszystko to polega na dobrowolności: nieformalna władza jest przyznawana na podstawie kompetencji i sprawdzonego osądu, ale nigdy nie powinna być aktywnie zdobywana. Nawet gdy osoba chcąca mieć władzę naprawdę jest kompetentna, to i tak kluczową sprawą jest to, że sprawuje ją nieformalnie, poprzez konsensus w grupie, i że nigdy nie powoduje to wykluczania innych z pracy na tym obszarze. Odrzucanie lub modyfikowanie czyjejś pracy z powodów technicznych to oczywiście zupełnie co innego. W tym wypadku decyduje jej zawartość, a nie osoba, która akurat zachowuje się jak strażnik. Może się zdarzyć, że ta sama osoba wykonuje akurat najwięcej przeglądów w danym obszarze, ale dopóki nie próbuje powstrzymywać kogoś innego przed robieniem tego samego, to prawdopodobnie wszystko jest w porządku. W celu zwalczania zalążków terytorializmu, lub nawet jego pozorów, wiele projektów zabroniło umieszczania nazwisk autorów lub opiekunów w plikach źródłowych. Z całego serca popieram tę praktykę: stosujemy ją w projekcie Subversion i jest to mniej lub bardziej oficjalna reguła w Apache Software Foundation. Członek ASF, Sander Striker, mówi o tym w ten sposób:
W Apache Software Foundation odradzamy używania oznaczeń autorstwa w kodzie źródłowym. Są ku temu różne powody, niezależnie od wątków prawnych. Zbiorowa produkcja polega na pracy nad projektami jako grupa i dbaniu o nie jako grupa. Uznawanie zasług jest dobre i powinno mieć miejsce, ale w taki sposób, który nie pozwala na fałszywe przypisywanie zasług, nawet przez skojarzenie. Nie ma jasnych wytycznych kiedy dodawać lub usuwać oznaczenia autorstwa. Czy dodajesz swoje nazwisko gdy zmienisz komentarz? Gdy wstawisz poprawkę o wielkości jednego wiersza? Czy usuwasz oznaczenia innych autorów kiedy zreorganizujesz kod i w 95% wygląda on inaczej? Co zrobić z ludźmi którzy dotykają niemal każdego pliku, zmieniając tam tylko tyle by zwiększyć wirtualny udział autora, po to, żeby wszędzie było ich nazwisko? Istnieją lepsze sposoby uznawania zasług i wolimy korzystać właśnie z nich. Z technicznego punktu widzenia znaczniki autorstwa są niepotrzebne; jeśli chcesz wiedzieć, kto napisał konkretny fragment kodu, to wystarczy się odwołać do zapisów w systemie kontroli wersji. Znaczniki autorstwa łatwo też tracą na aktualności. Czy na pewno chcesz dostawać prywatną korespondencję na temat kawałka kodu, który napisałeś pięć lat temu i miałeś szczęście już o nim zapomnieć?
Pliki z kodem źródłowym są rdzeniem tożsamości projektu programu komputerowego. Powinny one odzwierciedlać fakt, że społeczność twórców jest za nie odpowiedzialna jako całość, a nie podzielona na małe lenna. Ludzie czasem obstają za oznaczeniem autorów lub opiekunów w plikach z kodem źródłowym argumentując, że daje to widoczne dowody uznania osobom, które wykonały najwięcej pracy. Z tym argumentem wiążą się dwa problemy. Po pierwsze, oznaczenia nieuchronnie wywołują kłopotliwe pytanie o to, ile pracy trzeba włożyć, aby można było umieścić tam także swoje nazwisko. Po drugie, mieszają oni uznawanie zasług z władzą: z wykonania pracy w przeszłości nie wynika własność obszaru, na którym została ona wykonana, a trudno - jeśli to w ogóle możliwe - uniknąć tego skojarzenia, kiedy nazwiska konkretnych osób znajdują się na początku plików z kodem źródłowym. W każdym przypadku wiadomości o zasługach można i tak uzyskać z zapisów systemu kontroli wersji oraz innymi drogami, na przykład przez archiwa list dyskusyjnych, więc żadne informacje nie giną z powodu wykluczenia ich z plików źródłowych. Jeśli twój projekt zdecyduje się zabronić umieszczania nazwisk w plikach z kodem źródłowym, to upewnij się, żeby nie przesadzić. Na przykład wiele projektów ma dział contrib/, gdzie znajdują się drobne narzędzia i skrypty pomocnicze, często pisane przez osoby nie związane z projektem w żaden inny sposób. Nie ma problemu z umieszczaniem nazwisk autorów w tych plikach, ponieważ tak naprawdę projekt jako całość nie opiekuje się nimi. Z drugiej strony jeśli inni ludzie z projektu zaczynają modyfikować takie narzędzie, to możesz ostatecznie zechcieć przenieść je do do mniej izolowanego miejsca i, zakładając że pierwotny autor wyrazi na to zgodę, usunąć jego nazwisko, aby ten kod wyglądał tak jak pozostałe zasoby, którymi opiekuje się społeczność. Jeśli autor jest wrażliwy na tym punkcie, to dopuszczalne są kompromisy, na przykład:
# indexclean.py: Usuwa stare dane z indeksu Scanley. # # Pierwotny autor: K. Maru <kobayashi@yetanotheremailservice.com> # Obecny opiekun: Projekt Scanley <http://www.scanley.org/> # i K. Maru. # # ...
Jeśli to możliwe, to lepiej jednak unikać takich kompromisów, a większość autorów daje się do tego przekonać, ponieważ są zadowoleni, że ich wkład staje się bardziej integralną częścią projektu. Najważniejsze jest aby pamiętać, że pomiędzy rdzeniem a peryferiami każdego projektu rozciąga się continuum. Główne pliki z kodem źródłowym programu oczywiście należą do rdzenia i powinno się uznawać, że opiekuje się nimi społeczność. Z kolei narzędzia towarzyszące lub fragmenty dokumentacji mogą być dziełem pojedynczych osób, które opiekują się nimi samodzielnie, nawet jeśli są powiązane z projektem lub wręcz są rozpowszechniane razem z nim. Nie ma potrzeby stosowania reguły "jeden rozmiar dla wszystkich" do każdego pliku dopóki utrzymywana jest zasada, że zasoby, którymi opiekuje się społeczność, nie mogą stać się czyimś wyłącznym terytorium. Współczynnik automatyzacji Staraj się nie dopuszczać do tego, aby ludzie wykonywali czynności, które mogłyby wykonać maszyny. Generalna zasada brzmi, że automatyzacja częstego zadania ma wartość przynajmniej dziesięć razy większą od wysiłku włożonego w pojedyncze ręczne wykonanie tego zadania. W przypadku zadań bardzo częstych lub bardzo złożonych ten współczynnik może z łatwością wynieść dwadzieścia lub nawet jeszcze więcej. Może się tu przydać potraktowanie siebie raczej jako "menedżera projektu" niż po prostu jednego ze współtwórców projektu. Czasami poszczególni uczestnicy są zbyt zajęci pracą u podstaw aby zobaczyć szerszą perspektywę i zdać sobie sprawę, że wszyscy marnują mnóstwo energii wykonując ręcznie zadania, które da się zautomatyzować. Nawet ci, którzy zdają sobie sprawę z tego problemu, mogą nie mieć czasu na jego rozwiązanie: ponieważ każdorazowe wykonanie danego zadania nie wydaje się dużym wysiłkiem, nikt nigdy nie zirytuje się na tyle, aby coś z tym zrobić. Automatyzacja staje się atrakcyjna, kiedy ten drobny wysiłek przemnoży się przez ilość razy, gdy ponosi go każdy z twórców, a następnie tę liczbę pomnoży się przez liczbę twórców. Używam tu pojęcia "automatyzacja" w szerokim znaczeniu, obejmującym nie tylko powtarzające się działania, które za każdym razem modyfikują zawartość jednej lub dwóch zmiennych, ale także dowolny rodzaj infrastruktury technicznej, która wspomaga ludzi. Minimum standardowej automatyzacji, niezbędnej do prowadzenia współczesnego projektu, prezentuje , ale każdy projekt może mieć także własne szczególne problemy. Na przykład grupa pracująca nad dokumentacją może chcieć założyć stronę internetową, na której będą zawsze dostępne najbardziej aktualne wersje dokumentów. Ponieważ dokumentacja jest często pisana w języku znaczników w rodzaju XML, to można dodać do tego etap kompilacji, zwykle dość zawiły, który będzie konwertować dokumenty do formatu odpowiedniego do ich przeglądania lub pobierania. Przygotowanie strony, która wykonuje taką kompilację automatycznie po każdej zmianie może być skomplikowane i czasochłonne - ale jest warte wykonania, nawet jeśli będzie cię to kosztować dzień lub więcej pracy. Suma korzyści z posiadania aktualnych stron dostępnych przez cały czas jest ogromna, nawet mimo tego, że koszt nie posiadania ich może się wydawać w danej chwili i dla danego człowieka jedynie drobną niedogodnością. Przedsięwzięcie takich kroków eliminuje nie tylko straty czasu, ale także przeszkody i frustracje pojawiające się w sytuacji, kiedy ludzie błądzą, a dzieje się tak zawsze wtedy, gdy próbują wykonywać skomplikowane procedury ręcznie. Ściśle określone ciągi operacji są dokładnie tym, do czego stworzono komputery; oszczędzaj swoich ludzi do bardziej interesujących zadań. Automatyczne testowanie Przeprowadzanie automatycznych testów jest przydatne w każdym projekcie oprogramowania, ale szczególnie w projektach wolnego oprogramowania, ponieważ automatyczne testowanie (zwłaszcza testowanie regresji) pozwala programistom czuć się pewnie podczas wprowadzania zmian w obszarach kodu, których nie znają, i przez to zachęca do bardziej odkrywczego rozwoju. Ponieważ powstawanie usterek jest tak trudne do ręcznego wykrywania - trzeba właściwie zgadywać gdzie ktoś mógł coś popsuć i próbować wykonywać różne eksperymenty, aby sprawdzić, że tego nie zrobił - używanie automatycznych metod znajdowania takich usterek oszczędza projektowi mnóstwo czasu. Daje to również poczucie bezpieczeństwa ludziom reorganizującym duże połacie kodu i w ten sposób przyczynia się do długoterminowej zdolności do opieki nad oprogramowaniem. Testowanie regresji Testowanie regresji oznacza sprawdzanie, czy nie nastąpił nawrót już naprawionych usterek. Celem testowania regresji jest zmniejszanie szans na to, że zmiany w kodzie wywołają nieprzewidziane błędy w oprogramowaniu. W miarę jak projekt programu rozrasta się i komplikuje, prawdopodobieństwo występowania takich niespodziewanych efektów ubocznych stale rośnie. Dobre planowanie może obniżyć tempo jego wzrostu, ale nie da się wyeliminować tego problemu całkowicie. W rezultacie wiele projektów posiada swój zestaw testów, osobny program, który wywołuje oprogramowanie projektu na takie sposoby, o których wiadomo że w przeszłości ujawniały konkretne błędy. Jeśli temu programowi uda się powtórzyć jeden z takich błędów, to nastąpiła regresja, innymi słowy czyjaś zmiana niespodziewanie zniweczyła zaaplikowaną wcześniej poprawkę. Zobacz też . Testowanie regresji nie jest lekiem na wszystko. W szczególności najlepiej sprawdza się w tych programach, które działają w trybie wsadowym. Programy, które wykorzystują głównie graficzne interfejsy użytkownika, są znacznie trudniejsze do opracowania programistycznie. Inny problem z mechanizmem testowania regresji polega na tym, że sam zestaw testów jest zwykle dość złożony i ma swoją własną krzywą uczenia się oraz swoje problemy związane z opieką nad nim. Redukcja tej złożoności jest jedną z najbardziej pożytecznych rzeczy, które możesz zrobić, nawet jeśli zajmuje to wiele czasu. Im łatwiej dodaje się nowe testy do zestawu, tym więcej programistów będzie to robić i tym mniej błędów przetrwa do chwili wydania. Każdy wysiłek poświęcony na upraszczanie pisania testów zaprocentuje wielokrotnie w trakcie istnienia projektu. Wiele projektów kieruje się zasadą "Nie psuj procesu budowania!", czyli: nie wprowadzaj zmian, które powodują że programu nie można skompilować lub uruchomić. Osoba, która to zrobi, zwykle odczuwa umiarkowane zażenowanie i staje się obiektem docinków. Projekty posiadające zestaw testów regresji zwykle stosują też dodatkową regułę: nie wprowadzaj zmian, przez które testy kończą się niepowodzeniem. Takie problemy są najłatwiejsze do wykrycia, gdy cały zestaw testów wykonywany jest co noc, a informacje o wynikach są przesyłane na roboczą listę dyskusyjną lub na osobną listę, przeznaczoną specjalnie do wyników testowania; to kolejny przykład cennej automatyzacji. Większość ochotników chętnie poświęci dodatkową ilość czasu na napisanie testów regresji, jeżeli system testów jest zrozumiały i wygodny w użyciu. Tworzenie testów towarzyszących zmianom kodu jest uważane za odpowiedzialne zachowanie, jest to także wyjątkowa okazja do współpracy: zazwyczaj dwóch programistów dzieli się pracą przy naprawianiu błędów, przy czym jeden pisze łatkę, a drugi test. Często okazuje się, że tego drugiego czeka więcej pracy, a ponieważ już samo pisanie testów daje mniej satysfakcji niż faktyczne naprawienie błędów, to nakazem jest, aby zestaw testów nie był bardziej męczący niż to konieczne. Niektóre projekty idą w tym jeszcze dalej, wymagając aby każdej poprawce lub nowej funkcji towarzyszył nowy test. To, czy jest to dobry pomysł, czy nie, zależy od kilku czynników: od natury danego oprogramowania, organizacji zespołu oraz od stopnia trudności pisania nowych testów. Projekt CVS () ma takie wymogi od dawna. Teoretycznie jest to dobra zasada, ponieważ CVS to system kontroli wersji i z tego powodu stara się unikać ryzyka zamazania lub niewłaściwego potraktowania danych użytkownika. W praktyce problem z zestawem testów regresji w CVS polega na tym, że jest to jeden ogromny skrypt powłoki (jak na ironię nazwany sanity.sh, czyli "rozsądek"), który trudno jest rozczytać, modyfikować czy rozszerzać. Trudność w dodawaniu nowych testów w połączeniu z wymaganiem, aby do łatek były dołączane nowe testy, powoduje że CVS praktycznie zniechęca twórców łatek. Kiedy pracowałem nad CVS, czasem byłem świadkiem tego jak ludzie zaczynali, a nawet ukończali łatki do kodu projektu, ale rezygnowali gdy dowiedzieli się o konieczności dodania nowego testu do sanity.sh. To normalne, że więcej czasu spędza się na pisaniu nowego testu regresji, niż na poprawianiu pierwotnego błędu. Ale CVS doprowadziło to zjawisko do absurdu: można spędzić wiele godzin na właściwym przygotowanie swoich testów, a i tak nie osiągnąć celu, ponieważ zmiany w skrypcie Basha o długości 35 tysięcy wierszy wywołują po prostu zbyt wiele nieprzewidywalnych skutków. Nawet doświadczeni programiści CVS zwykle narzekali, kiedy musieli dodać nowy test. Taka sytuacja jest wynikiem nie uwzględnienia współczynnika automatyzacji we wszystkich naszych działaniach. To prawda, że przejście do prawdziwego systemu testów - czy to własnej produkcji, czy też już przez kogoś napisanego - byłoby trudnym zadaniem. Zauważ, że nie trzeba by było konwertować istniejących testów do nowego systemu; oba mogłyby spokojnie istnieć obok siebie, stare testy byłyby przenoszone tylko wtedy, gdy zachodziłaby potrzeba dokonania w nich zmian. Ale odmowa wykonania go kosztuje projekt o wiele więcej, i to przez całe lata. Jak wiele poprawek i nowych funkcji nie ma dziś w CVS z powodu zawalidrogi w postaci niewygodnego zestawu testów? Nie wiemy tego dokładnie, ale na pewno jest to wielokrotnie więcej niż liczba poprawek lub nowych funkcji, bez których programiści musieliby się się obyć w celu stworzenia nowego systemu testów (lub integracji jakiegoś gotowego systemu). To zadanie zabrałoby tylko skończoną ilość czasu, podczas gdy negatywne konsekwencje używania obecnego zestawu testów nie ustaną nigdy, jeśli się tego nie zrobi. Problem nie w tym, że posiadanie ścisłych wymagań co do pisania testów jest złe, ani w tym, że pisanie systemu testów w postaci skryptu Basha jest zawsze niewłaściwe. Może to być dobre wyjście, w zależności od tego jak go zaprojektujesz i co chcesz testować. Rzecz po prostu w tym, że gdy system testów staje się znaczącą przeszkodą w rozwoju kodu, to trzeba coś z tym zrobić. Odnosi się to do wszystkich rutynowych czynności, które stają się barierą lub wąskim gardłem projektu. Traktuj każdego użytkownika jako potencjalnego ochotnika Każdy kontakt z użytkownikiem jest okazją do pozyskania nowego ochotnika. Kiedy użytkownik poświęca czas na napisanie wiadomości do jednej z list dyskusyjnych projektu lub na wypełnienie raportu błędu, to automatycznie sygnalizuje, że ma większy potencjał zaangażowania niż większość innych użytkowników (o których projekt nigdy nawet się nie dowie). Wykorzystaj ten potencjał: jeśli opisał błąd, to podziękuj mu za zgłoszenie i zapytaj, czy chciałby spróbować go naprawić. Jeśli dał znać, że w FAQ brakuje czegoś istotnego, lub że dokumentacja programu jest w jakiś sposób niekompletna, to potwierdź istnienie problemu (jeśli on naprawdę występuje) i zapytaj, czy interesuje go samodzielne dopisanie brakujących materiałów. Oczywiście w większości wypadków użytkownik odmówi. Ale pytanie nie kosztuje wiele, a za każdym razem kiedy to robisz, przypominasz innym osobom na forum, że każdy może się zaangażować w projekt. Nie ograniczaj swoich celów tylko do pozyskiwania nowych programistów i twórców dokumentacji. Na przykład samo uczenie ludzi jak prawidłowo wypełniać zgłoszenia błędów na dłuższą metę się opłaci, o ile tylko nie poświęcisz zbyt wiele czasu każdej takiej osobie, i o ile zamierzają oni przesyłać w przyszłości kolejne zgłoszenia - co jest bardziej prawdopodobne jeżeli otrzymali konstruktywną reakcję po swoim pierwszym zgłoszeniu. Konstruktywna reakcja nie musi polegać na naprawieniu błędu, choć jest to zawsze mile widziane; może to być prośba o więcej informacji lub nawet potwierdzenie, że opisane działanie faktycznie jest błędne. Ludzie chcą być wysłuchani. W następnej kolejności chcą pozbyć się błędu. Nie zawsze będziesz w stanie zapewnić im na czas to drugie, ale możesz (ty, lub raczej projekt jako całość) dać im to pierwsze. Wynika z tego, że uczestnicy projektu nie powinni wyrażać złości wobec osób, które wypełniły raporty błędów z jak najlepszymi intencjami, ale kiepsko. To jeden z moich ulubionych irytujących drobiazgów; widzę jak deweloperzy robią to bez przerwy na rozmaitych listach dyskusyjnych otwartych projektów, a szkody jakie w ten sposób czynią są namacalne. Pechowy nowicjusz wysyła bezwartościowe zgłoszenie:
Cześć, nie mogę zmusić Scanleya do działania. Za każdym razem, gdy go uruchamiam, pokazuje mi błąd. Czy ktoś jeszcze ma ten sam problem?
Deweloper - który widział takie zgłoszenia tysiące razy i nie zastanowił się nad tym, że nowicjusz ich dotąd nie widział - odpowiada w ten sposób:
I co niby mamy zrobić z taką skromną informacją? Rany. Podaj nam przynajmniej jakieś szczegóły, takie jak wersję Scanleya, jaki masz system operacyjny i co to jest za błąd.
Ten programista nie spojrzał na problem z punktu widzenia użytkownika, a także nie zastanowił się nad efektem jaki ta reakcja wywoła na innych osobach przyglądających się tej wymianie zdań. Naturalnie użytkownik bez wcześniejszych doświadczeń z programowaniem i zgłaszaniem błędów nie wie jak się to robi. Jak należy prawidłowo postępować wobec takich osób? Nauczyć je! I zrobić to w taki sposób, żeby chciały wrócić po więcej:
Przykro nam, że miałeś taki problem. Potrzebujemy więcej informacji aby zorientować się co się stało. Podaj nam swoją wersję Scanleya, jaki masz system operacyjny i dokładną treść komunikatu o błędzie. Najlepiej jeśli możesz nam wysłać dokładny zapis poleceń, jakie uruchamiałeś, i tego, co one wypisywały. Więcej informacji na ten temat znajdziesz pod adresem http://www.scanley.org/jak_zglaszac_bledy.html.
Taki rodzaj odpowiedzi jest znacznie bardziej efektywny przy zdobywaniu potrzebnych informacji, ponieważ jest ona pisana z punktu widzenia użytkownika. Po pierwsze, wyraża współczucie: Masz problem; czujemy twój ból. (Nie w każdej odpowiedzi na zgłoszenie jest to konieczne; zależy to od wagi problemu i od tego, jak bardzo użytkownik jest zdenerwowany.) Po drugie, zamiast lekceważyć go za brak wiedzy o zgłaszaniu błędów, instruuje jak ma to robić tak szczegółowo, aby rzeczywiście było to użyteczne - na przykład wielu użytkowników nie zdaje sobie sprawy z tego, że "pokaż nam błąd" oznacza "podaj nam dokładny komunikat błędu, bez pomijania i skracania tekstu." Kiedy kontaktujesz się z takim użytkownikiem po raz pierwszy, musisz to wyraźnie powiedzieć. Wreszcie otrzymuje też odnośnik do znacznie bardziej szczegółowej i kompletnej instrukcji zgłaszania błędów. Jeśli nawiązałeś odpowiedni kontakt z użytkownikiem, to zwykle poświęci on czas na przeczytanie tego dokumentu i wykonanie tego, co jest tam napisane. Oczywiście oznacza to, że taki dokument musi zostać wcześniej przygotowany. Powinien on dawać zrozumiałe instrukcje na temat tego, jakich informacji oczekuje zespół w każdym zgłoszeniu. W idealnym przypadku taki dokument powinien z czasem ewoluować w odpowiedzi na konkretne typy braków i błędów w zgłoszeniach, które użytkownicy nadsyłają do twojego projektu. Instrukcje zgłaszania błędów w projekcie Subversion są dość standardowe (zobacz ). Zwróć uwagę na zakończenie, gdzie znajduje się zaproszenie do wysyłania łatek naprawiających błąd. Nie chodzi o to, że takie zaproszenie doprowadzi do zwiększenia ilości łatek załączanych do zgłoszeń - większość użytkowników, którzy potrafią naprawiać błędy, zdaje sobie sprawę, że łatki są mile widziane, więc nie trzeba im tego uświadamiać. Faktycznym przesłaniem tego zaproszenia jest podkreślenie dla wszystkich czytających, zwłaszcza nowicjuszy w projekcie lub w ogóle w ruchu wolnego oprogramowania, że projekt opiera się na wkładzie ochotników. W pewnym sensie obecni uczestnicy nie są bardziej odpowiedzialni za naprawianie błędów niż osoby, które nadsyłają zgłoszenia. To istotna kwestia, która nowym użytkownikom może być często nieznana. Gdy już to zrozumieją, to rosną szanse, że pomogą naprawić błąd, jeżeli nie nadsyłając kod, to podając bardziej dokładną procedurę odtworzenia błędu lub oferując sprawdzanie poprawek nadesłanych przez kogoś innego. Ostatecznym celem jest uświadomienie każdemu użytkownikowi, że nie istnieje zasadnicza różnica między nim a ludźmi pracującymi nad projektem - że jest to tylko kwestia ile czasu i wysiłku się poświęca, a nie tego kim się jest. Przestroga przed nerwowymi reakcjami nie ma zastosowania wobec nieuprzejmych użytkowników. Czasami ludzie wysyłają zgłoszenia błędów lub skargi, które, niezależnie od ich zawartości merytorycznej, zawierają wyrazy szyderczej pogardy w stosunku do projektu z powodu jego braków. Często takie osoby zachowują się na przemian wyzywająco i uniżenie, jak ten człowiek, który napisał na listę dyskusyjną Subversion:
Czemu od 6 dni nadal nie ma żadnych binarek na platformę windows?!? Ciągle się to powtarza i jest dosyć frustrujące. Dlaczego to nie jest zautomatyzowane tak, żeby były dostępne natychmiast?? Kiedy wychodzi wersja "RC", to rozumiem że chodzi o to, aby użytkownicy ją przetestowali, ale przecież nie dajecie sposobu, żeby to zrobić. Po co w ogóle wyznaczać okres na testy, jeśli nie dajecie żadnej okazji do testowania??
Pierwsze reakcje na tę raczej zaczepną wiadomość były zaskakująco wstrzemięźliwe: ludzie wskazywali na to, że projekt opublikował zasadę nie przygotowywania oficjalnych binariów, i odpowiadali z różną dozą irytacji, że powinien ochotniczo zająć się przygotowywaniem ich samemu, jeśli są dla niego aż tak ważne. Wierzcie lub nie, ale następnym razem zaczął swoją wypowiedź słowami:
Przede wszystkim pozwólcie mi powiedzieć, że moim zdaniem Subversion jest wspaniałe i naprawdę doceniam wysiłki wszystkich osób zaangażowanych w ten projekt. [...]
...po czym znów zaczął krytykować projekt za nie publikowanie binariów, a jednocześnie nadal nie zamierzał sam niczego robić w tej sprawie. W tej sytuacji około 50 osób po prostu na niego wsiadło i nie mogę powiedzieć, żeby mnie to wzruszyło. Zasada "zero tolerancji" wobec agresji, zalecana w sekcji (), dotyczy osób, z którymi projekt ma (lub chciałby mieć) stały kontakt. Ale jeśli po kimś od razu widać, że będzie się z niego wylewać żółć, to nie ma sensu sprawiać wrażenia, że jest mile widziany. Takie sytuacje zdarzają się na szczęście dość rzadko i występują dużo rzadziej w projektach, które podejmują wysiłki konstruktywnego i uprzejmego włączania użytkowników do pracy już od pierwszego kontaktu. Rozdzielaj zarówno zadania techniczne jak i kierownicze Rozdzielaj zarówno ciężar zarządzania projektem, jak i ciężar zadań technicznych. W miarę jak projekt rośnie, coraz więcej pracy wiąże się z zarządzaniem ludźmi i przepływem informacji. Nie ma powodu, aby nie rozdzielać tego ciężaru, a w dodatku dzielenie się nim nie wymaga tworzenia ścisłej hierarchii - w praktyce kształtuje się raczej coś na kształt sieci wzajemnych powiązań, niż struktura dowodzenia w stylu wojskowym. Czasami role kierownicze są sformalizowane, a czasem tworzą się spontanicznie. W projekcie Subversion mamy menedżera łatek, menedżera tłumaczeń, menedżerów dokumentacji, menedżerów zgłoszeń (choć jest to rola nieoficjalna) oraz menedżera wydań. Niektóre z tych ról zostały powołane w wyniku naszej świadomej decyzji, inne po prostu powstały samorzutnie; spodziewam się, że wraz z rozwojem projektu liczba różnych ról będzie rosła. Poniżej znajdują się szczegółowe opisy tych - i kilku innych - funkcji (z wyjątkiem roli menedżera wydań, którą przedstawia sekcja oraz sekcja , znajdująca się wcześniej w tym samym rozdziale). Czytając te opisy zwróć uwagę, że żadna z funkcji nie implikuje wyłącznej kontroli w danej sprawie. Istnienie menedżera zgłoszeń nie oznacza, że inni ludzie nie mogą dotykać bazy zgłoszeń, menedżer FAQ nie upiera się, że ma być jedyną osobą uprawnioną do edycji listy najczęściej zadawanych pytań, i tak dalej. Sens tych ról polega na określeniu odpowiedzialności bez wprowadzania monopolu. Ważną częścią pracy każdego menedżera jest zwracanie uwagi na innych ludzi, którzy zajmują się danym zagadnieniem, i przekazywanie im swoich umiejętności wykonywania zadań na tym polu, aby raczej wspierać kolektywny wysiłek niż wywoływać konflikty. Menedżer powinien także dokumentować proces swojej pracy, aby w razie jego odejścia z funkcji ktoś inny mógł od razu przejąć cały kram. Czasem powstaje konflikt, gdy dwie lub więcej osób chce wykonywać tę samą rolę. Nie ma jednej metody na załatwienie tego problemu. Możesz zasugerować, aby każdy z nich wysłał swoją propozycję ("aplikację") i przeprowadzić wśród wszystkich uczestników projektu głosowanie, która jest najlepsza. Ale jest to niewygodne i potencjalnie niezręczne. Moim zdaniem lepszą techniką jest poproszenie kandydatów, aby ustalili to między sobą. Zwykle tak właśnie zrobią i będą bardziej zadowoleni z wyniku, niż gdyby ta decyzja została im narzucona z zewnątrz. Menedżer łatek W projekcie wolnego oprogramowania, do którego napływa wiele łatek, panowanie nad tym, które łatki nadeszły i co zdecydowano w ich sprawie, może stać się koszmarem, zwłaszcza w środowisku rozproszonym. Większość łatek napływa w postaci wiadomości na roboczą listę dyskusyjną projektu (choć niektóre mogą się najpierw pojawić w systemie śledzenia zgłoszeń lub na niezależnych stronach w sieci) i istnieje wiele różnych ścieżek, którymi może podążać zgłoszona łatka. Czasami ktoś przegląda łatkę, znajduje problem i odsyła ją z powrotem do jej autora w celu poprawienia. To zazwyczaj prowadzi do procesu wzajemnej wymiany wiadomości — wszystkie są widoczne na liście dyskusyjnej — w której pierwotny autor wysyła kolejne wersje łatki do chwili kiedy korektor nie ma już nic do krytykowania. Nie zawsze łatwo jest stwierdzić, kiedy ten proces się zakończył: jeśli korektor wprowadza łatkę do kodu, to z pewnością ten cykl się zakończył. Ale jeśli tego nie robi, to może wynikać po prostu z braku czasu lub stąd, że sam nie ma prawa zapisu i nie zdołał zmusić do tego innego programisty. Inną częstą reakcją na łatkę jest rozpętanie się dyskusji, niekoniecznie na temat samej łatki, ale dotyczącej tego czy sama jej idea jest słuszna. Na przykład łatka może naprawiać błąd, ale projekt woli to zrobić inaczej, w ramach naprawy bardziej ogólnej klasy problemów. Często nie wiadomo o tym od początku i dopiero pojawienie się łatki doprowadza do takiego rozwiązania. Zdarza się, że łatka spotyka się z głuchą ciszą. Zwykle dzieje się tak dlatego, że żaden programista akurat w tej chwili nie ma czasu na jej przejrzenie, więc każdy liczy na to, że zrobi to ktoś inny. Ponieważ nie ma żadnego limitu na to, ile każda z osób czeka aż ktoś podejmie pałeczkę, a w tym czasie zawsze wypływają inne ważne rzeczy, to łatka bardzo łatwo może się zagubić w sposób przez nikogo nie zamierzony. Projekt może w ten sposób przegapić użyteczną łatkę, a to może doprowadzić także do innych szkodliwych efektów ubocznych: może to zniechęcać autora, który włożył w tę łatkę swoją pracę, i sprawia wrażenie, jakby cały projekt nieco stracił kontakt z rzeczywistością, zwłaszcza w oczach innych osób planujących napisać łatkę. Zadaniem menedżera łatek jest upewnić się, że łatki nie "gubią się". Robi to śledząc każdą łatkę aż do momentu osiągnięcią przez nią swego rodzaju stabilności. Menedżer łatek obserwuje każdy wątek na liście wywołany przez wysłanie łatki. Jeśli kończy się to zapisem do kodu, to nic nie robi. Jeśli dochodzi do cyklu kolejnych przeglądów/rewizji, który kończy się finalną wersją łatki, ale bez zapisu, to wypełnia zgłoszenie wskazujące na finalną wersję oraz na związany z nią wątek na liście dyskusyjnej, aby pozostał trwały ślad dla programistów, którzy zajmą się tym potem. Jeśli łatka dotyczy istniejącego zgłoszenia, odpowiednio je opisuje zamiast otwierać nowe. Gdy łatka nie wzbudza żadnej reakcji, menedżer łatek czeka przez kilka dni, a następnie pyta czy ktoś zamierza się nią zająć. Zwykle to powoduje reakcję: programista może wyjaśnić, że jego zdaniem łatka nie powinna zostać zaaplikowana i podać przyczynę, albo przejrzeć łatkę, a wówczas idzie ona jedną z poprzednio podanych ścieżek. Jeżeli nadal nic się nie dzieje, menedżer łatek może - jeśli tak zdecyduje - wypełnić zgłoszenie dla tej łatki, ale autor łatki przynajmniej dostaje jakiś sygnał zwrotny. Posiadanie menedżera łatek zaoszczędziło zespołowi Subversion mnóstwo czasu i energii psychicznej. Bez osoby wyznaczonej do takiej roli każdy programista musiałby się ciągle zastanawiać: "Jeśli ja nie mam teraz czasu żeby odpowiedzieć na tę łatkę, to czy mogę liczyć, że ktoś inny to zrobi? Czy powinienem starać się o niej pamiętać? Ale jeśli inni także o niej z jakiegoś powodu pamiętają, to będzie to niepotrzebne dublowanie wysiłków." Osoba menedżera łatek oddala takie spekulacje. Każdy programista może podjąć odpowiednią dla siebie decyzję przy pierwszym kontakcie z łatką. Jeśli chce ją przejrzeć, to może to zrobić — menedżer łatek dostosuje się do tego. Jeśli chce zupełnie ją zignorować, to także jest w porządku; menedżer łatek zadba o to, aby nie została zapomniana. Ponieważ ten system działa tylko jeśli ludzie mogą ślepo polegać na obecności menedżera łatek, ta rola powinna być obejmowana formalnie. W Subversion ogłaszaliśmy poszukiwania do niej na liście roboczej i na liście użytkowników, a ze zgłaszających się ochotników wybieraliśmy tego, który pierwszy odpowiedział. Kiedy ta osoba musiała zrezygnować (zobacz sekcję dalej w tym rozdziale), powtarzaliśmy ten proces. Nigdy nie próbowaliśmy obsadzić w tej roli więcej niż jedną osobę, ponieważ wymagałoby to dodatkowej komunikacji między nimi; ale być może w warunkach dużych ilości zgłaszanych łatek taki zespołowy menedżer mógłby mieć sens. Menedżer tłumaczeń In software projects, "translation" can refer to two very different things. It can mean translating the software's documentation into other languages, or it can mean translating the software itself—that is, having the program display errors and help messages in the user's preferred language. Both are complex tasks, but once the right infrastructure is in place, they are largely separable from other development. Because the tasks are similar in some ways, it may make sense (depending on your project) to have a single translation manager handle both, or it may be better to have two different managers. In the Subversion project, we have one translation manager handle both. He does not actually write the translations himself, of course—he may help out on one or two, but as of this writing, he would need to speak ten languages (twelve counting dialects) in order to work on all of them! Instead, he manages teams of volunteer translators: he helps them coordinate among each other, and he coordinates between the teams and the rest of the project. Part of the reason the translation manager is necessary is that translators are a different demographic from developers. They sometimes have little or no experience working in a version control repository, or indeed with working as part of a distributed volunteer team at all. But in other respects they are often the best kind of volunteer: people with specific domain knowledge who saw a need and chose to get involved. They are usually willing to learn, and enthusiastic to get to work. All they need is someone to tell them how. The translation manager makes sure that the translations happen in a way that does not interfere unnecessarily with regular development. He also serves as a sort of representative of the translators as a unified body, whenever the developers must be informed of technical changes required to support the translation effort. Thus, the position's most important skills are diplomatic, not technical. For example, in Subversion we have a policy that all translations should have at least two people working on them, because otherwise there is no way for the text to be reviewed. When a new volunteer shows up offering to translate Subversion to, say, Malagasy, the translation manager has to either hook him up with someone who posted six months ago expressing interest in doing a Malagasy translation, or else politely ask the volunteer to go find another Malagasy translator to work with as a partner. Once enough people are available, the manager sets them up with the proper kind of commit access, informs them of the project's conventions (such as how to write log messages), and then keeps an eye out to make sure they adhere to those conventions. Conversations between the translation manager and the developers, or between the translation manager and translation teams, are usually held in the project's original language—that is, the language from which all the translations are being made. For most free software projects, this is English, but it doesn't matter what it is as long as the project agrees on it. (English is probably best for projects that want to attract a broad international development community, though.) Conversations within a particular translation team usually happen in their shared language, however, and one of the other tasks of the translation manager is to set up a dedicated mailing list for each team. That way the translators can discuss their work freely, without distracting people on the project's main lists, most of whom would not be able to understand the translation language anyway. Internacjonalizacja a lokalizacja Internationalization (I18N) and localization (L10N) both refer to the process of adapting a program to work in linguistic and cultural environments other than the one for which it was originally written. The terms are often treated as interchangeable, but in fact they are not quite the same thing. As writes:
The distinction between them is subtle but important: Internationalization is the adaptation of products for potential use virtually everywhere, while localization is the addition of special features for use in a specific locale.
For example, changing your software to losslessly handle Unicode () text encodings is an internationalization move, since it's not about a particular language, but rather about accepting text from any of a number of languages. On the other hand, making your software print all error messages in Slovenian, when it detects that it is running in a Slovenian environment, is a localization move. Thus, the translation manager's task is principally about localization, not internationalization. Menedżer dokumentacji Keeping software documentation up-to-date is a never-ending task. Every new feature or enhancement that goes into the code has the potential to cause a change in the documentation. Also, once the project's documentation reaches a certain level of completeness, you will find that a lot of the patches people send in are for the documentation, not for the code. This is because there are many more people competent to fix bugs in prose than in code: all users are readers, but only a few are programmers. Documentation patches are usually much easier to review and apply than code patches. There is little or no testing to be done, and the quality of the change can be evaluated quickly just by review. Since the quantity is high, but the review burden fairly low, the ratio of administrative overhead to productive work is greater for documentation patches than for code patches. Furthermore, most of the patches will probably need some sort of adjustment, in order to maintain a consistent authorial voice in the documentation. In many cases, patches will overlap with or affect other patches, and need to be adjusted with respect to each other before being committed. Given the exigencies of handling documentation patches, and the fact that the code base needs to be constantly monitored so the documentation can be kept up-to-date, it makes sense to have one person, or a small team, dedicated to the task. They can keep a record of exactly where and how the documentation lags behind the software, and they can have practiced procedures for handling large quantities of patches in an integrated way. Of course, this does not preclude other people in the project from applying documentation patches on the fly, especially small ones, as time permits. And the same patch manager (see earlier in this chapter) can track both code and documentation patches, filing them wherever the development and documentation teams want them, respectively. (If the total quantity of patches ever exceeds one human's capacity to track, though, switching to separate patch managers for code and documentation is probably a good first step.) The point of a documentation team is to have people who think of themselves as responsible for keeping the documentation organized, up-to-date, and consistent with itself. In practice, this means knowing the documentation intimately, watching the code base, watching the changes others commit to the documentation, watching for incoming documentation patches, and using all these information sources to do whatever is necessary to keep the documentation healthy. Menedżer zgłoszeń The number of issues in a project's bug tracker grows in proportion to the number of people using the software. Therefore, even as you fix bugs and ship an increasingly robust program, you should still expect the number of open issues to grow essentially without bound. The frequency of duplicate issues will also increase, as will the frequency of incomplete or poorly described issues. Issue managers help alleviate these problems by watching what goes into the database, and periodically sweeping through it looking for specific problems. Their most common action is probably to fix up incoming issues, either because the reporter didn't set some of the form fields correctly, or because the issue is a duplicate of one already in the database. Obviously, the more familiar an issue manager is with the project's bug database, the more efficiently she will be able to detect duplicate issues—this is one of the main advantages of having a few people specialize in the bug database, instead of everyone trying to do it ad hoc. When the group tries to do it in a decentralized manner, no single individual acquires a deep expertise in the content of the database. Issue managers can also help map between issues and individual developers. When there are a lot of bug reports coming in, not every developer may read the issue notification mailing list with equal attention. However, if someone who knows the development team is keeping an eye on all incoming issues, then she can discreetly direct certain developers' attention to specific bugs when appropriate. Of course, this has to be done with a sensitivity to everything else going on in development, and to the recipient's desires and temperament. Therefore, it is often best for issue managers to be developers themselves. Depending on how your project uses the issue tracker, issue managers can also shape the database to reflect the project's priorities. For example, in Subversion we schedule issues into specific future releases, so that when someone asks "When will bug X be fixed?" we can say "Two releases from now," even if we can't give an exact date. The releases are represented in the issue tracker as target milestones, a field available in IssueZilla.IssueZilla is the issue tracker we use; it is a descendant of BugZilla. As a rule, every Subversion release has one major new feature and a list of specific bug fixes. We assign the appropriate target milestone to all the issues planned for that release (including the new feature—it gets an issue too), so that people can view the bug database through the lens of release scheduling. These targets rarely remain static, however. As new bugs come in, priorities sometimes get shifted around, and issues must be moved from one milestone to another so that each release remains manageable. This, again, is best done by people who have an overall sense of what's in the database, and how various issues relate to each other. Another thing issue managers do is notice when issues become obsolete. Sometimes a bug is fixed accidentally as part of an unrelated change to the software, or sometimes the project changes its mind about whether a certain behavior is buggy. Finding obsoleted issues is not easy: the only way to do it systematically is by making a sweep over all the issues in the database. Full sweeps become less and less feasible over time, however, as the number of issues grows. After a certain point, the only way to keep the database sane is to use a divide-and-conquer approach: categorize issues immediately on arrival and direct them to the appropriate developer's or team's attention. The recipient then takes charge of the issue for the rest of its lifetime, shepherding it to resolution or oblivion as necessary. When the database is that large, the issue manager becomes more of an overall coordinator, spending less time looking at each issue herself and more time getting it into the right person's hands. Menedżer FAQ FAQ maintenance is a surprisingly difficult problem. Unlike most other documents in a project, whose content is planned out in advance by the authors, a FAQ is a wholly reactive document (see ). No matter how big it gets, you still never know what the next addition will be. And because it is always added to piecemeal, it is very easy for the document as a whole to become incoherent and disorganized, and even to contain duplicate or semi-duplicate entries. Even when it does not have any obvious problems like that, there are often unnoticed interdependencies between items—links that should be made but aren't—because the related items were added a year apart. The role of a FAQ manager is twofold. First, she maintains the overall quality of the FAQ by staying familiar with at least the topics of all the questions in it, so that when people add new items that are duplicates of, or related to, existing items, the appropriate adjustments can be made. Second, she watches the project mailing lists and other forums for recurring problems or questions, and to write new FAQ entries based on this input. This latter task can be quite complex: one must be able to follow a thread, recognize the core questions raised in it, post a proposed FAQ entry, incorporate comments from others (since it's impossible for the FAQ manager to be an expert in every topic covered by the FAQ), and sense when the process is finished so the item can at last be added. The FAQ manager usually also becomes the default expert in FAQ formatting. There are a lot of little details involved in keeping a FAQ in shape (see in ); when random people edit the FAQ, they will sometimes forget some of these details. That's okay, as long as the FAQ manager is there to clean up after them. Various free software is available to help with the process of FAQ maintenance. It's fine to use it, as long as it doesn't compromise the quality of the FAQ, but beware of over-automation. Some projects try to fully automate the process of FAQ maintenance, allowing everyone to contribute and edit FAQ items in a manner similar to a wiki (see in ). I've seen this happen particularly with Faq-O-Matic (), though it may be that the cases I saw were simply abuses that went beyond what Faq-O-Matic was originally intended for. In any case, while complete decentralization of FAQ maintenance does reduce the workload for the project, it also results in a poorer FAQ. There's no one person with a broad view of the entire FAQ, no one to notice when certain items need updating or become obsolete entirely, and no one keeping watch for interdependencies between items. The result is a FAQ that often fails to provide users what they were looking for, and in the worst cases misleads them. Use whatever tools you need to to maintain your project's FAQ, but never let the convenience of the tools seduce you into compromising the quality of the FAQ. See Sean Michael Kerner's article, The FAQs on FAQs, at , for descriptions and evaluations of open source FAQ maintenance tools. Przekazywanie obowiązków From time to time, a volunteer in a position of ongoing responsibility (e.g., patch manager, translation manager, etc.) will become unable to perform the duties of the position. It may be because the job turned out to be more work than he anticipated, or it may be due to completely external factors: marriage, a new baby, a new employer, or whatever. When a volunteer gets swamped like this, he usually doesn't notice it right away. It happens by slow degrees, and there's no point at which he consciously realizes that he can no longer fulfill the duties of the role. Instead, the rest of the project just doesn't hear much from him for a while. Then there will suddenly be a flurry of activity, as he feels guilty for neglecting the project for so long and sets aside a night to catch up. Then you won't hear from him for a while longer, and then there might or might not be another flurry. But there's rarely an unsolicited formal resignation. The volunteer was doing the job in his spare time, so resigning would mean openly acknowledging to himself that his spare time is permanently reduced. People are often reluctant to do that. Therefore, it's up to you and the others in the project to notice what's happening—or rather, not happening—and to ask the volunteer what's going on. The inquiry should be friendly and 100% guilt-free. Your purpose is to find out a piece of information, not to make the person feel bad. Generally, the inquiry should be visible to the rest of the project, but if you know of some special reason why a private inquiry would be better, that's fine too. The main reason to do it publicly is so that if the volunteer responds by saying that he won't be able to do the job anymore, there's a context established for your next public post: a request for a new volunteer to fill that role. Sometimes, a volunteer is unable to do the job he's taken on, but is either unaware or unwilling to admit that fact. Of course, anyone may have trouble at first, especially if the responsibility is complex. However, if someone just isn't working out in the task he's taken on, even after everyone else has given all the help and suggestions they can, then the only solution is for him to step aside and let someone new have a try. And if the person doesn't see this himself, he'll need to be told. There's basically only one way to handle this, I think, but it's a multistep process and each step is important. First, make sure you're not crazy. Privately talk to others in the project to see if they agree that the problem is as serious as you think it is. Even if you're already positive, this serves the purpose of letting others know that you're considering asking the person to step aside. Usually no one will object to that—they'll just be happy you're taking on the awkward task, so they don't have to! Next, privately contact the volunteer in question and tell him, kindly but directly, about the problems you see. Be specific, giving as many examples as possible. Make sure to point out how people had tried to help, but that the problems persisted without improving. You should expect this email to take a long time to write, but with this sort of message, if you don't back up what you're saying, you shouldn't say it at all. Say that you would like to find a new volunteer to fill the role, but also point out that there are many other ways to contribute to the project. At this stage, don't say that you've talked to others about it; nobody likes to be told that people were conspiring behind his back. There are a few different ways things can go after that. The most likely reaction is that he'll agree with you, or at any rate not want to argue, and be willing to step down. In that case, suggest that he make the announcement himself, and then you can follow up with a post seeking a replacement. Or, he may agree that there have been problems, but ask for a little more time (or for one more chance, in the case of discrete-task roles like release manager). How you react to that is a judgement call, but whatever you do, don't agree to it just because you feel like you can't refuse such a reasonable request. That would prolong the agony, not lessen it. There is often a very good reason to refuse the request, namely, that there have already been plenty of chances, and that's how things got to where they are now. Here's how I put it in a mail to someone who was filling the release manager role but was not really suited for it:
> If you wish to replace me with some one else, I will gracefully > pass on the role to who comes next. I have one request, which > I hope is not unreasonable. I would like to attempt one more > release in an effort to prove myself. I totally understand the desire (been there myself!), but in this case, we shouldn't do the "one more try" thing. This isn't the first or second release, it's the sixth or seventh... And for all of those, I know you've been dissatisfied with the results too (because we've talked about it before). So we've effectively already been down the one-more-try route. Eventually, one of the tries has to be the last one... I think [this past release] should be it.
In the worst case, the volunteer may disagree outright. Then you have to accept that things are going to be awkward and plow ahead anyway. Now is the time to say that you talked to other people about it (but still don't say who until you have their permission, since those conversations were confidential), and that you don't think it's good for the project to continue as things are. Be insistent, but never threatening. Keep in mind that with most roles, the transition really happens the moment someone new starts doing the job, not the moment the old person stops doing it. For example, if the contention is over the role of, say, issue manager, at any point you and other influential people in the project can solicit for a new issue manager. It's not actually necessary that the person who was previously doing it stop doing it, as long as he does not sabotage (deliberately or otherwise) the efforts of the new volunteer. Which leads to a tempting thought: instead of asking the person to resign, why not just frame it as a matter of getting him some help? Why not just have two issue managers, or patch managers, or whatever the role is? Although that may sound nice in theory, it is generally not a good idea. What makes the manager roles work—what makes them useful, in fact—is their centralization. Those things that can be done in a decentralized fashion are usually already being done that way. Having two people fill one managerial role introduces communications overhead between those two people, as well as the potential for slippery displacement of responsibility ("I thought you brought the first aid kit!" "Me? No, I thought you brought the first aid kit!"). Of course, there are exceptions. Sometimes two people work extremely well together, or the nature of the role is such that it can easily be spread across multiple people. But these are not likely to be of much use when you see someone flailing in a role he is not suited for. If he'd appreciated the problem in the first place, he would have sought such help before now. In any case, it would be disrespectful to let someone waste time continuing to do a job no one will pay attention to. The most important factor in asking someone to step down is privacy: giving him the space to make a decision without feeling like others are watching and waiting. I once made the mistake—an obvious mistake, in retrospect—of mailing all three parties at once in order to ask Subversion's release manager to step aside in favor of two other volunteers. I'd already talked to the two new people privately, and knew that they were willing to take on the responsibility. So I thought, naïvely and somewhat insensitively, that I'd save some time and hassle by sending one mail to all of them to initiate the transition. I assumed that the current release manager was already fully aware of the problems and would see the reasonableness of my point immediately. I was wrong. The current release manager was very offended, and rightly so. It's one thing to be asked to hand off the job; it's another thing to be asked that in front of the people you'll hand it off to. Once I got it through my head why he was offended, I apologized. He eventually did step aside gracefully, and continues to be involved with the project today. But his feelings were hurt, and needless to say, this was not the most auspicious of beginnings for the new volunteers either. Prawo zapisu As the only formally distinct class of people found in all open source projects, committers deserve special attention here. Committers are an unavoidable concession to discrimination in a system which is otherwise as non-discriminatory as possible. But "discrimination" is not meant as a pejorative here. The function committers perform is utterly necessary, and I do not think a project could succeed without it. Quality control requires, well, control. There are always many people who feel competent to make changes to a program, and some smaller number who actually are. The project cannot rely on people's own judgement; it must impose standards and grant commit access only to those who meet themNote that the commit access means something a bit different in decentralized version control systems, where anyone can set up a repository that is linked into the project, and give themselves commit access to that repository. Nevertheless, the concept of commit access still applies: "commit access" is shorthand for "the right to make changes to the code that will ship in the group's next release of the software." In centralized version control systems, this means having direct commit access; in decentralized ones, it means having one's changes pulled into the main distribution by default. It is the same idea either way; the mechanics by which it is realized are not terribly important.. On the other hand, having people who can commit changes directly working side-by-side with people who cannot sets up an obvious power dynamic. That dynamic must be managed so that it does not harm the project. In in , we already discussed the mechanics of considering new committers. Here we will look at the standards by which potential new committers should be judged, and how this process should be presented to the larger community. Przyznawanie prawa zapisu In the Subversion project, we choose committers primarily on the Hippocratic Principle: first, do no harm. Our main criterion is not technical skill or even knowledge of the code, but merely that the committer show good judgement. Judgement can mean simply knowing what not to take on. A person might post only small patches, fixing fairly simple problems in the code; but if the patches apply cleanly, do not contain bugs, and are mostly in accord with the project's log message and coding conventions, and there are enough patches to show a clear pattern, then an existing committer will usually propose that person for commit access. If at least three people say yes, and no one objects, then the offer is made. True, we might have no evidence that the person is able to solve complex problems in all areas of the code base, but that does not matter: the person has made it clear that he is capable of at least judging his own abilities. Technical skills can be learned (and taught), but judgement, for the most part, cannot. Therefore, it is the one thing you want to make sure a person has before you give him commit access. When a new committer proposal does provoke a discussion, it is usually not about technical ability, but rather about the person's behavior on the mailing lists or in IRC. Sometimes someone shows technical skill and an ability to work within the project's formal guidelines, yet is also consistently belligerent or uncooperative in public forums. That's a serious concern; if the person doesn't seem to shape up over time, even in response to hints, then we won't add him as a committer no matter how skilled he is. In a volunteer group, social skills, or the ability to "play well in the sandbox", are as important as raw technical ability. Because everything is under version control, the penalty for adding a committer you shouldn't have is not so much the problems it could cause in the code (review would spot those quickly anyway), but that it might eventually force the project to revoke the person's commit access—an action that is never pleasant and can sometimes be confrontational. Many projects insist that the potential committer demonstrate a certain level of technical expertise and persistence, by submitting some number of nontrivial patches—that is, not only do these projects want to know that the person will do no harm, they want to know that she is likely to do good across the code base. This is fine, but be careful that it doesn't start to turn committership into a matter of membership in an exclusive club. The question to keep in everyone's mind should be "What will bring the best results for the code?" not "Will we devalue the social status associated with committership by admitting this person?" The point of commit access is not to reinforce people's self-worth, it's to allow good changes to enter the code with a minimum of fuss. If you have 100 committers, 10 of whom make large changes on a regular basis, and the other 90 of whom just fix typos and small bugs a few times a year, that's still better than having only the 10. Odbierania prawa zapisu The first thing to be said about revoking commit access is: try not to be in that situation in the first place. Depending on whose access is being revoked, and why, the discussions around such an action can be very divisive. Even when not divisive, they will be a time-consuming distraction from productive work. However, if you must do it, the discussion should be had privately among the same people who would be in a position to vote for granting that person whatever flavor of commit access they currently have. The person herself should not be included. This contradicts the usual injunction against secrecy, but in this case it's necessary. First, no one would be able to speak freely otherwise. Second, if the motion fails, you don't necessarily want the person to know it was ever considered, because that could open up questions ("Who was on my side? Who was against me?") that lead to the worst sort of factionalism. In certain rare circumstances, the group may want someone to know that revocation of commit access is or was being considered, as a warning, but this openness should be a decision the group makes. No one should ever, on her own initiative, reveal information from a discussion and ballot that others assumed were secret. Once someone's access is revoked, that fact is unavoidably public (see later in this chapter), so try to be as tactful as you can in how it is presented to the outside world. Częściowe prawo zapisu Some projects offer gradations of commit access. For example, there might be contributors whose commit access gives them free rein in the documentation, but who do not commit to the code itself. Common areas for partial commit access include documentation, translations, binding code to other programming languages, specification files for packaging (e.g., RedHat RPM spec files, etc.), and other places where a mistake will not result in a problem for the core project. Since commit access is not only about committing, but about being part of an electorate (see in ), the question naturally arises: what can the partial committers vote on? There is no one right answer; it depends on what sorts of partial commit domains your project has. In Subversion we've kept things fairly simple: a partial committer can vote on matters confined exclusively to that committer's domain, and not on anything else. Importantly, we do have a mechanism for casting advisory votes (essentially, the committer writes "+0" or "+1 (non-binding)" instead of just "+1" on the ballot). There's no reason to silence people entirely just because their vote isn't formally binding. Full committers can vote on anything, just as they can commit anywhere, and only full committers vote on adding new committers of any kind. In practice, though, the ability to add new partial committers is usually delegated: any full committer can "sponsor" a new partial committer, and partial committers in a domain can often essentially choose new committers for that same domain (this is especially helpful in making translation work run smoothly). Your project may need a slightly different arrangement, depending on the nature of the work, but the same general principles apply to all projects. Each committer should be able to vote on matters that fall within the scope of her commit access, and not on matters outside that, and votes on procedural questions should default to the full committers, unless there's some reason (as decided by the full committers) to widen the electorate. Regarding enforcement of partial commit access: it's often best not to have the version control system enforce partial commit domains, even if it can. See in for the reasons why. Niewykorzystywane prawo zapisu Some projects automatically remove people's commit access if they go a certain amount of time (say, a year) without committing anything. I think this is usually unhelpful and even counterproductive, for two reasons. First, it may tempt some people into committing acceptable but unnecessary changes, just to prevent their commit access from expiring. Second, it doesn't really serve any purpose. If the main criterion for granting commit access is good judgement, then why assume someone's judgement would deteriorate just because he's away from the project for a while? Even if he completely vanishes for years, not looking at the code or following development discussions, when he reappears he'll know how out of touch he is, and act accordingly. You trusted his judgement before, so why not trust it always? If high school diplomas do not expire, then commit access certainly shouldn't. Sometimes a committer may ask to be removed, or to be explicitly marked as dormant in the list of committers (see below for more about that list). In these cases, the project should accede to the person's wishes, of course. Unikaj tajemnic Although the discussions around adding any particular new committer must be confidential, the rules and procedures themselves need not be secret. In fact, it's best to publish them, so people realize that the committers are not some mysterious Star Chamber, closed off to mere mortals, but that anyone can join simply by posting good patches and knowing how to handle herself in the community. In the Subversion project, we put this information right in the developer guidelines document, since the people most likely to be interested in how commit access is granted are those thinking of contributing code to the project. In addition to publishing the procedures, publish the actual list of committers. The traditional place for this is a file called MAINTAINERS or COMMITTERS in the top level of the project's source code tree. It should list all the full committers first, followed by the various partial commit domains and the members of each domain. Each person should be listed by name and email address, though the address can be encoded to prevent spam (see in ) if the person prefers that. Since the distinction between full commit and partial commit access is obvious and well defined, it is proper for the list to make that distinction too. Beyond that, the list should not try to indicate the informal distinctions that inevitably arise in a project, such as who is particularly influential and how. It is a public record, not an acknowledgments file. List committers either in alphabetical order, or in the order in which they arrived. Uznanie zasług Credit is the primary currency of the free software world. Whatever people may say about their motivations for participating in a project, I don't know any developers who would be happy doing all their work anonymously, or under someone else's name. There are tangible reasons for this: one's reputation in a project roughly governs how much influence one has, and participation in an open source project can also indirectly have monetary value, because some employers now look for it on resumés. There are also intangible reasons, perhaps even more powerful: people simply want to be appreciated, and instinctively look for signs that their work was recognized by others. The promise of credit is therefore one of best motivators the project has. When small contributions are acknowledged, people come back to do more. One of the most important features of collaborative development software (see ) is that it keeps accurate records of who did what, when. Wherever possible, use these existing mechanisms to make sure that credit is distributed accurately, and be specific about the nature of the contribution. Don't just write "Thanks to J. Random <jrandom@example.com>" if instead you can write "Thanks to J. Random <jrandom@example.com> for the bug report and reproduction recipe" in a log message. In Subversion, we have an informal but consistent policy of crediting the reporter of a bug in either the issue filed, if there is one, or the log message of the commit that fixes the bug, if not. A quick survey of Subversion commit logs up to commit number 14525 shows that about 10% of commits give credit to someone by name and email address, usually the person who reported or analyzed the bug fixed by that commit. Note that this person is different from the developer who actually made the commit, whose name is already recorded automatically by the version control system. Of the 80-odd full and partial committers Subversion has today, 55 were credited in the commit logs (usually multiple times) before they became committers themselves. This does not, of course, prove that being credited was a factor in their continued involvement, but it at least sets up an atmosphere in which people know they can count on their contributions being acknowledged. It is important to distinguish between routine acknowledgment and special thanks. When discussing a particular piece of code, or some other contribution someone made, it is fine to acknowledge their work. For example, saying "Daniel's recent changes to the delta code mean we can now implement feature X" simultaneously helps people identify which changes you're talking about and acknowledges Daniel's work. On the other hand, posting solely to thank Daniel for the delta code changes serves no immediate practical purpose. It doesn't add any information, since the version control system and other mechanisms have already recorded the fact that he made the changes. Thanking everyone for everything would be distracting and ultimately information-free, since thanks are effective largely by how much they stand out from the default, background level of favorable comment going on all the time. This does not mean, of course, that you should never thank people. Just make sure to do it in ways that tend not to lead to credit inflation. Following these guidelines will help: The more ephemeral the forum, the more free you should feel to express thanks there. For example, thanking someone for their bugfix in passing during an IRC conversation is fine, as is an aside in an email devoted mainly to other topics. But don't post an email solely to thank someone, unless it's for a truly unusual feat. Likewise, don't clutter the project's web pages with expressions of gratitude. Once you start that, it'll never be clear when or where to stop. And never put thanks into comments in the code; that would only be a distraction from the primary purpose of comments, which is to help the reader understand the code. The less involved someone is in the project, the more appropriate it is to thank her for something she did. This may sound counterintuitive, but it fits with the attitude that expressing thanks is something you do when someone contributes even more than you thought she would. Thus, to constantly thank regular contributors for doing what they normally do would be to express a lower expectation of them than they have of themselves. If anything, you want to aim for the opposite effect! There are occasional exceptions to this rule. It's acceptable to thank someone for fulfilling his expected role when that role involves temporary, intense efforts from time to time. The canonical example is the release manager, who goes into high gear around the time of each release, but otherwise lies dormant (dormant as a release manager, in any case—he may also be an active developer, but that's a different matter). As with criticism and crediting, gratitude should be specific. Don't thank people just for being great, even if they are. Thank them for something they did that was out of the ordinary, and for bonus points, say exactly why what they did was so great. In general, there is always a tension between making sure that people's individual contributions are recognized, and making sure the project is a group effort rather than a collection of individual glories. Just remain aware of this tension and try to err on the side of group, and things won't get out of hand. Rozwidlenia In in , we saw how the potential to fork has important effects on how projects are governed. But what happens when a fork actually occurs? How should you handle it, and what effects can you expect it to have? Conversely, when should you initiate a fork? The answers depend on what kind of fork it is. Some forks are due to amicable but irreconcilable disagreements about the direction of the project; perhaps more are due to both technical disagreements and interpersonal conflicts. Of course, it's not always possible to tell the difference between the two, as technical arguments may involve personal elements as well. What all forks have in common is that one group of developers (or sometimes even just one developer) has decided that the costs of working with some or all of the others now outweigh the benefits. Once a project forks, there is no definitive answer to the question of which fork is the "true" or "original" project. People will colloquially talk of fork F coming out of project P, as though P is continuing unchanged down some natural path while F diverges into new territory, but this is, in effect, a declaration of how that particular observer feels about it. It is fundamentally a matter of perception: when a large enough percentage of observers agree, the assertion starts to become true. It is not the case that there is an objective truth from the outset, one that we are only imperfectly able to perceive at first. Rather, the perceptions are the objective truth, since ultimately a project—or a fork—is an entity that exists only in people's minds anyway. If those initiating the fork feel that they are sprouting a new branch off the main project, the perception question is resolved immediately and easily. Everyone, both developers and users, will treat the fork as a new project, with a new name (perhaps based on the old name, but easily distinguishable from it), a separate web site, and a separate philosophy or goal. Things get messier, however, when both sides feel they are the legitimate guardians of the original project and therefore have the right to continue using the original name. If there is some organization with trademark rights to the name, or legal control over the domain or web pages, that usually resolves the issue by fiat: that organization will decide who is the project and who is the fork, because it holds all the cards in a public relations war. Naturally, things rarely get that far: since everyone already knows what the power dynamics are, they will avoid fighting a battle whose outcome is known in advance, and just jump straight to the end. Fortunately, in most cases there is little doubt as to which is the project and which is the fork, because a fork is, in essence, a vote of confidence. If more than half of the developers are in favor of whatever course the fork proposes to take, usually there is no need to fork—the project can simply go that way itself, unless it is run as a dictatorship with a particularly stubborn dictator. On the other hand, if fewer than half of the developers are in favor, the fork is a clearly minority rebellion, and both courtesy and common sense indicate that it should think of itself as the divergent branch rather than the main line. Obchodzenie się z rozwidleniami If someone threatens a fork in your project, keep calm and remember your long-term goals. The mere existence of a fork isn't what hurts a project; rather, it's the loss of developers and users. Your real aim, therefore, is not to squelch the fork, but to minimize these harmful effects. You may be mad, you may feel that the fork was unjust and uncalled for, but expressing that publicly can only alienate undecided developers. Instead, don't force people to make exclusive choices, and be as cooperative as is practicable with the fork. To start with, don't remove someone's commit access in your project just because he decided to work on the fork. Work on the fork doesn't mean that person has suddenly lost his competence to work on the original project; committers before should remain committers afterward. Beyond that, you should express your desire to remain as compatible as possible with the fork, and say that you hope developers will port changes between the two whenever appropriate. If you have administrative access to the project's servers, publicly offer the forkers infrastructure help at startup time. For example, offer them a complete, deep-history copy of the version control repository, if there's no other way for them to get it, so that they don't have to start off without historical data (this may not be necessary depending on the version control system). Ask them if there's anything else they need, and provide it if you can. Bend over backward to show that you are not standing in the way, and that you want the fork to succeed or fail on its own merits and nothing else. The reason to do all this—and do it publicly—is not to actually help the fork, but to persuade developers that your side is a safe bet, by appearing as non-vindictive as possible. In war it sometimes makes sense (strategic sense, if not human sense) to force people to choose sides, but in free software it almost never does. In fact, after a fork some developers often openly work on both projects, and do their best to keep the two compatible. These developers help keep the lines of communication open after the fork. They allow your project to benefit from interesting new features in the fork (yes, the fork may have things you want), and also increase the chances of a merger down the road. Sometimes a fork becomes so successful that, even though it was regarded even by its own instigators as a fork at the outset, it becomes the version everybody prefers, and eventually supplants the original by popular demand. A famous instance of this was the GCC/EGCS fork. The GNU Compiler Collection (GCC, formerly the GNU C Compiler) is the most popular open source native-code compiler, and also one of the most portable compilers in the world. Due to disagreements between the GCC's official maintainers and Cygnus Software,Now part of RedHat (). one of GCC's most active developer groups, Cygnus created a fork of GCC called EGCS. The fork was deliberately non-adversarial: the EGCS developers did not, at any point, try to portray their version of GCC as a new official version. Instead, they concentrated on making EGCS as good as possible, incorporating patches at a faster rate than the official GCC maintainers. EGCS gained in popularity, and eventually some major operating system distributors decided to package EGCS as their default compiler instead of GCC. At this point, it became clear to the GCC maintainers that holding on to the "GCC" name while everyone switched to the EGCS fork would burden everyone with a needless name change, yet do nothing to prevent the switchover. So GCC adopted the EGCS codebase, and there is once again a single GCC, but greatly improved because of the fork. This example shows why you cannot always regard a fork as an unadulteratedly bad thing. A fork may be painful and unwelcome at the time, but you cannot necessarily know whether it will succeed. Therefore, you and the rest of the project should keep an eye on it, and be prepared not only to absorb features and code where possible, but in the most extreme case to even join the fork if it gains the bulk of the project's mindshare. Of course, you will often be able to predict a fork's likelihood of success by seeing who joins it. If the fork is started by the project's biggest complainer and joined by a handful of disgruntled developers who weren't behaving constructively anyway, they've essentially solved a problem for you by forking, and you probably don't need to worry about the fork taking momentum away from the original project. But if you see influential and respected developers supporting the fork, you should ask yourself why. Perhaps the project was being overly restrictive, and the best solution is to adopt into the mainline project some or all of the actions contemplated by the fork—in essence, to avoid the fork by becoming it. Inicjowanie rozwidlenia All the advice here assumes that you are forking as a last resort. Exhaust all other possibilities before starting a fork. Forking almost always means losing developers, with only an uncertain promise of gaining new ones later. It also means starting out with competition for users' attention: everyone who's about to download the software has to ask themselves: "Hmm, do I want that one or the other one?" Whichever one you are, the situation is messy, because a question has been introduced that wasn't there before. Some people maintain that forks are healthy for the software ecosystem as a whole, by a standard natural selection argument: the fittest will survive, which means that, in the end, everyone gets better software. This may be true from the ecosystem's point of view, but it's not true from the point of view of any individual project. Most forks do not succeed, and most projects are not happy to be forked. A corollary is that you should not use the threat of a fork as an extremist debating technique—"Do things my way or I'll fork the project!"—because everyone is aware that a fork that fails to attract developers away from the original project is unlikely to survive long. All observers—not just developers, but users and operating system packagers too—will make their own judgement about which side to choose. You should therefore appear extremely reluctant to fork, so that if you finally do it, you can credibly claim it was the only route left. Do not neglect to take all factors into account in evaluating the potential success of your fork. For example, if many of the developers on a project have the same employer, then even if they are disgruntled and privately in favor of a fork, they are unlikely to say so out loud if they know that their employer is against it. Many free software programmers like to think that having a free license on the code means no one company can dominate development. It is true that the license is, in an ultimate sense, a guarantor of freedom—if others want badly enough to fork the project, and have the resources to do so, they can. But in practice, some projects' development teams are mostly funded by one entity, and there is no point pretending that that entity's support doesn't matter. If it is opposed to the fork, its developers are unlikely to take part, even if they secretly want to. If you still conclude that you must fork, line up support privately first, then announce the fork in a non-hostile tone. Even if you are angry at, or disappointed with, the current maintainers, don't say that in the message. Just dispassionately state what led you to the decision to fork, and that you mean no ill will toward the project from which you're forking. Assuming that you do consider it a fork (as opposed to an emergency preservation of the original project), emphasize that you're forking the code and not the name, and choose a name that does not conflict with the project's name. You can use a name that contains or refers to the original name, as long as it does not open the door to identity confusion. Of course it's fine to explain prominently on the fork's home page that it descends from the original program, and even that it hopes to supplant it. Just don't make users' lives harder by forcing them to untangle an identity dispute. Finally, you can get things started on the right foot by automatically granting all committers of the original project commit access to the fork, including even those who openly disagreed with the need for a fork. Even if they never use the access, your message is clear: there are disagreements here, but no enemies, and you welcome code contributions from any competent source.