Organizzazione del progetto

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.

Dipartimenti

Sviluppo del software

Lo sviluppo avviene su 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.

La pianificazione temporale delle issue attualmente in lavorazione è disponibile sulla bacheca Kanban . Gli sviluppatori possono scegliere le issue nella colonna To Do. Le nuove modifiche da osservare e testare si trovano nella colonna Done. Le pull request che non seguono il protocollo di progettazione verranno rifiutate.

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.

Le notizie sui progetti di sviluppo conclusi o sulle milestone vengono pubblicate sul blog. Una chat Matrix  dedicata centralizza tutti gli aggiornamenti e le notifiche dei nuovi commit, delle issue Github, dei nuovi post del blog e dei nuovi post del forum della comunità.

Build notturne

I pacchetti installabili per Windows (.exe) e Linux (.AppImage) vengono compilati automaticamente su Github intorno all'1:00 UTC, se il giorno precedente sono stati inviati nuovi commit. I link di download diretti vengono pubblicati su una chat Matrix  dedicata, così puoi vedere comparire le notifiche e ottenere le nuove build, tutto in un unico posto.

Le build notturne (nightly) hanno lo scopo di promuovere il collaudo precoce da parte degli utenti che non possono o non vogliono compilarle da sé dai sorgenti. Possono essere instabili.

Bug

I bug (ovvero le cose che rompono il software) vengono gestiti su Github  quando sono confermati.

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

Aprire le issue su Github è importante per includerle nella gestione del progetto e tenerne traccia da un unico posto.

Sito web

Il sito web è generato usando Hugo, il generatore di siti web statici , che è un modo abbastanza a basso carico gestionale per scrivere siti web tecnici usando la sintassi Markdown.

Il codice sorgente del sito web è su Github . Puoi correggere refusi o aiutare con la traduzione direttamente modificando i file sorgente dall’interfaccia di Github. In alternativa, puoi installare Hugo sul tuo computer, quindi il file Readme su Github spiega come compilare un’anteprima del sito web in locale, usando un server di prova sul tuo computer, per visualizzare in anteprima (e correggere) meglio le tue modifiche.

Le modifiche al sito web devono usare il tipico flusso di lavoro Git + Pull Request (su Github), che può scoraggiare i non programmatori, ma è il modo meno pessimo di collaborare da remoto su qualcosa di basato sul testo, garantendo al contempo versioning e backup reversibili.

Documentazione

La documentazione non è inclusa nel repository del sito web per ragioni di licenza (GPL v3), quindi viene importata come modulo Hugo esterno. Il codice sorgente è su Github , e tutto il resto si applica allo stesso modo del sito web. Il Readme presenta gli shortcode disponibili che puoi usare per formattare il contenuto, nei file Markdown.

C’è però un’avvertenza, se vuoi compilare la documentazione in locale, perché importa il tema dal sito web principale di Ansel, quindi il modo più semplice è in realtà compilare il sito web principale collegando localmente la documentazione come modulo. La procedura è descritta in dettaglio nel Readme del sito web principale.

La documentazione è attualmente in fase di modifiche strutturali, insieme alle modifiche di progettazione del software, quindi non esitare a chiedere su Matrix  se hai in mente un progetto particolare, prima di impegnarti su qualcosa che è sul punto di essere rimosso.

Insegnamento e formazione degli utenti

Come mostrano molte segnalazioni di «bug», gli utenti insufficientemente formati hanno aspettative errate e, se prendi le loro richieste di funzioni troppo sul serio, finisci con un software azzoppato che duplica funzioni e carico della CPU. Questi vanno risolti alla radice : con l’insegnamento.

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.

Gestione

Questa è per lo più un’operazione portata avanti da una sola persona, quindi le cose devono essere efficienti e a basso carico gestionale. Il che richiede una certa disciplina.

Gestione della programmazione

Di solito ci sono 2 progetti di programmazione aperti contemporaneamente, scelti perché indipendenti l’uno dall’altro. Questo permette di passare al progetto n. 2 mentre si attende il feedback degli utenti sulle modifiche apportate al n. 1, in un modo che consente comunque di identificare quale dei due ha creato regressioni e nuovi bug. Pensalo come un focus singolo alternato.

Nel bel mezzo di un progetto, lo sviluppatore in genere non si occuperà, non si preoccuperà né darà ascolto a issue relative a qualsiasi cosa che non sia quel progetto, perché la capacità mentale è una risorsa preziosa, più veloce da spendere che da recuperare. In particolare, le richieste di funzioni su altre parti del software verranno ignorate.

Il focus quotidiano è soggetto a cambiamenti inaspettati, a seconda della merda scoperta mentre si sistema altra merda, grazie alla pessima eredità di darktable fatta di codice spaghetti semi-rotto, non modulare e da far impazzire, che spesso richiede riscritture parziali o complete (in ogni caso, una ripulitura) prima di tentare di sistemare qualsiasi cosa (in un modo che non induca ulteriori problemi futuri, s’intende).

Comunicazione

Viviamo in un mondo in cui il volume di informazioni e comunicazioni è diventato travolgente e gli esseri umani non hanno la banda per elaborarlo tutto. I thread infiniti e le conversazioni non regolamentate danneggiano attivamente la comunicazione diluendo le informazioni importanti ed esaurendo il lettore. La discussione ha il solo scopo di raggiungere una comprensione e di procedere verso decisioni attuabili. C’è un sottile compromesso da trovare tra completezza e concisione.

Per la chat o le domande generali, usa lo spazio Matrix . Ma anche lì, la concisione è fondamentale.

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

• I dettagli tecnici (come sistema operativo, uso di OpenCL, dimensione dello schermo, ecc.) dovrebbero usare elenchi puntati.
• Screenshot e disegni possono essere di grande aiuto.
• Se stai rispondendo a un punto o a una persona in particolare, cita la sezione di testo a cui stai rispondendo.
• Suddividi il tuo testo in paragrafi di circa 4-8 righe, ma evita di mandare ogni frase in un nuovo paragrafo.
• Tieni presente che tutti parlano inglese ma pochissime persone sono madrelingua, quindi cerca di attenerti al Globish  di base.

Buoni principi sulle interazioni con issue/ticket si possono trovare qui .

Aggiornamenti e notifiche

Vengono offerti molti modi centralizzati e automatizzati per tenere traccia delle novità del progetto :

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