Tym razem to zaległe programy Charlesa Plessy'ego oraz Stefano Zachirolliego. Programy Margarity Manteroli oraz Woutera Verhelsta znaleźć można we wcześniejszej wiadomości.

Charles Plessy

Więcej przyjemności, więcej zaufania

Prezentacja

Jestem biologiem molekularnym i od 2005 r. w wolnym czasie pracuję nad Debianem. Większość czasu jaki poświęcam Debianowi spędzam nad projektem Debian Med, w którym pakietuję oprogramowanie związane z bioinformatyką. Istotą Debiana jest wolność, a osobiście uważam, że w erze coraz bardziej zwiększającej się roli technologii w medycynie, niezwykle istotne jest, aby każdy miał wolny i nieskrępowany dostęp do narzędzi, które pozwalają na zarządzanie oraz zrozumienie informacji na temat stanu zdrowia.

Opiekuję się wieloma pakietami, co sprawiło, że zaproponowałem oraz uczestniczyłem w wielu próbach ustandaryzowania oraz zracjonalizowania pewnych elementów cyklu życia pakietów. Tworzenie wolnego systemu wymaga od nas starannego sprawdzania dystrybuowanych programów, aby ułatwić to zadanie wypracowaliśmy format informacji na temat praw autorskich oraz podsumowania licencji „czytelnego dla maszyn”. Uczestniczyłem w procesie burzy mózgów na wiki Debiana oraz wniosłem spory wkład w uproszczenie tej propozycji obecnie znanej jako 'DEP-5'. Eksperymentowałem również z systemem weryfikowania dodawanych nowych pakietów. Ostatnio rozpocząłem pracę nad zarządzaniem metadanymi na temat projektów zewnętrznych poza plikiem debian/control w pakietach źródłowych.

Moje odczucia względem Debiana

Co czyni Debiana wyjątkowym

Uważam, że Debian to coś więcej niż tylko system operacyjny, to społeczność poświęcona łączeniu wolnych programów w całość i szczodrym dystrybuowaniu ich w sposób, który wnosi pozytywny wkład w nasze społeczeństwo. Nie jesteśmy jedyną społecznością, która stawia sobie taki cel; uważam, że tym co odróżnia nas od nich jest fakt, że nasz projekt utrzymuje się z głównie z darowizn. Współpracownicy ofiarowują swój czas, sponsorzy ofiarowują sprzęt, zasoby oraz zatrudniają niektórych naszych deweloperów aby mogli pracować nad Debianem, użytkownicy zaś — opinie. To zapewnia naszemu projektowi bezprecedensową wolność działania, co w połączeniu z naszymi wzniosłymi celami wolności oprogramowania oraz technicznej doskonałości czyni Debiana wyjątkowym.

Debian przechodzi kryzys rozwoju

Debian nieustannie się rozwija, zarówno jeśli chodzi o liczbę pakietów, obsługiwanych platform, współpracowników, i — jak w większości innych rosnących projektów, tak komercyjnych jak i nie — musimy uważać, żeby nie stać się ofiarą własnego sukcesu. Uważam, że część naszych problemów oraz waśni w naszym środowisku to objawy kryzysu dojrzałości: trudności z akceptacją nowych członków, kłopotliwe wydania oraz względna izolacja (mierzona trudnością w adaptowaniu standardów innych oraz adaptowaniu przez innych rozwiązań wypracowanych przez nas).

Słowa kluczowe rozwiązania tych problemów to wg mnie przyjemność, zaufanie oraz koordynacja. Ponieważ wszyscy jesteśmy ochotnikami, przyjemność jest bardzo ważna w celu utrzymania motywacji. Ponadto ważne dla nas jest docenianie własnego wkładu w społeczeństwo: o ile to nie to samo co udział w czymś, co mieliśmy przyjemność stworzyć, w połączeniu z presją wykonania zadania na czas. Zaufanie oraz koordynacja są kluczowe w utrzymaniu przyjemności każdego. Potrzebujemy więcej zaufania, weryfikowania oraz odporności na błędy, w połączeniu z kontrolą, zatwierdzaniem oraz kolejkowaniem. W zamian powinniśmy raportować o naszych postępach i sprawdzać czy są one spójne z innymi. Nazbyt często zdarza się w Debianie, że ludzie poddają się i zaczynają wzajemnie ignorować.

Program

Moimi głównymi priorytetami jako Lidera Projektu będzie pomoc Debianowi w przezwyciężeniu kryzysu rozwoju.

Członkostwo

Otrzymywanie statusu członka przynosi motywację, odpowiedzialność oraz nagrodę. Obecnie kandydat musi wiele udowodnić aby zostać Deweloperem Debiana, wg mnie poziom jakiego wymagamy od nowych członków to niemal umiejętności potrzebne do sprawowania kontroli nad całą dystrybucją oraz udziału w procesie wydawniczym. Ponieważ to właśnie siły roboczej nam tak bardzo brakuje, nie uważam aby w naszym interesie leżało bycie tak restrykcyjnym w kwestii członkostwa. Bardzo podobała mi się wcześniejsza praktyka, kiedy każdy Deweloper Debiana mógł mianować nowego członka projektu. To przypomina działanie — dobrze się sprawującego — statusu Opiekun Debiana. Co ważne, ułatwienie dołączenia do projektu, ułatwia również opuszczenie go na jakiś czas. Przy bardziej odstraszającym systemie emerytalnym, możemy zmotywować deweloperów, którzy cierpią na brak czasu, do wzięcia oficjalnej przerwy zamiast zwykłego wstrzymania aktywności przez długi czas. A jeśli utraceni członkowie będą mogli zostać łatwiej odzyskani, uważam, że możemy również złagodzić warunki anulowania nieaktywnych członkostw. Przywrócę dyskusję na temat członkostwa, która zostanie zakończona głosowaniem.

