Organizacja projektu

Projektem kieruje Aurélien Pierre, który stara się godzić pracę fotograficzną (niemal nieistniejącą od 2019 roku), rozwój i utrzymanie oprogramowania oraz szkolenie użytkowników podczas indywidualnych sesji. Wymaga to strategii zarządzania projektem o niskim narzucie, opartych na chmurowych narzędziach do współpracy.

Działy

Rozwój oprogramowania

Rozwój odbywa się na Githubie ,

Na tym etapie prośby o nowe funkcje nie są przyjmowane od użytkowników. Deweloper konsultuje się z użytkownikami w sprawie ich potrzeb, gdy rozpoczynany jest projekt (prze)projektowania. Ma to zapobiec destrukcyjnym wtrętom w przypadkowych momentach, które jedynie spowalniałyby otwarte projekty.

Harmonogram zgłoszeń, nad którymi obecnie trwają prace, jest dostępny na tablicy Kanban . Deweloperzy mogą wybierać zgłoszenia z kolumny To Do. Nowe zmiany do obejrzenia i przetestowania znajdują się w kolumnie Done. Pull requesty, które nie przestrzegają protokołu projektowania, zostaną odrzucone.

Deweloperzy, którzy potrzebują pomocy, wprowadzenia do bazy kodu lub przeglądu kodu, mogą umówić się na spotkanie z Aurélienem Pierre’em , aby zrobić to za pośrednictwem wideokonferencji (ewentualnie z użyciem Visual Studio Live Share ).

Nowości o zamkniętych projektach deweloperskich lub kamieniach milowych są publikowane na blogu. Dedykowany czat Matrix  centralizuje wszystkie aktualizacje i powiadomienia o nowych commitach, zgłoszeniach na Githubie, nowych wpisach na blogu i nowych postach na forum społeczności.

Kompilacje nocne

Pakiety instalacyjne dla Windowsa (.exe) i Linuksa (.AppImage) są budowane automatycznie na Githubie około godziny 1:00 czasu UTC, jeśli poprzedniego dnia zostały wypchnięte nowe commity. Bezpośrednie linki do pobrania są publikowane na dedykowanym czacie Matrix , więc możesz obserwować pojawiające się powiadomienia i pobierać nowe kompilacje — wszystko w jednym miejscu.

Kompilacje nocne (nightly builds) mają promować wczesne testowanie przez użytkowników, którzy nie mogą lub nie chcą samodzielnie budować oprogramowania ze źródeł. Mogą być niestabilne.

Błędy

Błędy (rozumiane jako rzeczy, które psują oprogramowanie) są obsługiwane na Githubie , gdy zostaną potwierdzone.

Można je omawiać na forum społeczności lub na czatach Matrix , zwłaszcza aby potwierdzić, że są to faktycznie błędy (a nie zmiany projektowe).

Zakładanie zgłoszeń na Githubie jest ważne, aby włączyć je do zarządzania projektem i śledzić je z jednego miejsca.

Strona internetowa

Strona internetowa jest generowana za pomocą generatora stron statycznych Hugo , który jest dość niskonakładowym sposobem pisania technicznych stron internetowych przy użyciu składni Markdown.

Kod źródłowy strony znajduje się na Githubie . Możesz poprawiać literówki lub pomagać w tłumaczeniu bezpośrednio, edytując pliki źródłowe w interfejsie Githuba. W przeciwnym razie możesz zainstalować Hugo na swoim komputerze, a wówczas plik Readme na Githubie wyjaśnia, jak zbudować lokalnie podglądową wersję strony przy użyciu serwera testowego na Twoim komputerze, aby lepiej podglądać (i debugować) swoje zmiany.

Zmiany na stronie muszą korzystać z typowego przepływu pracy Git + Pull Request (na Githubie), co może zniechęcać osoby nieprogramujące, ale jest to najmniej beznadziejny sposób zdalnej współpracy nad czymś opartym na tekście, przy jednoczesnym zapewnieniu odwracalnego wersjonowania i kopii zapasowych.

Dokumentacja

Dokumentacja nie jest dołączona do repozytorium strony z powodów licencyjnych (GPL v3), więc jest importowana jako zewnętrzny moduł Hugo. Kod źródłowy znajduje się na Githubie , a wszystko inne stosuje się tak samo jak w przypadku strony. Plik Readme przedstawia dostępne shortcode’y, których możesz użyć do formatowania treści w plikach Markdown.

Jest jednak pewne zastrzeżenie, jeśli chcesz zbudować dokumentację lokalnie, ponieważ importuje ona motyw z głównej strony Ansel, więc najłatwiejszym sposobem jest w istocie zbudowanie głównej strony przy jednoczesnym lokalnym podlinkowaniu dokumentacji jako modułu. Procedura jest szczegółowo opisana w pliku Readme głównej strony.

Dokumentacja obecnie przechodzi zmiany strukturalne, wraz ze zmianami projektowymi oprogramowania, więc nie wahaj się zapytać na Matriksie , jeśli masz na myśli konkretny projekt, zanim zaangażujesz się w coś, co lada moment zostanie usunięte.

Nauczanie i szkolenie użytkowników

Jak pokazuje wiele zgłoszeń „błędów", niedostatecznie przeszkoleni użytkownicy mają błędne oczekiwania, a jeśli potraktujesz ich prośby o nowe funkcje zbyt poważnie, skończysz z okaleczonym oprogramowaniem powielającym funkcje i obciążenie procesora. Trzeba to rozwiązywać u źródła: poprzez nauczanie.

