Segregacja zgłoszeń

Ta strona jest przeznaczona dla osób pomagających w segregacji zgłoszeń w systemie śledzenia zgłoszeń na Githubie.

Preamble

• Każdy projekt ma ograniczone zasoby, różnica między projektami polega na progu.
• Każdy projekt powinien mieć jasno określone cele. Dla Ansela jest to zarządzanie, edytowanie i eksportowanie kolekcji obrazów RAW na komputerze stacjonarnym przez użytkownika końcowego, który nie korzysta z wiersza poleceń, ale stawia wizualną jakość obrazu ponad wszystko inne.
• Każdy projekt ma narzut, czyli działania wymagane, aby osiągnąć cele, choć same w sobie nie są celem i dlatego powinny pozostać minimalne. Dla Ansela jest to utrzymanie strony internetowej, dokumentacji, serwerów, pakietów budowanych co noc, porządkowanie kodu, debugowanie, testy regresji, wsparcie dla wielu systemów operacyjnych, segregacja zgłoszeń itd.
• Cele i narzut należy wyrażać w kategoriach zadań do wykonania, aby rozwiązać problemy (zgłoszenia). Jeśli nie ma problemu do rozwiązania, to nie ma pracy do wykonania: status quo też jest świetne, nie twórz pracy dla samej pracy.
• z powodu ograniczenia zasobów zadania muszą być uporządkowane według ich priorytetu.

Poniższy dokument ma na celu zdefiniowanie tego priorytetu.

Ansel został odgałęziony od Darktable, ponieważ Darktable nie ma jasnego celu, nie zarządza priorytetami, a narzut rośnie z roku na rok, co jest znakiem rozpoznawczym fabryk wypalenia zawodowego i jest nie do utrzymania w perspektywie średnioterminowej.

Definiowanie dobrych zgłoszeń

Zarządzanie projektem działa lepiej z zadaniami SMART. S.M.A.R.T. oznacza:

• Specific — konkretne (np. znalezienie URI zdjęć wyeksportowanych przez Ansela w systemie plików i otwarcie ich)
• Measurable — mierzalne (np. liczba kliknięć/kroków wymaganych, czas procesora potrzebny na wykonanie zadania na jakiejś docelowej platformie)
• Actionnable/Achievable — wykonalne/osiągalne (np. można zintegrować z obecną bazą kodu przy jedynie drobnych przeróbkach, wymaga tylko kilkuset linii kodu)
• Relevant/Reasonable — istotne/rozsądne (np. jest częścią dość ogólnego procesu fotograficznego, byłoby używane przez znaczącą część użytkowników)
• Time-bound — ograniczone czasowo (np. wymaga co najwyżej 70 roboczogodzin).