Mniej ograniczone operacje

Uważam, że członkostwo nie jest jedyną sferą, w której każdy deweloper powinien móc działać, pod kontrolą oraz z możliwym prawem weta innych deweloperów, wydelegowanych do rozstrzygania ewentualnych różnic zdań. Deweloperzy powinni posiadać nasze zaufanie w kwestii prac wykonywanych przy ich pakietach, dla przykładu powinni móc zmieniać ich sekcję i priorytet, kontrolować proces migracji do gałęzi testowej, ustalać dla jakich architektur zostaną zbudowane, itd. Wiele z tych działań kontrolowanych jest poprzez pliki tekstowe, do których dostęp jest ograniczony. Proponuję nadania prawa do zapisu do nich wszystkim deweloperom, z systemem opóźniającym aplikowanie zmian oraz powiadamiającym o nich, który pozwoli na wychwytywania błędów.

Wydawane architektury z wsparciem spójnego zbioru pakietów

Jeśli wprowadzimy kilka zmian w naszym systemie pakietowania oraz organizacji architektur, możemy wprowadzić wiele elastyczności do naszego procesu wydawniczego. Proponuję, żeby nie wydawać wszystkich pakietów dla wszystkich architektur. Pozwoli nam to wydawać nowe architektury wcześniej, zazwyczaj kiedy staną się one podstawowym systemem à la Unix, również ograniczać wsparcie podupadających architektur krok po kroku. Może z takim systemem nadal byśmy mieli architekturę m68k? Przyniesie to więcej korzyści na początku, więcej przyjemności oraz mniej powodów do stresu dla ludzi zainteresowanych architekturami spoza głównego nurtu, a także presji związanej z wydaniem wśród ludzi zajmujących się oprogramowaniem, które nie jest wspierane przez autorów na tych architekturach.

Elastyczny model wydawniczy: mieszanie stabilnej podstawy z backportami i migawkami

Niebudowanie pakietów dla wszystkich architektur otwiera oczywiście kwestię kryteriów wydania. Uważam, że możliwe jest przerobienie systemu sekcji i priorytetów, tak aby architektury mogły zostać wydawane z częściowym wsparciem naszego archiwum. Nasza obecna strategia wydawnicza, jak wynika z mojego doświadczenia jako opiekuna oraz użytkownika, raczej nie satysfakcjonuje naszych użytkowników, jeśli chodzi o niektóre pakiety: nie oczekują wsparcia bezpieczeństwa dla nich, ani najnowszej wersji czy jakieś konkretnej, która nie jest ani w gałęzi stabilnej, ani niestabilnej. Wraz z nadejściem oficjalnych backportów oraz migawek, uważam, że nasza strategia wydawnicza może wyewoluować ku skoncentrowaniu się na podstawowych pakietów.

Co będę robił jako Lider Projektu Debian

Wg mnie rolą Lidera Projektu jest pomaganie projektowi w rozwoju, poprzez przezwyciężanie zastojów oraz rozwiązywanie konfliktów. Nasza konstytucja nakłada na niego wiele zadań, właśnie za ich pomocą chcę przedstawić najważniejsze punkty mojego programu:

• Delegaci: skontaktuję się z aktualnymi delegatami i zapytam się ich, czy zaangażują się w tym roku, czy wolą zostać wymienieni lub potrzebują pomocy. Porozmawiam z nimi na temat bardziej szczegółowego opisu ich roli i odnowię delegacje lub poszukam nowych delegatów. Opublikują wszystkie nowe delegacje na dedykowanej do tego stronie na naszej witrynie.

• Dyskusje: istnieje wiele przyczyn czemu cześć ważnych dyskusji na naszych listach nie kończy się żadnym wnioskiem. Dyskusje należy przerywać aby ochłonąć, przemyśleć sprawę lub po prostu zakończyć inne zadania. Po takich przerwach, będę wznawiał dyskusję na tematy, które odpowiadają kluczowym punktom wymienionym w moim programie lub spotkały się z konstruktywnym zainteresowaniem, i doprowadzał je do końca.

• Głosowania: Czasami brak wniosków oraz podejmowanych akcji nie wynika z konfliktu czy podziału, po prostu w dużum projekcie jakim jest Debian, który jest zależny od komunikacji elektronicznej, może być ciężko odczuć aprobatę. Uważam, że w takich przypadkach głosowanie może być właściwą procedurą, będę inicjował głosowanie, jeśli Projekt utknie podczas wyboru kierunku spośród kilku akceptowalnych.

• Pieniądze: nasze wydatki skupię na rzeczach, które ciężko uzyskać w ramach datku, szczególnie dostawy sprzętu oraz transport ludzi. Nie będę opłacał rozwoju oprogramowania. Będę co dwa miesiące zdawał sprawozdanie z tego jakie wydatki zatwierdziłem.

