Projectorganisatie

Het project wordt geleid door Aurélien Pierre, die probeert een balans te vinden tussen zijn fotografiewerk (grotendeels onbestaand sinds 2019), het ontwikkelen en onderhouden van de software, en het begeleiden van gebruikers in individuele trainingssessies. Dit vraagt om projectmanagementstrategieën met weinig overhead, die steunen op cloudgebaseerde samenwerkingstools.

Afdelingen

Softwareontwikkeling

Ontwikkeling gebeurt op Github ,

Op dit moment worden er geen functieverzoeken van gebruikers aangenomen. Gebruikers worden door de ontwikkelaar geraadpleegd over hun behoeften wanneer een (her)ontwerpproject wordt gestart. Dit om te voorkomen dat er op willekeurige momenten verstorende input komt die de lopende projecten alleen maar zou vertragen.

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.

Ontwikkelaars die hulp nodig hebben, een introductie tot de codebase, of code reviews kunnen een afspraak boeken met Aurélien Pierre  om dit via videoconferentie te doen (eventueel met Visual Studio Live Share ).

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.

Ze kunnen worden besproken op het communityforum of de Matrix-chats , met name om te bevestigen dat het daadwerkelijk bugs zijn (en geen ontwerpwijzigingen).

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. Het communityforum heeft een plek om links naar videotutorials te plaatsen,
2. Het communityforum heeft een plek voor gebruikers om educatieve blogposts te schrijven,
3. De documentatie is bedoeld om gebruiksinformatie te bieden die nauw aansluit bij de GUI van de software, zodat gebruikers over de functies kunnen leren in de lineaire volgorde waarin ze in de GUI verschijnen.
4. De sectie workflow op de hoofdwebsite is bedoeld om gebruiksinformatie te bieden die gekoppeld is aan een specifieke taak, zodat gebruikers de “hoe te” kunnen leren.
5. De sectie resources op de hoofdwebsite is bedoeld om theoretische achtergrondinformatie te bieden die helpt bij het opbouwen van een dieper begrip van kleur en fotografie, en gebruikers in staat stelt retoucheerproblemen zelf op te lossen.
6. Gebruikers kunnen 1-op-1 trainingssessies boeken  (lessen) met Aurélien Pierre, voor snellere en meer gerichte training.

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.

Probeer in pull requests en issues, zowel op Github als op het communityforum, alsjeblieft beknopt en to the point te blijven :

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

• De hoofdwebsite heeft een centrale RSS-feed, waar nieuwe en bijgewerkte pagina’s naartoe gaan : globale RSS,
• Voor meer granulariteit heeft elke sectie van de website (News, Doc, Workflows, enz.) ook zijn eigen RSS-feed. Het -icoon dat je vindt op de indexpagina’s van secties en op elke pagina linkt naar die RSS-feed in de huidige taal.
• De communitywebsite heeft ook een centrale openbare RSS-feed (afgekapt tot de 25 meest recente gebeurtenissen).
• Codewijzigingen kunnen worden gevolgd via de commit-index op Github , of met de Github Atom-feed  (afgekapt tot de 20 meest recente commits). Commit-berichten zijn doorgaans vrij uitvoerig en zouden goed genoeg moeten uitleggen wat er is gewijzigd en waarom.
• Nieuwe commits, updates van Github-issues (aangemaakt, bewerkt, gesloten), nieuwe communityberichten en nieuwe websitepagina’s worden allemaal geplaatst in een speciale Matrix-chat .
• Pakketten van nightly builds worden geplaatst in een speciale Matrix-chat . Ze staan ook vermeld op de Github pre-release-pagina .
• Open en gesloten projecten/issues zijn te zien op het Github Kanban-bord .