Od kilku miesięcy skrupulatnie obserwuję dział Critical Issues (D7) i powiem szczerze, że osobiście jestem przygnębiony.
Każdy kto choć odrobinę zajmował się metodologiami Agile czytał o potrzebie małych zwycięstw, które motywowałyby i podnosiły wydajność zespołu. To co dzieje się w critical issues jest dokładnym anty-przykładem.
Jak każdy wie Drupal 7 w wersji beta wyjdzie gdy ilość krytycznych błędów spadnie do zera. Wszystko pięknie jednak śledząc każdego dnia spadki i wzrosty oraz pobieżnie przeglądając statusy poszczególnych zgłoszeń jestem załamany.
Generalnie ilość zgłoszeń utrzymuje się na poziomie trzydziestu kilku. Bywają okresy, po których liczba ta spadała do dwudziestu lub nawet kilkunastu jednak był to raczej efekt mechanizmu, który po 14 dniach braku aktywności uznaje zgłoszenie za rozwiązane aniżeli faktyczne zakończenie rozwiązywania problemu.
Oczywiście mechanizm ten ma sens i zgłoszenia tak zamykane zawierały szereg łatek będących propozycjami rozwiązania problemu. Odnoszę jednak wrażenie, że proces recenzji trwa w nieskończoność i brak jakiegoś BDFL w tym całym zamieszaniu.
Wracając do małych sukcesów. Wiele projektów przyjmuje bardzo prostą i moim zdaniem słuszną zasadę - skupiamy się w danej wersji na zaimplementowaniu kilku - dwóch, trzech rzeczy i koniec. Cel jest niedaleki, do osiągnięcia w niedługim czasie i bardzo dobrze określony. W Drupalu brakuje mi dobrze określonego celu. Metoda SMART byłaby tutaj nieoceniona i znacznie przyspieszyłaby wydanie stabilne. Jednak już sam fakt braku "małych kroków" sprawia iż nie widać końca a utrzymująca się liczba bugów nie cieszy, brak jest małych sukcesów, które podniosłyby morale.
Dobrą drogą dla projektów OpenSource jest stawianie sobie malutkich celów. Dobrze widać to w przypadku Google Chrome. Niemal od samego początku wiadomo jakie nowe funkcje pojawią się w nowej wersji, każda kolejna wersja stabilna cieszy i przynosi kolejne usprawnienia. Wszystko dzięki po mistrzowsku zaprojektowanemu procesowi (Review process, continous integration, tests), używaniu nowoczesnych narzędzi (Buildbot, Review Board, coś na wzór ANT ale dla typowe dla GNOME) i jasno określonym zasadom. Drupal mógłby się tu wiele nauczyć.
Moim zdaniem po wydaniu Drupala 7 społeczność powinna przestawić się na wydania drupala 7.1, 7.2,7.3 z kolejnymi elementami przygotowywanymi przez społeczność. Projekt rozwijałby się na bieżąco, nadążał za obecnie panującymi trendami, był innowacyjny i nowoczesny. Wydanie wielkiego Drupala 8 za kolejne kilka lat pozostawiłoby ponownie siódemkę w tyle i sprawiło, że strony na niej oparte trącą myszką.
Życzę zespołowi Drupala 8 lepszego określania celów, stosowania metody małych sukcesów, małych wydań przynoszących cieszące użytkowników zmiany i rychłego wydania ósemki :)