Ponadto będę zdawał sprawozdania o moich innych aktywnościach co miesiąc.

Czego nie będę robił jako Lider Projektu

• Podróże: posiadam pełnoetatową pracę i mieszkam daleko od Europy oraz Ameryki [w Japonii — przyp. red.]. Nie będę miał dość wolnego czasu aby brać udział w spotkaniach na innych kontynentach.

• Wtrącanie się: zgodnie z konstytucją, nie będę forsował własnego zdania czy wtrącał się w kwestię przyjmowania nowych członków (ani Opiekunów Debiana).

• IRC: czuję się niezręcznie na IRC-u, ponadto mieszkam w strefie czasowej, w której jest pora na sen, kiedy inni członkowie projektu są aktywni, tak więc nie będę regularnie osiągalny na IRC-u. Oczywiście mogę się połączyć, jeśli będzie trzeba omówić jakąś sprawę.

Więcej przyjemności, więcej zaufania

Nasze zadania powinniśmy wykonywać z wiarą w nie, a nie dlatego, że jakieś ustawienia komputera wymuszają na nas pewien kierunek. W ciągu rocznej kadencji Lidera Projektu, razem z nominowanymi delegatami, chcę — poprzez przewodzenie dyskusjom i, jeśli okaże się to konieczne, rozstrzyganie ich za pomocą głosowań — pomóc Debianowi w otwarciu się na nowych współpracowników, umożliwić deweloperom operowanie naszymi zasobami bezpośrednio, a nie poprzez zgłoszenia, a tym samym ponownie zrównoważyć udział obowiązkach i przyjemnościach w obciążeniu pracą.

---

Stefano Zacchiroli

Skrót

Cześć, jestem Stefano Zacchiroli — szerzej znany jako Zack — i kanyduję na Lidera Projektu Debian.

Główne punkty mojego programu:

• Zamierzam być liderem **zaangażowanym***, zarówno w dyskusjach, jak i jako osoba odpowiedzialna za organizację projektu.*
• Będę regularnie, **co miesiąc***, przedstawiał wieści na temat mojej aktywności jako Lidera Projektu Debian na liście debian-devel-announce.*
• Wprowadzę mechanizm pozwalający osiągnąć konsensus jeśli tenże istnieje.
• Będę naciskał o więcej stopniowych oraz dla zasłużonych ścieżek dostępu do Debiana.
• Będę zwalczał silne uwłasnowolnienie pakietów **jeśli konfliktuje to z jakością***.*
• Zrobię co w mojej mocy aby wspierać, finansowo i innymi środkami, spotkania współpracowników.

W dalszej części tego programu znaleźć można informacje o mnie (sekcja 1), szczegółowy opis powyższych punktów (sekcja 2) oraz moich planów na czas kadencji (sekcja 2.3).

1 Wstęp

1.1 Kim jestem

Deweloperem Debiana zostałem w marcu 2001 r., niedługo po tym jak wprowadzono status nowego opiekuna (New Maintainer, NM). Można wyróżnić dwa etapy mojego zaangażowania w Debiana. Początkowo troszczyłem się tylko o moje pakiety, ignorując społeczność: żadnego IRC-a, żadnych dyskusji na lista deweloperskich, itd. Aż w końcu, podczas konferencji LinuxTag 2004 odkryłem Debiana jako społeczność, która mnie zafascynowała — stopniowo zacząłem zwiększać stopień mojego zaangażowania w projekt. Moje najbardziej warte odnotowania sfery działalności przez te wszystkie lata to:

• PTS:

  Byłem współtwórcą systemu śledzenia pakietów (Package Tracking System, PTS) przez ostatnie 4-5 lat, zajmowałem się zarówno codzienną opieką, jak i bardziej znaczącymi zmianami — szczegóły można znaleźć na moim blogu. (PTS-em zainteresowałem się ponieważ chciałem spopularyzować pola Vcs-*, co ostatecznie doprowadziło mnie do napisania debcheckouta.)

• QA:

  Jeszcze bardziej ogólnie, od dawna jestem członkiem zespołu Quality Assurance: lubię myśleć o projekcie jako o całości i szukać nowych rozwiązań (np. UDD, wygasanie statusu DD, itd.) uporczywych problemów.

• OCaml:

  Odpowiednia obsługa języka OCaml zmotywowała mnie do dołączenia do projektu. Zawiązałem zespół ds. OCaml, w którym przeszedłem pełen wachlarz działalności — od nowicjusza, po lidera. Zespół obecnie opiekuje się około 150 pakietami źródłowymi o szalenie skomplikowanych wzajemnych zależnościach oraz złożonych wymaganiach migracyjnych.

• RCBW:

  Począwszy od września 2009 r., naprawiam jeden błąd krytyczny dla wydania dziennie, rozpoczynając inicjatywę Błędy krytyczne dla wydania tygodnia (Release Critical Bugs of the Week, RCBW). Szczegóły oraz moje motywacje można znaleźć na stronie RCBW.

• AM:

  Dołączyłem do Komitetu ds. Nowych Opiekunów w 2009 r., zostając Zarządcą zgłoszeń (Application Manager, AM). Przeprowadziłem przez proces 4 nowych opiekunów, 2 z nich zostało już Deweloperami Debiana.