1. Forum społeczności ma miejsce na publikowanie linków do samouczków wideo,
2. Forum społeczności ma miejsce, w którym użytkownicy mogą pisać edukacyjne wpisy blogowe,
3. Dokumentacja ma dostarczać informacji o użytkowaniu ściśle powiązanych z interfejsem graficznym oprogramowania, aby użytkownicy mogli poznawać funkcje w liniowej kolejności pojawiania się w GUI.
4. Sekcja workflow głównej strony ma dostarczać informacji o użytkowaniu powiązanych z konkretnym zadaniem do wykonania, aby użytkownicy mogli nauczyć się „jak to zrobić".
5. Sekcja zasoby głównej strony ma dostarczać podstawowych informacji teoretycznych, które pomagają budować głębsze zrozumienie koloru i fotografii oraz umożliwiają użytkownikom samodzielne rozwiązywanie problemów z retuszem.
6. Użytkownicy mogą zarezerwować indywidualne sesje szkoleniowe  (zajęcia) z Aurélienem Pierre’em, dla szybszego i bardziej skoncentrowanego szkolenia.

Zarządzanie

To w większości jednoosobowe przedsięwzięcie, więc rzeczy muszą być wydajne i niskonakładowe. Co wymaga pewnej dyscypliny.

Zarządzanie programowaniem

Zazwyczaj w tym samym czasie otwarte są 2 projekty programistyczne, wybrane dlatego, że są od siebie niezależne. Pozwala to przełączyć się na projekt nr 2 podczas oczekiwania na opinie użytkowników o zmianach wprowadzonych w projekcie nr 1, w sposób, który wciąż pozwala zidentyfikować, który z nich spowodował regresje i nowe błędy. Pomyśl o tym jak o naprzemiennym pojedynczym skupieniu.

W trakcie projektu deweloper zazwyczaj nie zajmuje się, nie przejmuje się ani nie słucha zgłoszeń związanych z czymkolwiek poza tym projektem, ponieważ moc umysłowa to cenny zasób, wydawany szybciej, niż się odnawia. W szczególności prośby o nowe funkcje w innych częściach oprogramowania zostaną pominięte.

Bieżące, codzienne skupienie może zmienić się nieoczekiwanie, w zależności od gówna odkrytego podczas naprawiania innego gówna, dzięki fatalnemu dziedzictwu Darktable w postaci na wpół zepsutego, niemodularnego, doprowadzającego do szału kodu spaghetti, które często wymaga częściowego lub pełnego przepisania (a w każdym razie posprzątania), zanim w ogóle spróbuje się cokolwiek naprawić (w sposób, który nie wywołuje kolejnych przyszłych problemów, rzecz jasna).

Komunikacja

Żyjemy w świecie, w którym objętość informacji i komunikacji stała się przytłaczająca, a ludzie nie mają przepustowości, by przetworzyć to wszystko. Niekończące się wątki i nieuregulowane rozmowy czynnie szkodzą komunikacji, rozcieńczając ważne informacje i wyczerpując czytelnika. Dyskusja służy wyłącznie osiągnięciu porozumienia i przejściu do wykonalnych decyzji. Istnieje subtelny kompromis do znalezienia między kompletnością a zwięzłością.

Do czatu lub ogólnych pytań używaj przestrzeni Matrix . Ale nawet tam zwięzłość jest kluczowa.

W pull requestach i zgłoszeniach, czy to na Githubie, czy na forum społeczności, staraj się pozostać zwięzłym i na temat:

• Szczegóły techniczne (takie jak system operacyjny, użycie OpenCL, rozmiar ekranu itd.) powinny korzystać z list wypunktowanych.
• Zrzuty ekranu i rysunki mogą wiele zdziałać.
• Jeśli odpowiadasz na konkretny punkt lub konkretnej osobie, zacytuj fragment tekstu, na który odpowiadasz.
• Dziel swój tekst na akapity o mniej więcej 4 do 8 wierszy, ale unikaj wysyłania każdego zdania do nowego akapitu.
• Pamiętaj, że wszyscy mówią po angielsku, ale bardzo niewiele osób jest rodzimymi użytkownikami, więc staraj się trzymać podstawowego Globisha .

Dobre zasady dotyczące interakcji przy zgłoszeniach/ticketach można znaleźć tutaj .

Aktualizacje i powiadomienia

Oferowanych jest wiele scentralizowanych i zautomatyzowanych sposobów, aby śledzić, co nowego w projekcie:

• Główna strona ma centralny kanał RSS, do którego trafiają nowe i zaktualizowane strony: globalny RSS,
• Dla większej szczegółowości każda sekcja strony (Nowości, Dokumentacja, Workflow itd.) ma też własny kanał RSS. Ikona , którą znajdziesz na stronach indeksu sekcji oraz na każdej stronie, linkuje do tego kanału RSS w bieżącym języku.
• Strona społeczności również ma centralny publiczny kanał RSS (obcięty do 25 najnowszych wydarzeń).
• Zmiany w kodzie można śledzić z indeksu commitów na Githubie  lub za pomocą kanału Atom Githuba  (obcięty do 20 najnowszych commitów). Wiadomości commitów są zazwyczaj dość rozbudowane i powinny wystarczająco dobrze wyjaśniać, co i dlaczego zostało zmienione.
• Nowe commity, aktualizacje zgłoszeń na Githubie (utworzone, edytowane, zamknięte), nowe posty społeczności i nowe strony witryny są publikowane na dedykowanym czacie Matrix .
• Pakiety kompilacji nocnych są publikowane na dedykowanym czacie Matrix . Są też wymienione na stronie wydań wstępnych Githuba .
• Otwarte i zamknięte projekty/zgłoszenia można zobaczyć na tablicy Kanban  Githuba.