Organizacja projektu

The project is run by the maintainer, who balances developing and maintaining the software with the rest of a life. This calls for low-overhead project management strategies, relying on cloud-based collaborative tools.

Działy

Rozwój oprogramowania

Rozwój odbywa się na Githubie ,

Feature requests are not taken from users at this point. Users are consulted by the developer regarding their needs when a (re)design project is started. This is to prevent disruptive inputs at random times that would only slow-down the opened projects. Consultations reach beyond the forum and chat regulars — through surveys when the stakes warrant it — because the people who show up in project spaces are a biased sample of the people who use the tool, and silence is not satisfaction: those who left or never came have needs too, and they are precisely the ones the loudest channels never carry.

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.

Developers who need help, an introduction to the code base, or code reviews can ask on the developer Matrix chat  or in GitHub Discussions ; mentorship is offered within the maintainer’s capacity.

Releases and stability

A stable release is a finished functional set, not a date: versions ship when what they promise works, and the triage rules define what lands in the next minor or major milestone. Two consequences. During foundation work — replacing a core library, reworking an architecture — feature work freezes until the foundations are done: building on a floor while someone replaces the joists wastes both people’s work. And there is no post-release rush: bugs found after a release enter the normal triage queue, in priority order, instead of triggering a scramble that itself creates regressions. Users who want to help stabilize a release test the candidate branch beforehand (validation), which is safe for your edits, unlike dev.

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.

They can be discussed in GitHub Discussions  or the Matrix chats , especially to confirm that they are actually bugs (and not design changes).

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. Video tutorials are published and indexed from the workflows section,
2. Educational long-form writing belongs on the website or in GitHub Discussions ,
3. The documentation is meant to provide usage information closely tied to the software GUI, so users could learn about the features in linear order of GUI appearance.
4. The main website workflow section is meant to provide usage information tied to a specific task to achieve, so users could learn “how to”.
5. The main website resources section is meant to provide background theoritical information to help building a deeper understanding of color and photography, and empower users to troubleshoot retouching issues themselves.

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.

In pull requests and issues, on Github please try to stay concise and on-point :

• 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:

• The main website has a central RSS feed, where new and updated page goes : global RSS,
• For more granularity, each section of the website (News, Doc, Workflows, etc.) has its own RSS feed too. The icon you find on section index pages and on every page links to that RSS feed in the current language.
• Code changes can be tracked from commits index on Github , or using the Github Atom feed  (truncated to the 20 most recent commits). Commit messages are usually quite verbose and should explain well enough what was changed and why.
• New commits, Github issues updates (created, edited, closed), new community posts and new website pages are all posted to a dedicated Matrix chat .
• Nightly builds packages are posted to a dedicated Matrix chat . They are also listed on the Github pre-release page .
• Open and closed project/issues can be seen on the Github Kanban board .