• Pakiety:

  Ponadto opiekuję się kilkoma pakietami. Poza pakietami związanymi z OCaml, jestem dumny z wkładu w pakiety devscripts, vim, python-debian oraz turbogears2.

Wierząc, że społeczność jest prawdziwą siłą Debiana, regularnie uczestniczę w DebConfach oraz, jeśli czas pozwala, innych spotkaniach, takich jak wspólne rozwiązywanie błędów czy sesje w Extremadurze.

W „realu” prowadzę badania naukowe, obecnie pracuję jako podoktorant w laboratorium PPS na Uniwersytecie Paris Diderot. Laboratorium jest istnym siedliskiem Deweloperów Debiana, w którym przerwy na kawę regularnie przeradzają się w fascynujące dyskusje na temat Debiana. Głównie pracuję nad projektem Mancoosi, w którym badamy rozpowszechnianie WiOO za pomocą metod naukowych; projekt regularnie współtworzy narzędzie dla społeczności, takie jak edos-debcheck, edos.debian.net i inne usługi QA używane każdego dnia przez Debiana i inne dystrybucje.

1.2 Dlaczego kandyduję na Lidera Projektu

Są dwa różne aspekty pełnienia funkcji Lidera Projektu Debian: rola instytucjonalną oraz, jeśli lider jest ambitny, realizowanie dodatkowych celów w trakcie kadencji. To ważne rozróżnianie. Rola instytucjonalna jest opisana w naszej konstytucji, a składają się na nią trzy zadania: podejmowanie zwykłych oraz nadzwyczajnych decyzji, zadania PR-owskie oraz przewodzenie dyskusjom wewnątrz projektu.

Moja perspektywa na fakt konieczności posiadania Lidera Projektu opiera się na obserwacji naszej metody działania: ktokolwiek chce coś zrobić sam decyduje co i jak wykonuje zadanie, nikt nikogo nie może zmusić do wykonania czegokolwiek. Biorąc pod uwagę rozmiar projektu, mamy tendencję do niedoskonałości.

1. ograniczanie dostępu osobom celem zahamowania ich rzekomo niebezpiecznych działań
2. nieciekawe zadania pozostają nietknięte, ponieważ nikt nie ma dość motywacji aby się nimi zająć
3. osoby zajmujące już jakieś pozycje mogą zaniedbywać swoje zadania oraz obniżać poziom swoich usług, ponieważ nie potrafią przyznać, że nie są już w stanie pełnić swoich funkcji

Lider Projektu Debian ma obowiązek, w ramach ograniczonego czasu, łagodzić nasze niedoskonałości:

1. zauważać nazbyt przyhamowujące ograniczenia dostępu, które powstrzymują od pracy odpowiednich ludzi, wywołując niewydajność oraz frustrację
2. znajdować ludzi gotowych do wykonywania nieciekawe zadania dla dobra całego projektu (w zamian za odpowiednie uznanie)
3. nadawać i zmieniać przydziały na kluczowe pozycje, aby udoskonalać jakość usług wewnątrz i na zewnątrz Projektu

Nagrodą jest możliwość stymulowania postępu całego projektu zajmując tylko pozycję Lidera Projektu Debian.

Stawiam sobie za cel być transparentnym i zaangażowanym liderem, oraz ulepszyć mechanizmy używane wewnątrz naszego projektu. Oto dlaczego kandyduję na Lidera Projektu Debian.

2 Moje cele

Zadania instytucjonalne Lidera Projektu Debian polegają na podejmowaniu decyzji w sytuacjach, które są — ogólnie rzecz ujmując — nieznane a priori. Dlatego przedstawiam moje cele:

1. Po pierwsze podaję moją wizję względem kluczowych tematów „polityki” Debiana. To, jak uważam, jest jedyny sposób aby zarysować moje możliwe reakcje na nieprzewidywalne scenariusze.
2. Następnie prezentuję moje podejście, które zamierzam stosować podczas pełnienia instytucjonalnych zadań Lidera Projektu.
3. Na końcu przedstawiam listę pewnych specyficznych projektów, które zamierzam zrealizować jeśli zostanę wybrany liderem.

2.1 Wizja

Współpracownicy, którzy nie są Deweloperami Debiana

Wprowadzenie statusu Opiekuna Debiana (Debian Maintainer, DM) było pomyślne dla Debiana. Część ludzi argumentowało, że otworzyło to nasze archiwum na pakiety o niższym standardzie. Może i prawda, jednak poza tym mieliśmy już (sporo) pakietów o niższym standardzie, którymi zajmowali się pełnoprawni opiekunowie, którzy stracili zainteresowanie Debianem. Rozwiązaniem obu kwestii jest więcej QA.

Dzięki temu statusowi, wiele entuzjastów mogło rozpocząć pracę nad Debianem, zwiększając nasze siły przerobowe. Na dodatek zainicjował on bardziej kontrolowany proces zostawania pełnoprawnym Deweloperem Debiana, zwiększając prawdopodobieństwo autentycznego oddania Debianowi oraz poziom doświadczenia. Koniec końców, status Opiekuna Debiana jest bardziej rozdrobnioną ścieżką dostępu do Debiana, niż wcześniejsze, co pozwala nam stopniowo oddawać uznanie współpracownikom.

