Projectorganisatie

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.

Afdelingen

Softwareontwikkeling

Ontwikkeling gebeurt op 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.

De tijdsplanning van de issues waaraan momenteel wordt gewerkt is beschikbaar op het Kanban-bord . Ontwikkelaars kunnen issues oppakken uit de kolom To Do. Nieuwe wijzigingen om in de gaten te houden en te testen staan in de kolom Done. Pull requests die het ontwerpprotocol niet volgen worden geweigerd.

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.

Nieuws over afgesloten ontwikkelprojecten of mijlpalen wordt gepubliceerd op de blog. Een speciale Matrix-chat  centraliseert alle updates en meldingen van nieuwe commits, Github-issues, nieuwe blogposts en nieuwe berichten op het communityforum.

Nightly builds

Installeerbare pakketten voor Windows (.exe) en Linux (.AppImage) worden automatisch op Github gebouwd rond 1:00 uur UTC, als er de dag ervoor nieuwe commits zijn gepusht. De directe downloadlinks worden gepubliceerd naar een speciale Matrix-chat , zodat je de meldingen kunt zien verschijnen en de nieuwe builds kunt ophalen, allemaal op één plek.

Nightly builds zijn bedoeld om vroegtijdig testen te bevorderen door gebruikers die niet zelf vanaf de broncode kunnen of willen bouwen. Ze kunnen instabiel zijn.

Bugs

Bugs (dat wil zeggen, dingen die de software kapotmaken) worden op Github  behandeld zodra ze zijn bevestigd.

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

Het openen van issues op Github is belangrijk om ze op te nemen in het projectmanagement en ze vanaf één plek te volgen.

Website

De website wordt gegenereerd met Hugo static website builder , wat een manier met vrij weinig overhead is om technische websites te schrijven met Markdown-syntaxis.

De broncode van de website staat op Github . Je kunt typefouten corrigeren of helpen met vertalen door de bronbestanden direct in de Github-UI te bewerken. Anders kun je Hugo op je computer installeren, en dan legt het Readme-bestand op Github uit hoe je lokaal een preview-website bouwt, met een testserver op je computer, om je wijzigingen beter te bekijken (en te debuggen).

Wijzigingen aan de website moeten de gebruikelijke Git + Pull Request-workflow (op Github) gebruiken, wat niet-programmeurs kan afschrikken, maar het is de minst waardeloze manier om op afstand samen te werken aan iets tekstgebaseerds, terwijl reversibele versiebeheer en back-ups gewaarborgd blijven.

Documentatie

De documentatie is om licentieredenen (GPL v3) niet opgenomen in de website-repository, dus wordt ze geïmporteerd als een externe Hugo-module. De broncode staat op Github , en al het overige is hetzelfde als voor de website. De Readme presenteert de beschikbare shortcodes die je kunt gebruiken om de inhoud in Markdown-bestanden op te maken.

Er is echter een kanttekening als je de documentatie lokaal wilt bouwen, want ze importeert het thema van de hoofdwebsite van Ansel, dus de gemakkelijkste manier is eigenlijk om de hoofdwebsite te bouwen terwijl je de documentatie lokaal als module koppelt. De procedure staat uitgebreid beschreven in de Readme van de hoofdwebsite.

De documentatie ondergaat momenteel structurele wijzigingen, samen met wijzigingen in het softwareontwerp, dus aarzel niet om op Matrix  te vragen of je een bepaald project in gedachten hebt, voordat je je vastlegt op iets wat op het punt staat verwijderd te worden.

Onderwijs en gebruikerseducatie

Zoals veel “bug”-meldingen laten zien, hebben onvoldoende getrainde gebruikers verkeerde verwachtingen, en als je hun functieverzoeken te serieus neemt, kom je uit op verminkte software die functies en CPU-belasting dupliceert. Die moeten bij de wortel worden opgelost : met onderwijs.

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.

Beheer

Dit is grotendeels een eenmansoperatie, dus dingen moeten efficiënt zijn en weinig overhead hebben. Wat enige discipline vereist.

Programmeerbeheer

Er lopen doorgaans 2 programmeerprojecten tegelijk, die zo worden gekozen dat ze onafhankelijk van elkaar zijn. Dit maakt het mogelijk om over te schakelen naar project #2 terwijl je wacht op gebruikersfeedback over wijzigingen in #1, op een manier waarbij nog steeds te achterhalen is welk van de twee regressies en nieuwe bugs heeft veroorzaakt. Zie het als afwisselende enkelvoudige focus.

Midden in een project zal de ontwikkelaar zich doorgaans niet bezighouden met, geven om, of luisteren naar issues die iets anders betreffen dan dat project, want hersencapaciteit is een kostbare grondstof, sneller uitgegeven dan hersteld. In het bijzonder worden functieverzoeken over andere delen van de software genegeerd.

De dagelijkse focus kan onverwacht veranderen, afhankelijk van de troep die aan het licht komt tijdens het repareren van andere troep, dankzij Darktables waardeloze erfenis van halfkapotte, niet-modulaire, waanzin opwekkende spaghetticode, die vaak gedeeltelijke of volledige herschrijvingen vereist (in elk geval opschonen) voordat je überhaupt iets probeert te repareren (op een manier die niet meer toekomstige problemen veroorzaakt, wel te verstaan).

Communicatie

We leven in een wereld waarin de hoeveelheid informatie en communicatie overweldigend is geworden en mensen niet de bandbreedte hebben om het allemaal te verwerken. Eindeloze threads en ongereguleerde gesprekken schaden de communicatie actief door belangrijke informatie te verdunnen en de lezer uit te putten. Discussie is er uitsluitend om tot een gemeenschappelijk begrip te komen en over te gaan tot bruikbare beslissingen. Er is een subtiele afweging tussen volledigheid en beknoptheid te vinden.

Gebruik voor chat of algemene vragen alsjeblieft de Matrix-space . Maar zelfs daar is beknoptheid essentieel.

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

• Technische details (zoals OS, gebruik van OpenCL, schermgrootte, enz.) kun je het beste in opsommingslijsten zetten.
• Screenshots en tekeningen kunnen veel helpen.
• Als je op een bepaald punt of persoon reageert, citeer dan het tekstgedeelte waarop je reageert.
• Verdeel je tekst in alinea’s van ongeveer 4 tot 8 regels, maar vermijd het om elke zin naar een nieuwe alinea te sturen.
• Houd er rekening mee dat iedereen Engels spreekt maar heel weinig mensen moedertaalsprekers zijn, dus probeer je te houden aan basaal Globish .

Goede principes voor interacties op issues/tickets zijn hier  te vinden.

Updates en meldingen

Er worden veel gecentraliseerde en geautomatiseerde manieren geboden om bij te houden wat er nieuw is in het project :

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