Organisation du projet

Le projet est géré par le mainteneur, qui équilibre le développement et la maintenance du logiciel avec le reste d’une vie. Cela demande des stratégies de gestion de projet à faible surcoût, reposant sur des outils collaboratifs en ligne.

Départements

Développement logiciel

Le développement est réalisé sur Github ,

Les demandes de fonctionnalités ne sont pas prises auprès des utilisateurs à ce stade. Les utilisateurs sont consultés par le développeur sur leurs besoins quand un projet de (re)conception démarre. C’est pour éviter des interventions perturbatrices à des moments aléatoires, qui ne feraient que ralentir les projets ouverts. Les consultations vont au-delà des habitués du forum et du chat — par sondages quand l’enjeu le justifie — parce que les gens présents dans les espaces du projet sont un échantillon biaisé des gens qui utilisent l’outil, et que le silence n’est pas de la satisfaction : ceux qui sont partis ou ne sont jamais venus ont aussi des besoins, et ce sont précisément ceux que les canaux les plus bruyants ne portent jamais.

Le planning des questions en cours de traitement est disponible sur le tableau Kanban . Les développeurs peuvent choisir des questions dans la colonne À faire. Les nouvelles modifications à surveiller et tester se trouvent dans la colonne Terminé. Les requêtes pull qui ne respectent pas le protocole de design seront refusées.

Les développeurs qui ont besoin d’aide, d’une introduction à la base de code ou de revues de code peuvent demander sur le chat Matrix des développeurs  ou dans les Discussions GitHub  ; le mentorat est offert dans la limite des capacités du mainteneur.

Versions et stabilité

Une version stable est un ensemble fonctionnel achevé, pas une date : les versions sortent quand ce qu’elles promettent fonctionne, et les règles de triage définissent ce qui entre dans le prochain jalon mineur ou majeur. Deux conséquences. Pendant les chantiers de fondations — remplacer une bibliothèque centrale, retravailler une architecture —, le travail de fonctionnalités gèle jusqu’à la fin des fondations : bâtir sur un plancher pendant que quelqu’un en remplace les solives gâche le travail des deux. Et il n’y a pas de rush d’après-version : les bugs trouvés après une sortie entrent dans la file normale de triage, par ordre de priorité, au lieu de déclencher une précipitation qui crée elle-même des régressions. Les utilisateurs qui veulent aider à stabiliser une version testent la branche candidate en amont (validation), qui est sûre pour vos retouches, contrairement à dev.

Les nouvelles concernant les projets de développement clôturés ou les étapes importantes sont publiées sur le blog. Un chat Matrix dédié  centralise toutes les mises à jour et notifications des nouveaux commits, issues Github, nouveaux articles de blog et nouveaux messages du forum communautaire.

Compilations nocturnes

Des paquets installables pour Windows (.exe) et Linux (.AppImage) sont construits automatiquement sur Github vers 01:00 UTC, si de nouveaux commits ont été poussés la veille. Les liens de téléchargement direct sont publiés sur un chat Matrix dédié , vous permettant de voir les notifications apparaître et obtenir les nouvelles compilations, tout en un seul endroit.

Les compilations nocturnes sont destinées à promouvoir des tests précoces par des utilisateurs qui ne peuvent ou ne veulent pas les compiler eux-mêmes à partir du code source. Elles peuvent être instables.

Bugs

Les bugs (c’est-à-dire, les choses qui cassent le logiciel) sont traités sur Github  lorsqu’ils sont confirmés.

Ils peuvent être discutés dans les Discussions GitHub  ou les chats Matrix , en particulier pour confirmer qu’il s’agit bien de bugs (et pas de changements de conception).

Il est important d’ouvrir des issues sur Github pour les inclure dans la gestion de projet et les suivre depuis un seul endroit.

Site Internet

Le site est généré à l’aide de Hugo static website builder , qui est une manière assez légère d’écrire des sites techniques utilisant la syntaxe Markdown.

Le code source du site est sur Github . Vous pouvez corriger des fautes de frappe ou aider à traduire directement en éditant les fichiers source sur l’interface utilisateur de Github. Sinon, vous pouvez installer Hugo sur votre ordinateur, puis le fichier Readme sur Github explique comment construire un site de prévisualisation localement, en utilisant un serveur de test sur votre ordinateur, pour mieux prévisualiser (et déboguer) vos changements.

Les modifications apportées au site doivent utiliser le flux de travail typique de Git + Pull Request (sur Github), ce qui peut rebuter les non-programmeurs, mais c’est le moyen le moins mauvais de collaborer à distance sur quelque chose de textuel, tout en garantissant une version réversible et des sauvegardes.

Documentation

La documentation n’est pas incluse dans le dépôt du site pour des raisons de licence (GPL v3), elle est donc importée en tant que module externe Hugo. Le code source est sur Github , et tout le reste s’applique de la même manière que pour le site. Le Readme présente les shortcodes disponibles que vous pouvez utiliser pour formater le contenu, dans des fichiers Markdown.

Il y a cependant une mise en garde, si vous souhaitez construire la documentation localement, car elle importe le thème du site principal d’Ansel, donc le moyen le plus simple est en fait de construire le site principal tout en liant localement la documentation comme module. La procédure est détaillée dans le Readme du site principal.