Musimy wyciągnąć wnioski wyciągnięte ze statusu DM. Mamy wielu potencjalnych wartościowych współpracowników. Potrzebują oni tylko lepszej dokumentacji na temat tego jak dołączyć do Debiana. Jedynie oczekują tylko czegoś w zamian, z czego mogliby być dumni, docenienia ich wysiłków. Nie mam uprzedzeń względem innych sposobów pozwalających to osiągnąć (np. lista kontroli dostępu a zwiększanie przywilejów liniowo), jednak musimy iść właśnie w tym kierunku. Przy okazji powinniśmy również rozluźnić nasze założenia, że w Debianie ważne są tylko umiejętności techniczne. „Najlepszy system operacyjny” to głównie, a nie tylko, oprogramowanie — składają się na niego również tłumaczenia, grafiki, muzyka, itd.

Będę naciskał o więcej stopniowych oraz dla zasłużonych (rewarding) ścieżek dostępu do Debiana.

Wspólna praca

Wprowadzenie pola Uploaders: to kolejny przykład rozwoju Debiana w słusznym kierunku. Wprawdzie pozwoliło to również tworzyć zespoły, w których brak odpowiedzialności za konkretne zadania, jednak zazwyczaj sprawdza się świetnie. Utworzyło wydajne, techniczne pole do współpracy nad pewnymi kwestiami, a także (ponownego) tworzenia struktur organizacyjnych o określonych rolach i przydziałach.

Wspólna praca nie powinna być obowiązkowa (mamy kilku bardzo wydajnych deweloperów działających w pojedynkę), jednakże takie podejście powinno być traktowane jako domyślne. Pakietujący nowicjusze powinni rozpoczynać pracę w zespołach i w nich nabierać doświadczenia. Opinia innego członka zespołu jest przydatna, pozwala na zdjęcie nieco ciężaru z ramion nowego opiekuna. Nie powinniśmy również dopuszczać do działania w pojedynkę, jeśli pociąga to za sobą de facto porzucony pakiet. W takich przypadkach powinniśmy sugerować — a nawet wymuszać, jeśli zachodzi taka potrzeba — pracę zespołową. To może być lepsza strategia niż publiczne, jednak nic nie przynoszące, zawstydzanie.

Będę zwalczał silne uwłasnowolnienie pakietów **jeśli konfliktuje to z jakością***.*

Głośne mniejszości

Nasze listy dyskusyjne uległy znacznej poprawie w ostatnich latach. Jednak od czasu do czasu zostają zanieczyszczone przez (widocznie) bardzo głośne mniejszości, zdolne do spolaryzowania dyskusji, co nie jest ani produktywne, ani zabawne. Biorąc pod uwagę jak jesteśmy przywiązani do naszej społeczności, czasami bierzemy udział w takich właśnie dyskusjach, nieuchronnie się wypalając (zbyt często deweloperzy biorą z tego powodu urlopy). Moje podejście

Wolność wypowiedzi: dobra. Głośne mniejszości trzymające w szachu milczące większości: źle.

O ile powinniśmy rozważać — a wprowadzić powinniśmy już dawno — metody moderatorskie by odpierać powtarzające się zachowania paraliżujące społeczność, nie możemy zaryzykować wprowadzenia ich tylko na założeniu, iż nadawca wiadomości rzeczywiście należy do głośnej mniejszości. Jakkolwiek nie ma optymalnego rozwiązania tego rodzaju problemów, instrumenty techniczne mogą pomóc. Chcę użyć jednego z nich — ankiet, jak proponowali inni w ubiegłych latach. Założenie jest takie, że każdy Deweloper Debiana będzie mógł rozpocząć e-mailową ankietę, à la devotee (system używany podczas głosowania w Debianie — przyp. red.).

Ankiety mogą ujawnić prawdziwe stanowisko społeczności, bez uruchamiania całej maszynerii głosowania. Wyniki ankiety mogą uświadomić uczestnikom dyskusji (lub kłótni), że wcale nie zgadzają się resztą członków projektu i lepiej, żeby dali sobie spokój, lub wskazać, że znajdują się na właściwej ścieżce.

Wprowadzę mechanizm pozwalający osiągnąć konsensus jeśli tenże istnieje.

Spotkania twarzą w twarz

Spotkania są kluczowe w doskonaleniu jakości współpracy wewnątrz projektu, choćbyśmy nie wiem jak dobrze radzili sobie komunikując się drogą elektroniczną. Wystarczy spotkać się twarzą w twarz, pohakować kilka godzin, porobić parę rzeczy wspólnie i wrócić do domu. Następnego dnia współpraca zdalna będzie lepsza.

Pomoc w organizacji spotkań to jedna z najlepszych metod wydawania Debianowych pieniędzy i innych środków. Na szczęście mamy DebConf, organizowany przez bardzo sprawny zespół. Jednakże DebConf nie powinien być jedyną okazją do spotkań, powinniśmy bardziej zachęcać do organizowania lokalnych spotkań. Widzę jak całkowicie uzasadnione jest finansowe wsparcie podróży aktywnych współpracowników, po tym jak umożliwia to innym rozpoczęcie prac na pewnymi zagadnieniami.