Dobre zgłoszenie to takie, które prowadzi do zadania SMART. Dla Ansela oznacza to zgłoszenia skupione na jasno zdefiniowanym problemie dotyczącym jasno zdefiniowanego etapu procesu edycji zdjęcia („Mam problemy z robieniem X z powodu Y i chciałbym Z").

Pytania i ogólne dyskusje powinny odbywać się na https://community.ansel.photos.

Złe zgłoszenia to:

• zbyt szerokie („zautomatyzować proces pracy", „poprawić UX"),
• skupione na środkach („użyć sieci neuronowej", „rozszerzyć krzywą tonalną") zamiast na celu („zamaskować niebo", „selektywnie kontrolować nasycenie"),
• poza zakresem („przeportować na Androida", „przejść na Qt", „przejść na Vulkan")
• dotyczące bibliotek/projektów firm trzecich (Rawspeed, Libraw, Exiv2, Lensfun, GPhoto2, Gtk itd.),
• zbyt subiektywne („proszę zrobić rzeczy tak jak w tym innym oprogramowaniu, którego używałem w przeszłości i naprawdę lubię"). To, co lubi użytkownik A, nie będzie się podobać użytkownikowi B, nie możemy z tym pracować.

Uwaga na marginesie: niektóre zgłoszenia mogą brzmieć jak rzeczy wymagające więcej kodu, podczas gdy w rzeczywistości potrzebują lepszej dokumentacji obecnych funkcji lub drobnych poprawek GUI (zmiana nazw etykiet, reorganizacja widżetów), więc warto o tym pamiętać, zanim rzuci się do broni.

Definiowanie priorytetów

W idealnym świecie zadania (czyli dobre zgłoszenia) byłyby dodawane do listy rzeczy do zrobienia liniowo, w miarę osiągania kolejnych kamieni milowych, a ich produkt kodowy byłby testowany przez kilka tygodni, podczas gdy kod pozostawałby zamrożony, aż do udowodnienia, że wszystko się trzyma, w którym to przypadku odmroziłibyśmy kod i przeszli do następnego zadania na liście rzeczy do zrobienia.

Problem w tym, że oznacza to wszystkich na pokładzie na czas fazy testowania, aby nie zamrażać kodu na zbyt długo. Ponieważ tak się nie dzieje (ludzie biorą urlopy, mają dzieci, przeprowadzają się, zmieniają pracę, mają życie…), musimy zrównoleglić testowanie produktu poprzednich zadań, gdy pracujemy nad następnym, aby być wydajnymi.

To znaczy, że lista rzeczy do zrobienia nie jest liniowa i niektóre ważne rzeczy mogą być dodawane lub usuwane dynamicznie, w zależności od tego, co się dzieje. Problem polega wtedy na określeniu, co stanowi coś na tyle ważnego, by zakłócić harmonogram.

Nie ma tu ostatecznej reguły, więc będziesz musiał kierować się najlepszym osądem, ale istnieje kilka reguł kciuka:

• coś, co zostało niedawno zepsute (regresja), jest łatwiejsze do wykrycia i naprawienia raczej wcześniej niż później, więc w ogólnym rozrachunku może to oznaczać mniej pracy ogółem, jeśli zrobi się to wcześniej,
• coś, co całkowicie uniemożliwia działanie oprogramowania (awaria, uszkodzone pliki wyjściowe, utrata danych), jest wystarczająco krytyczne, aby mieć pierwszeństwo przed ulepszeniami i bardziej kosmetycznymi poprawkami,
• coś, co dotyka dużej liczby użytkowników i dla czego nie można znaleźć obejścia, również będzie miało pierwszeństwo.

Wręcz przeciwnie, wszystko, co dotyka małej liczby użytkowników, lub niszowych/drugorzędnych funkcji, lub drobnych niedogodności, które mają obejścia, nie jest wystarczająco krytyczne, by uzasadnić zakłócenie harmonogramu. Takie rzeczy będą dodawane do kolejki na zasadzie „pierwszy przyszedł, pierwszy obsłużony".

Ansel ma 4 poziomy priorytetów, ustawiane jako etykiety zgłoszeń:

• priority: critical: Wpływa na podstawowe i kluczowe funkcje oprogramowania w sposób, który całkowicie uniemożliwia jego działanie,
• priority: high: Wpływa na podstawowe i kluczowe funkcje oprogramowania w sposób, który poważnie pogarsza użyteczność,
• priority: medium: Wpływa na podstawowe i kluczowe funkcje oprogramowania w sposób, który nieznacznie pogarsza użyteczność (dostępne obejścia),
• priority: low: Wpływa na opcjonalne i niszowe funkcje

Definiowanie kamieni milowych

Parametry modułów są zapisywane jako binarne bloby. Radzimy sobie z nimi, obsługując ich rozmiar bitowy. Gdy dodawany jest nowy parametr, musimy napisać kod obsługujący konwersję, czyli różny rozmiar bitowy blobu parametrów, i zwiększamy wewnętrzną wersję parametrów modułów. Nie pisze się kodu dla zgodności wstecznej, więc zdjęcia edytowane nowszymi modułami nie mogą być otwierane w starszych modułach. Parametry modułów są używane również w stylach, w presetach i w plikach XMP.

Z tych powodów każde zgłoszenie, które prowadziłoby do dodania parametrów w modułach (czy to modułach przetwarzania obrazu w ciemni, czy modułach stołu podświetlanego zajmujących się eksportem i metadanymi), złamałoby zgodność wsteczną i musi być zaplanowane na następną główną wersję oprogramowania (1.0, 2.0, 3.0 itd.). Oznacza to, że w obrębie tej samej głównej wersji dozwolone są tylko zmiany GUI i zachowania, i można je zaplanować na następną wersję poboczną (0.1, 0.2, 0.3, potem 1.1, 1.2, 1.3 itd.).

Ansel ma zawsze tylko 2 kamienie milowe: następną wersję poboczną i następną wersję główną.

Definiowanie trudności

Trudność jest bezpośrednio związana z ilością pracy wymaganej przez zadanie, czyli:

• liczba linii kodu do napisania,
• liczba plików do zmiany,
• prawdopodobieństwo zepsucia istniejących funkcji, prowadzące do dodatkowej pracy przy testowaniu,
• istnienie podobnych funkcji lub spisanej teorii do wykonania zadania,
• narzut związany z zapewnieniem niezawodnego działania zmian i funkcji na różnych systemach operacyjnych.

Dokładne oszacowanie trudności jest czymś, co potrafi zrobić tylko doświadczony programista.

Definiowanie charakteru

Charakter zgłoszeń obsługiwany jest za pomocą etykiet. Mamy:

• regresje (rzeczy, które kiedyś działały, ale zostały zepsute przez stosunkowo niedawne zmiany),
• błędy (rzeczy, które nigdy nie działały przez ostatnie lata),
• ulepszenia (rzeczy, które trzeba poprawić lub dodać),
• wontfix (nie błąd, lecz funkcja, decyzja projektowa lub konieczność narzucona przez zależności firm trzecich),
• pytanie (nie powinno być na Githubie, lecz na https://community.ansel.photos),
• duplikat (zgłoszenie już zgłoszone),
• niejasne (zgłoszenia nie da się zrozumieć),
• nieprawidłowe (zgłoszenie jest „złe" zgodnie z powyższą definicją dobrego zgłoszenia).

Priorytety są względne

Zobacz https://www.youtube.com/watch?v=8fnfeuoh4s8 . Konieczność naprawy samochodu, aby wymienić żarówkę, to świetna metafora pisania kodu w 12-letnim oprogramowaniu mającym setki tysięcy linii kodu napisanego przez ludzi, którzy ze sobą nie rozmawiali i nie dokumentowali swoich zmian. Naprawa samochodu nie jest najwyższym priorytetem, dopóki nie stanie się warunkiem wstępnym naprawy wysokopriorytetowego światła.

Twoja praca segregatora

Ostatecznie tylko doświadczony programista będzie w stanie dokładnie segregować zgłoszenia. Ale rozsądek wymaga, aby doświadczony programista był zatrudniany do robienia rzeczy, które potrafi zrobić tylko doświadczony programista: pisania prostego kodu do wydajnego rozwiązywania problemów technicznych wymagających pewnej ilości teorii i projektowania.

Kompromis polega na tym, aby segregatorzy pomagali ustalać priorytety oczywistych zgłoszeń, tak by programiści musieli zajmować się tylko najmniej oczywistymi zgłoszeniami i skupiać się na kodowaniu.

1. etykietuj tylko te zgłoszenia, które rozumiesz i przy których czujesz się swobodnie podczas segregacji. Nie musisz robić ich wszystkich, to w porządku, jeśli czegoś nie wiesz.
2. w przypadku zgłoszeń, które rozumiesz:
   • przypisz etykietę priorytetu, jeśli potrafisz,
   • przypisz etykietę charakteru, jeśli potrafisz,
   • przypisz kamień milowy, jeśli potrafisz,
   • natychmiast zamknij zgłoszenie, jeśli jest nieprawidłowe lub jest duplikatem.
3. w przypadku zgłoszeń, których nie rozumiesz:
   • spróbuj zadać autorowi więcej pytań,
   • upewnij się, że autorzy wypełniają wszystkie istotne informacje (system operacyjny, sprzęt, kroki odtworzenia w przypadku błędów),
4. lepiej jest nie zrobić nic, niż zrobić to źle: zgłoszenia bez etykiet są łatwiejsze do wykrycia niż zgłoszenia z błędnymi etykietami.
5. nie wahaj się zwoływać spotkań wideo: lepiej usiąść razem na 30 min, żeby produktywnie porozmawiać i skorygować decyzje, niż wymieniać niekończące się wątki bezużytecznych wiadomości.

Dziękujemy !