La documentation subit actuellement des modifications structurelles, ainsi que des changements de design logiciel, donc n’hésitez pas à demander sur Matrix  si vous avez un projet particulier en tête, avant de vous engager sur quelque chose sur le point d’être supprimé.

Enseignement et formation des utilisateurs

Comme le montrent de nombreux rapports de « bugs », les utilisateurs insuffisamment formés ont des attentes erronées, et si vous prenez trop au sérieux leurs demandes de fonctionnalités, vous finissez par avoir un logiciel boiteux dupliquant des fonctionnalités et une charge CPU. Ceux-ci doivent être résolus à la racine : avec l’enseignement.

1. Les tutoriels vidéo sont publiés et indexés depuis la section chaînes de travail,
2. Les écrits pédagogiques longs vont sur le site web ou dans les Discussions GitHub ,
3. La documentation fournit l’information d’usage collée à l’interface du logiciel, pour apprendre les fonctionnalités dans l’ordre linéaire de leur apparition à l’écran.
4. La section chaînes de travail du site principal fournit l’information d’usage liée à une tâche précise à accomplir, pour apprendre « comment faire ».
5. La section ressources du site principal fournit l’information théorique de fond, pour bâtir une compréhension plus profonde de la couleur et de la photographie, et permettre aux utilisateurs de dépanner eux-mêmes leurs problèmes de retouche.

Gestion

C’est principalement une opération d’une seule personne, donc les choses doivent être efficaces et peu coûteuses. Cela nécessite une certaine discipline.

Gestion de la programmation

Il y a généralement 2 projets de programmation ouverts en même temps, qui sont choisis car indépendants l’un de l’autre. Cela permet de passer au projet n°2 en attendant les retours des utilisateurs sur les modifications apportées au n°1, de manière à toujours pouvoir identifier lequel a créé des régressions et des bugs. Pensez-y comme une focalisation alternée.

Au milieu d’un projet, le développeur ne traitera généralement pas, ne se préoccupera pas et n’écoutera pas les problèmes liés à autre chose que ce projet, car la puissance cérébrale est une ressource précieuse, plus vite dépensée que récupérée. En particulier, les demandes de fonctionnalités sur d’autres parties du logiciel seront ignorées.

La focalisation au jour le jour peut changer de manière inattendue, en fonction des problèmes découverts en réparant d’autres problèmes, grâce à l’héritage merdique de Darktable de code spaghetti semi-cassé et non modulable provoquant la folie, qui nécessite souvent des réécritures partielles ou complètes (dans tous les cas, nettoyage) avant de tenter de réparer quoi que ce soit (de manière à ne pas induire d’autres problèmes futurs, c’est-à-dire).

Communication

Nous vivons dans un monde où le volume d’informations et de communications est devenu écrasant et les humains n’ont pas la capacité de tout traiter. Les fils de discussion interminables et les conversations non régulées nuisent activement à la communication en diluant les informations importantes et en épuisant le lecteur. La discussion est uniquement destinée à arriver à une compréhension et à procéder à des décisions concrètes. Il y a un subtil compromis entre complétude et concision à trouver.

Pour les discussions ou les questions générales, veuillez utiliser l’espace Matrix . Mais même là, la concision est clé.

Dans les pull requests et les issues, sur Github, merci d’essayer de rester concis et centré :

• Les détails techniques (comme le système d’exploitation, l’utilisation d’OpenCL, la taille de l’écran, etc.) devraient utiliser des listes à puces.
• Les captures d’écran et les dessins peuvent beaucoup aider.
• Si vous répondez à un point ou une personne en particulier, citez la section de texte à laquelle vous répondez.
• Divisez votre texte en paragraphes d’environ 4 à 8 lignes, mais évitez d’envoyer chaque phrase dans un nouveau paragraphe.
• Gardez à l’esprit que tout le monde parle anglais mais très peu de gens sont des locuteurs natifs, donc essayez de vous en tenir au Globish .

De bons principes sur les interactions avec les issues/tickets peuvent être trouvés ici .

Mises à jour et notifications

De nombreuses façons centralisées et automatisées sont proposées pour suivre ce qui est nouveau dans le projet :

• Le site principal a un flux RSS central, où vont les pages nouvelles et mises à jour : RSS global,
• Pour plus de granularité, chaque section du site (News, Doc, Chaînes de travail, etc.) a aussi son propre flux RSS. L’icône que vous trouvez sur les pages d’index de section et sur chaque page pointe vers ce flux RSS dans la langue courante.
• Les changements de code se suivent depuis l’index des commits sur Github , ou via le flux Atom Github  (tronqué aux 20 commits les plus récents). Les messages de commit sont généralement assez détaillés pour expliquer ce qui a changé et pourquoi.
• Les nouveaux commits, les mises à jour d’issues Github (créées, éditées, fermées), les nouveaux billets communautaires et les nouvelles pages du site sont tous publiés sur un chat Matrix dédié .
• Les paquets des versions de développement sont publiés sur un chat Matrix dédié . Ils sont aussi listés sur la page de pré-version Github .
• Les projets et issues ouverts et fermés se consultent sur le tableau Kanban  Github.