Prostym wyznacznikiem pozwalającym podjąć decyzję kiedy wesprzeć spotkanie finansowo, a kiedy nie (poza ilością wymaganych pieniędzy), może być liczba x innych deweloperów proszących o to. Dopóki nie będzie problemy z pieniędzmi, nie widzę powodu aby przestać sponsorować organizację spotkań.

Zrobię co w mojej mocy aby wspierać, finansowo i innymi środkami, spotkania współpracowników.

Pochodne

Jesteśmy częścią ekosystemu WiOO, w którym łatki przepływają między dystrybutorami oprogramowania a jego autorami (downstream and upstream) w obu kierunkach. Obiecaliśmy odwdzięczać się społeczności Wolnego Oprogramowania, jednak czasami nam się to nie udaje. Inicjatywy takie jak system śledzenia łat mają na celu upewnić się, że wszystkie nasze zmiany są widoczne zarówno dla dystrybutorów jak i autorów.

Sami jesteśmy autorami dla pochodnych Debiana. Nie możemy zmusić ich do odwdzięczenia się nam, ponieważ nasze obietnice niekoniecznie są ich, jednak mimo to powinniśmy:

1. świecić przykładem jako projekt, który się odwdzięcza, dla przykładu poprzez upublicznianie naszych prób wysyłania łat autorom
2. ułatwić jak tylko to możliwe odwdzięczanie się nam, dla przykładu uczestniczyć w międzydystrybucyjnych inicjatywach, aktualizowanie pakietów w trybie NMU jeśli ważne łaty są zostawione same sobie w systemie śledzenia błędów

Obydwie czynności wzmocnią naszą prośbę o odwdzięczanie się kierowaną do pochodnych, której nie powinniśmy przestać wysyłać.

Szczególnie nie powinniśmy ignorować faktu, że Ubuntu jest najpopularniejsze wśród naszych pochodnych i zdaje się, że posiada społeczność większą niż nasza. (i) Technicznie, powinniśmy wykorzystywać ów fakt, by osiągać korzyści dla naszych użytkowników, poprzez integrowanie dobrych zmian i odrzucanie reszty. W tym celu przydałby się techniczny mechanizm, który pozwalałby Deweloperom Debiana lepiej współdziałać ze społecznością Ubuntu (błędy, łaty, ...). (ii) Politycznie, mamy ten atut, że wydania Ubuntu (wliczając universe) to w 70% niezmodyfikowane pakiety Debiana. Powinien on zostać użyty do bardziej wyraźnego zakomunikowania naszego oczekiwania, że Ubuntu zachowa się jak na dystrybutora WiOO przystało: odda zasługi i odwdzięczy się. (iii) Wreszcie, powinniśmy zakomunikować dlaczego jesteśmy lepsi (patrz: sekcja 2.3.1) i nie zapominać że jesteśmy lepsi.

2.2 Interakcja z Projektem

2.2.1 Bycie zaangażowanym

Często zauważałem „nieobecność” Lidera Projektu. Może to moja wina, nie odezwałem się jako pierwszy do lidera za pośrednictwem IRC-a lub e-maila, jednak uważam, że to obowiązkiem Lidera Projektu jest zakomunikować swoją obecność. Może to przybrać dwie formy: jedną z nich jest przewodzenie dyskusjom, co opisano w konstytucji, coś z czym rzadko się spotykałem. O ile nie chcemy żeby stało się to regułą (niepotrzebny jest lider piszący w każdym wątku), postaram się być obecnym w „gorących” dyskusjach (celowo nie precyzuję) dotyczących organizacji i Projektu w szerszej perspektywie. Będę też zachęcał do zasięgania opinii lidera na konkretne tematy, przez zaczepianie mnie bezpośrednio.

Zasięgnięcie opinii Lidera Projektu może również być pierwszą próbą rozwiązania konfliktu. Jeśli zakończy się fiaskiem, posiadamy inne mechanizmy rozstrzygnięcia go. Uważam, że moje osobiste cechy mogą być przydatne dla Projektu: jestem życzliwy, potrafię słuchać innych, można mnie przekonać dobrą argumentacją.

Drugim przejawem zaangażowania, który powinien być wymagany od lidera, jest organizacja projektu, a także komunikowanie naszej wizji. Organizowanie projektu oznacza posiadania planu działania, listy tematów które Projekt powinien rozważyć w swoim czasie. Strona DiscussionsAfterLenny — oraz to jak z niej (nie) skorzystaliśmy — może być przykładem tej potrzeby. Lider Projektu powinien się upewnić, że Projekt posiada spójny plan, aby uniknąć sytuacji, w której o czymś istotnym by zapomniano, aby przypomnieć sobie, powiedzmy, tuż przed wydaniem.

To oznacza także bycie na bieżąco z tym co się dzieje. Propozycja DEP-ów, której byłem współautorem, jest próbą osiągnięcia tego: bez wywołania dodatkowego obciążenia, za to informacjami pozwalającymi na zapamiętanie obecnego statusu „dużych” propozycji wpływających na projekt. Lider Projektu powinien zaopiekować się „osieroconymi” DEP-ami poprzez zmianę przydziału, zamykanie lub doprowadzanie ich do pierwszego „właściciela”. Dopilnuję, żebyśmy wypróbowali podobne instrumenty, żebyśmy mieli rozsądny wybór pomiędzy bardzo formalnymi głosowaniami a tradycyjnie podejmowanymi decyzjami, które często sprowadzają się do braku decyzji w ogóle.

