Projektorganisation

Das Projekt wird von Aurélien Pierre geleitet, der versucht, seine Fotografiearbeit (hauptsächlich seit 2019 nicht mehr existent), das Entwickeln & Warten der Software, und das Benutzertraining in Einzeltrainingsitzungen in Einklang zu bringen. Das erfordert projektmanagementstrategien mit geringem Overhead, die auf cloudbasierten Kollaborationstools beruhen.

Abteilungen

Softwareentwicklung

Die Entwicklung erfolgt auf Github ,

Feature-Requests werden zu diesem Zeitpunkt nicht von Nutzern angenommen. Die Entwickler konsultieren die Benutzer bezüglich ihrer Bedürfnisse, wenn ein (Re)Design-Projekt gestartet wird. Dies soll störende Eingaben zu zufälligen Zeiten verhindern, die nur die geöffneten Projekte verlangsamen würden.

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.

Entwickler, die Hilfe, eine Einführung in den Code oder Code-Reviews benötigen, können einen Termin mit Aurélien Pierre buchen  um dies per Videokonferenz durchzuführen (möglicherweise mit Visual Studio Live Share ).

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.

Sie können im Community-Forum oder den Matrix-Chats  diskutiert werden, insbesondere um zu bestätigen, dass es sich tatsächlich um Bugs handelt (und nicht um Designänderungen).

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. Das Community-Forum bietet einen Platz, um Links zu Video-Tutorials zu veröffentlichen,
2. Das Community-Forum bietet Benutzern Platz zum Schreiben von pädagogischen Blog-Posts,
3. Die Dokumentation soll Nutzungshinweise bieten, die eng mit der Benutzeroberfläche der Software verbunden sind, sodass Benutzer mehr über die Funktionen in linearer Reihenfolge des Aussehens der GUI lernen können.
4. Die Workflow Sektion der Haupt-Website soll nutzungsbezogene Informationen zu einem bestimmten zu erreichenden Task bereitstellen, damit Benutzer lernen können “wie man”.
5. Der Ressourcen Abschnitt der Hauptwebsite soll theoretische Hintergrundinformationen bereitstellen, um ein tieferes Verständnis von Farbe und Fotografie zu fördern und Benutzer zu befähigen, selbstständig Retuschierungsprobleme zu lösen.
6. Benutzer können Einzeltrainings-Sitzungen  (Kurse) mit Aurélien Pierre buchen, um schnelleres und fokussierteres Training zu erhalten.

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 und Issues, egal ob auf Github oder im Community Forum bitte versuchen, prägnant und punktuell zu bleiben:

• 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.
• The Community website has a central public RSS feed too (truncated to the 25 most recent events).
• 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 .