Organizzazione del progetto

Il progetto è gestito da Aurélien Pierre, che cerca di bilanciare il suo lavoro fotografico (per lo più inesistente dal 2019), lo sviluppo e la manutenzione del software e la formazione degli utenti in sessioni di formazione individuali. Questo richiede strategie di gestione del progetto a basso carico gestionale, basandosi su strumenti collaborativi in cloud.

Dipartimenti

Sviluppo del software

Lo sviluppo avviene su Github ,

Al momento non vengono accettate richieste di funzioni dagli utenti. Gli utenti vengono consultati dallo sviluppatore riguardo alle loro esigenze quando viene avviato un progetto di (ri)progettazione. Questo per evitare input dirompenti in momenti casuali che non farebbero altro che rallentare i progetti aperti.

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.

Gli sviluppatori che hanno bisogno di aiuto, di un’introduzione al codice o di revisioni del codice possono prenotare un appuntamento con Aurélien Pierre  per farlo tramite videoconferenza (eventualmente usando Visual Studio Live Share ).

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.

Possono essere discussi su il forum della comunità o sulle chat Matrix , in particolare per confermare che si tratti effettivamente di bug (e non di modifiche di progettazione).

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. Il forum della comunità ha uno spazio per pubblicare link a video tutorial,
2. Il forum della comunità ha uno spazio in cui gli utenti possono scrivere post di blog educativi,
3. La documentazione ha lo scopo di fornire informazioni d’uso strettamente legate alla GUI del software, così che gli utenti possano imparare le funzioni nell’ordine lineare di comparsa nella GUI.
4. La sezione workflow del sito web principale ha lo scopo di fornire informazioni d’uso legate a un compito specifico da svolgere, così che gli utenti possano imparare “come si fa”.
5. La sezione risorse del sito web principale ha lo scopo di fornire informazioni teoriche di base per aiutare a costruire una comprensione più profonda del colore e della fotografia, e per mettere gli utenti in grado di risolvere da sé i problemi di ritocco.
6. Gli utenti possono prenotare sessioni di formazione individuali  (lezioni) con Aurélien Pierre, per una formazione più rapida e mirata.

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.

Nelle pull request e nelle issue, sia su Github che sul forum della comunità, cerca per favore di rimanere conciso e pertinente :

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

• Il sito web principale ha un feed RSS centrale, in cui finiscono le pagine nuove e aggiornate : RSS globale,
• Per una maggiore granularità, anche ogni sezione del sito web (News, Doc, Workflow, ecc.) ha il proprio feed RSS. L’icona che trovi nelle pagine indice delle sezioni e su ogni pagina rimanda a quel feed RSS nella lingua corrente.
• Anche il sito web della comunità ha un feed RSS pubblico centrale (troncato ai 25 eventi più recenti).
• Le modifiche al codice possono essere tracciate dall’indice dei commit su Github , o usando il feed Atom di Github  (troncato ai 20 commit più recenti). I messaggi dei commit sono di solito abbastanza dettagliati e dovrebbero spiegare a sufficienza cosa è stato cambiato e perché.
• I nuovi commit, gli aggiornamenti delle issue Github (create, modificate, chiuse), i nuovi post della comunità e le nuove pagine del sito web vengono tutti pubblicati su una chat Matrix dedicata .
• I pacchetti delle build notturne (nightly) vengono pubblicati su una chat Matrix dedicata . Sono anche elencati sulla pagina delle pre-release di Github .
• I progetti/issue aperti e chiusi possono essere visti sulla bacheca Kanban  di Github.