Zamierzam być liderem **zaangażowanym***, zarówno w dyskusjach, jak i jako osoba odpowiedzialna za organizację projektu.*

2.2.2 Transparentność

Innym przejawem aktywności Lidera Projektu jest okresowe ujawnianie informacji na temat swojej działalności, nazwijmy to „transparentnością”. W tym przypadku, standardowe krótkie wiadomości (bits) od lidera, to za mało jak na stanowisko, które reprezentuje tak duży i odmienny projekt. W razie czego będę wolał zarzucić pewne zadania i powiadomić o innych, jeśli nie da się zrobić tego inaczej.

Prawdopodobnie część działalności Lidera Projektu nie nadaje się do ujawnienia — albo niektórych tyczy osobiście, albo jest strasznie nudna, albo z innych powodów nie powinna zostać opublikowana w Sieci. Mam też świadomość, że pisanie od zera wiadomości od Lidera może być czasochłonne.

Rozwiązaniem, które zamierzam wprowadzić, jest stały kanał informacji o działalności Lidera. „Kanał” to ogólne pojęcie, jego realizacja może być różna: kanał IRC, blog lub mikroblog, strona BitsFromTheDPL na wiki zorganizowana à la DeveloperNews, itd. Brak informacji na temat działalności oznacza brak aktywności Lidera oraz prawo do narzekania przez innych Deweloperów oraz domagania się wyjaśnień. Jestem pewien, że te sfery działalności, które jeszcze nie są gotowe do upublicznienie, nawet nie z powodu konieczności ocenzurowania czy przeredagowania, będą na tyle rzadki, że nie spowodują opróżnienia kanału. Kanał będzie co miesiąc „zamrażany” i publikowany na liście debian-devel-announce. Jeśli dwukrotnie nie podołam temu zadaniu, przyznam swoją porażkę i podam jej powody, a także zapytam o opinie na temat jak kontynuować kadencję.

Będę regularnie, **co miesiąc***, przedstawiał wieści na temat mojej aktywności jako Lidera Projektu Debian na liście debian-devel-announce.*

Pieniądze

Uważam, że potrzebujemy usprawnić transparencję również w kwestii zarządzania finansami: zarówno Deweloperzy jak i inni współpracownicy powinni móc sprawdzić jak pieniądze wpływają i wypływają z naszych kont bankowych. Zbadam razem z odpowiednimi skarbnikami możliwość publikowania takich raportów publicznie. Mamy co nieco pieniędzy (ponad 60 tys. USD tylko na kontach SPI), jasny podgląd na to jak je używamy może zachęcić cały Projekt do wydatkowania ich w sposób przynoszący większe profity (np. dedykowane maszyny lub inne zasoby do konkretnych potrzeb związanych z pakietowaniem).

2.2.3 Brak zespołu doradców

Wg byłych liderów, ponoszenie ciężaru stanowiska w pojedynkę może być ciężkie. Aby mu podołać będę stale szukal porady innych. Nie wierzę w użyteczność zespołu doradców Lidera, więc nie powołam go; nie powołam również zastępcy (2IC, second in charge). Tak naprawdę nie znalazłem niczego co potwierdzałoby, że którykolwiek z tych instrumentów znacząco wpływa na jakość kadencji.

Do bardziej konkretnych zadań posiadamy funkcję delegatów, które w pełni wystarczają. Szczególnie chcę zbadać użyteczność okresowych delegatur powoływanych do konkretnych zadań, uznawanych za kluczowe do trzymania się ustalonego planu. Okresowe delegatury — realizowane podobnie jak zwykłe, tylko z wyraźnym oświadczeniem, że zostaną odwołane, np. na koniec kadencji Lidera — pozwolną na uniknięcie koncentracji władzy oraz ustalą delegatom pewne ramy czasowe na wykonanie zadania. Oczekuję, że Deweloperzy Debiana sami zaproponują swoje kandydatury na okresowych delegatów ds. zadań, na których im zależy (jeśli rzeczywiście wymagają one delegowania kogoś).

Nie powołam zespołu doradców Lidera, będę raczej korzystał z delegatur, prawdopodobnie ograniczając ich czas trwania.

2.3 Konkretne plany

2.3.1 Strona WWW

Wszyscy pragniemy bardziej seksownej strony, np. takiej, na której ludzi mogą znaleźć to czego szukają, i która nie sprawia, że Debian jawi się jako system operacyjny z lat 80'. Wprawdzie prace trwają wewnątrz zespołu ds. WWW, jednak nadal brak widocznej poprawy.

Z upływem czasu, wady obecnej strony stoją się coraz bardziej istotne. Przede wszystkim powinniśmy jasno wytłumaczyć naszej (potencjalnej) społeczności czemu jesteśmy lepsi niż inne dystrybucje bazujące na Debianie. Musimy wyjaśnić, że jesteśmy całkowicie wolni (również wszystkie elementy naszej infrastruktury) oraz prawdziwie demokratycznym projektem, w którym decyzje podejmują wolontariusze, nie pieniądze. Innymi słowy, musimy promować naszą wizję w świecie WiOO, a strona WWW powinna być pierwszym medium, który ją przekazuje.

