Projektorganisation

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.

Abteilungen

Softwareentwicklung

Die Entwicklung erfolgt auf Github ,

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.

Die Zeitplanung der derzeit bearbeiteten Themen ist auf dem Kanban-Board  verfügbar. Entwickler können Themen in der Zu erledigen Spalte auswählen. Neue Änderungen, auf die zu achten und zu testen sind, befinden sich in der Erledigt Spalte. Pull Requests, die dem Designprotokoll nicht folgen, werden abgelehnt.

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.

Nachrichten über abgeschlossene Entwicklungsprojekte oder Meilensteine werden auf diesem Blog veröffentlicht. Ein dedizierter Matrix-Chat  zentralisiert alle Updates und Benachrichtigungen zu neuen Commits, Github-Themen, neuen Blog-Posts und neuen Community-Foren-Posts.

Nightly Builds

Installierbare Pakete für Windows (.exe) und Linux (.AppImage) werden automatisch auf Github um 01:00 UTC erstellt, wenn am Vortag neue Commits gepusht wurden. Die direkten Download-Links werden in einem dedizierten Matrix-Chat  veröffentlicht, sodass du die Popups benachrichtigen und die neuen Builds erhalten kannst, alles an einem Ort.

Nightly Builds sollen frühe Tests von Anwendern fördern, die nicht in der Lage sind oder nicht selbst aus dem Quellcode bauen möchten. Sie können instabil sein.

Bugs

Bugs (im Sinne von Problemen, die die Software kaputtmachen), werden auf Github  behandelt, wenn sie bestätigt werden.

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

Es ist wichtig, Issues auf Github zu eröffnen, um sie in das Projektmanagement einzubeziehen und sie von einem zentralen Ort aus zu verfolgen.

Website

Die Website wird mit Hugo Static Website Builder  generiert, das eine relativ überkopfarme Möglichkeit bietet, technische Websites mithilfe der Markdown-Syntax zu schreiben.

Der Quellcode der Website befindet sich auf Github . Du kannst Tippfehler korrigieren oder direkt bei der Übersetzung helfen, indem du die Quelldateien in der Github-Oberfläche bearbeitest. Alternativ kannst du Hugo auf deinem Rechner installieren, dann erklärt die Readme Datei auf Github, wie du eine Vorschau-Website lokal mit einem Testserver auf deinem Rechner erstellst, um deine Änderungen besser vorzusehen (und zu testen).

Änderungen an der Website müssen den typischen Git + Pull Request (auf Github) Workflow verwenden, was Nicht-Programmierer abschrecken kann, aber es ist der geringste schlechte Weg, um remote an etwas Textbasiertem zusammenzuarbeiten, während umkehrbare Versionierung und Backups sichergestellt werden.

Dokumentation

Die Dokumentation ist aus Lizenzgründen (GPL v3) nicht im Website-Repository enthalten, daher wird sie als externes Hugo-Modul importiert. Der Quellcode befindet sich auf Github , und alles andere gilt für die Website. Die Readme stellt die verfügbaren Shortcodes vor, die du zum Formattieren des Inhalts in Markdown-Dateien verwenden kannst.

Es gibt jedoch einen Haken, wenn du die Dokumentation lokal erstellen willst, da sie das Theme von der Haupt-Ansel Website importiert, sodass tatsächlich der einfachste Weg ist, die Haupt-Website zu erstellen, während die Dokumentation lokal als Modul verlinkt ist. Das Verfahren ist im Readme der Hauptseite detailliert.

Die Dokumentation befindet sich derzeit im Strukturwandel, zusammen mit Änderungen am Software Design, also zögere nicht, auf Matrix  nachzufragen, wenn du ein besonderes Projekt im Sinn hast, bevor du dich zu etwas verpflichtest, das kurz davor steht entfernt zu werden.

Unterricht und Benutzererziehung

Wie viele “Bugs”-Meldungen zeigen, haben unzureichend geschulte Benutzer falsche Erwartungen, und wenn man ihre Feature-Requests zu ernst nimmt, endet man mit verkrüppelter Software, die Funktionen und CPU-Belastungen dupliziert. Diese müssen an der Wurzel gelöst werden : durch Unterricht.

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.

Verwaltung

Das meiste ist ein Einzelprojekt, daher muss es effizient und überkopfarm sein. Das erfordert etwas Disziplin.

Programmierungsmanagement

Normalerweise gibt es zwei offene Programmierprojekte gleichzeitig, die ausgewählt werden, weil sie voneinander unabhängig sind. Dies ermöglicht es, zu Projekt #2 zu wechseln, während man auf Benutzerfeedback zu Änderungen in #1 wartet, in einer Weise, die es trotzdem erlaubt, zu identifizieren, welches Rückschläge und neue Bugs verursacht hat. Betrachte es als alternativen Fokus.

Mitten in einem Projekt wird der Entwickler typischerweise weder mit noch über oder auf Probleme in anderen Teilen der Software hören, weil die mentale Belastbarkeit eine kostbare Ressource ist, die schneller verbraucht als wiederhergestellt wird. Insbesondere werden Feature-Requests für andere Teile der Software ignoriert.

Der tägliche Fokus kann unerwartet wechseln, abhängig von den entdeckten Problemen beim Beseitigen anderer Probleme, dank Darktable’s miserablen Erbes halbbroken Wahnsinn-spaghetticode, die oft teilweise oder vollständige Umschreibungen (in jedem Fall, Aufräumen) erfordert, bevor man versucht, irgendetwas zu reparieren (in einer Weise, die nicht zukünftige Probleme hervorruft, das heißt).

Kommunikation

Wir leben in einer Welt, in der das Informations- und Kommunikationsvolumen überwältigend geworden ist und Menschen nicht die Bandbreite haben, es alles zu verarbeiten. Endlose Threads und unregulierte Konversationen schaden aktiv der Kommunikation durch Verdünnen wichtiger Informationen und Ermüden des Lesers. Diskussion ist lediglich dafür gedacht, ein Verständnis zu erreichen und zu umsetzbaren Entscheidungen zu gelangen. Es gibt einen subtilen Kompromiss zwischen Vollständigkeit und Prägnanz zu finden.

Für allgemeine Fragen oder Chat bitte die Matrix-Räume  verwenden. Aber auch dort ist Prägnanz der Schlüssel.

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

• Technische Details (wie Betriebssystem, Verwendung von OpenCL, Bildschirmgröße, etc.) sollten Bullet-Point-Listen verwenden.
• Screenshots und Zeichnungen können viel bewirken.
• Wenn du auf einen bestimmten Punkt oder eine Person antwortest, zitiere den Abschnitt des Textes, auf den du antwortest.
• Teile deinen Text in Absätze von ungefähr 4 bis 8 Zeilen, aber vermeide es, jedem Satz einen neuen Absatz zuzugeben.
• Beachte bitte, dass jeder Englisch spricht, aber nur sehr wenige Menschen Muttersprachler sind, also versuche, bei einfachem Globish  zu bleiben.

Gute Prinzipien für Interaktionen in Problemen/Tickets sind hier  zu finden.

Updates und Benachrichtigungen

Viele zentrale und automatisierte Wege werden angeboten, um den Überblick über Neuigkeiten im Projekt zu behalten:

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