Zamierzam pomóc zespołowi ds. WWW rozwiązać główne problemy w trakcie kadencji. Nie ma sensu precyzować technicznych celów w programie, jednak ogólny kierunek działań będzie jak poniżej. Wszystkie kroki zostaną podjęte w porozumieniu z zespołem ds. WWW.

1. Ustalimy minimalne wymagania ulepszonej strony w kwestii: przekazu, struktury, dostępności, przepływu pracy. Uczynimy te wymagania publicznie dostępnymi, również szczegółowy plan działań koniecznych do wdrożenia ich: nie będziemy ukrywać problemów.
2. Wyślemy prośbę o pomoc do społeczności, poszukamy ludzi, którzy chcieliby zając się zadaniem i ukończyć je w określonym czasie. Moje doświadczenia z odnawianiem strony PTS pokazuje, że jest to możliwe — poprosiłem społeczność o pomoc i otrzymałem kilka propozycji. (Tak, wiem — wszyscy jesteśmy ochotnikami, musimy jednak brać odpowiedzialność i trzymać się terminów, ten problem jest na tyle ważny, żeby o to prosić.)
3. Upewnimy się, że ochotnicy, którzy podejmą się zadania będą mieli dostęp do koniecznych zasobów i otrzymają uznanie za swoje starania i, mam nadzieję, sukces.

Jeśli wszystko zakończy się fiaskiem, wdrożymy w życie plan awaryjny. Dla przykładu, możemy wziąć pod uwagę zewnętrznego wykonawcę, który zrealizuje zadanie pod nadzorem zespołu ds. WWW. Regularnie płacimy za usługi, których sami nie jesteśmy w stanie wykonać, strona WWW nie powinna być wyjątkiem.

2.3.2 Wyklarowanie kwestii delegatów

Pamiętaj: TINC (There is no cabal) [tinc.debian.net? — przyp. red.). Dobrze. A zatem:

1. wszyscy obecni delegaci powinni zostać jasno określeni na naszej stronie organizacyjnej z podaniem adresu e-mail
2. wszyscy członkowie głównych zespołów, którzy już de facto korzystają ze statusu delegatów, powinni zostać oficjalnie delegowani. Pozwoli to na uniknięcie dysproporcji między „młodymi” członkami zespołów, którzy już są delegatami, a „starymi”, którzy tkwią w niejasnym stanie zawieszenia.

2.3.3 Główne zespoły

Nasze główne zespoły uległy ostatnio dużej poprawie, zarówno w kwestii mocy przerobowych jak i komunikacji. Podziękowania należą się ostatnim dwóm Liderom, oraz oczywiści samym zespołom. Jednakże niektóre z nich nadal cierpią na deficyt, a przynajmniej tak to wygląda z zewnątrz. Dodawanie nowych członków sprawia, że zespół jest mniej wrażliwy na nieobecności, ponadto pomaga przygotować kolejne pokolenie współpracowników. Rozróżnienie między asystentami a regularnymi członkami praktykowane w pewnych zespołach wydaje się znakomicie sprawdzać w tek kwestii.

W swej naiwności chcę sprawić, aby wszystkie główne zespoły składały się co najmniej z trzech członków, oraz rozpocząć kampanię o wprowadzenie asystentów, jeśli nie ma jasno ustalonych procedur dołączania do zespołu. Ponadto, rzut oka na stronę organizacyjną pokazuje, że część zespołów jest raczej nieaktywna lub są bardzo kiepscy pod względem komunikowania o swoich działaniach. Członkowie tych zespołów, dla ich własnego dobra, powinni albo rozpocząć prace nad czymś co sprawia im więcej przyjemności, albo informować co jakiś czas o swoich poczynaniach.

Wszystkie te zmiany powinny jednak zostać wprowadzone w życie w porozumieniu z samymi zespołami, aby nie kłopotać mało liczebne, jednak bardzo kompetentne zespoły. Inicjatywa przeglądu zespołów Steve'a McIntyre'a sprzed dwóch lat była krokiem w dobrym kierunku, choć oczywiście wymaga zmian, z racji upływu czasu.

Dodatkowe informacje

Zobowiązanie czasowe

Funkcja Lidera Projektu Debian jest prawdziwym wyzwaniem, zadanie musi być potraktowane poważnie, jeśli ma być wykonane jak należy. Dlatego na czas kadencji odstąpię od moich innych Debianowych zadań: to obowiązek wobec współpracowników oraz zabezpieczenie przed wypaleniem się. Większość moich Debianowych obowiązków realizowana jest wewnątrz kompetentnych zespołów, jestem pewien, że zadania nie zostaną pozostawione same sobie, reszta to garść pakietów, które potrzebować będą nowych opiekunów.

Część kandydatów deklarowało w przeszłości możliwość działania jako lider w pełnym wymiarze godzin. Nie mogę tego zagwarantować. Mogę jednak przeznaczyć na zadania lidera czas, który obecnie poświęcam Debianowi. Dodatkowo, mam bardzo oddanego WiOO szefa: pozwolił mi przeorganizować oraz prawdopodobnie skrócić mój grafik w razie nagłych przypadków lub zadań wymagających więcej czasu, takich jak podróże związane z Debianem. Jak większość z nas, jestem osiągalny przez IRC, telefon, itd.