Organisation du projet

Le projet est dirigé par Aurélien Pierre, qui s’efforce de jongler entre son travail de photographie (presque inexistant depuis 2019), le développement et la maintenance du logiciel, et la formation des utilisateurs lors de sessions d’entraînement individuelles. Cela requiert des stratégies de gestion de projet à faible coût indirect, s’appuyant sur des outils collaboratifs basés sur le cloud.

Départements

Développement logiciel

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

Les demandes de fonctionnalités ne sont pas acceptées des utilisateurs à ce moment. Les utilisateurs sont consultés par le développeur concernant leurs besoins lorsqu’un projet de (re)design est démarré. Cela vise à prévenir des intrusions perturbatrices à des moments aléatoires qui ralentiraient les projets en cours.

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 révisions de code peuvent prendre rendez-vous avec Aurélien Pierre  pour le faire par vidéoconférence (possiblement en utilisant Visual Studio Live Share ).

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 sur le forum communautaire ou les chats Matrix , surtout pour confirmer qu’il s’agit bien de bugs (et non de changements de design).

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. Le forum communautaire dispose d’un espace pour poster des liens vers des tutoriels vidéo,
2. Le forum communautaire a un espace pour que les utilisateurs écrivent des articles éducatifs de blog,
3. La documentation est destinée à fournir des informations d’utilisation étroitement liées à l’interface utilisateur du logiciel, de sorte que les utilisateurs puissent apprendre les fonctionnalités dans l’ordre linéaire d’apparition de l’interface utilisateur.
4. La section workflow du site principal est destinée à fournir des informations d’utilisation liées à une tâche spécifique à accomplir, afin que les utilisateurs puissent apprendre « comment faire ».
5. La section resources du site principal est destinée à fournir des informations théoriques de base pour aider à construire une compréhension plus approfondie de la couleur et de la photographie, et habiliter les utilisateurs à résoudre eux-mêmes les problèmes de retouche.
6. Les utilisateurs peuvent réserver des sessions d’entraînement individuelles  (cours) avec Aurélien Pierre, pour une formation plus rapide et plus ciblée.

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 demandes de pull et les issues, que ce soit sur Github ou sur le forum communautaire veuillez essayer de rester concis et direct :

• 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ù les nouvelles et les pages mises à jour vont : flux RSS global,
• Pour plus de granularité, chaque section du site web (Actualités, Doc, Flux de travail, etc.) a également son propre flux RSS. L’icône que vous trouvez sur les pages index des sections et sur chaque page renvoie à ce flux RSS dans la langue actuelle.
• Le site communautaire a également un flux RSS public central (réduit aux 25 événements les plus récents).
• Les modifications de code peuvent être suivies à partir de l’index des commits sur GitHub , ou à l’aide du flux Atom GitHub  (réduit aux 20 commits les plus récents). Les messages de commits sont généralement assez détaillés et devraient expliquer suffisamment bien ce qui a été changé et pourquoi.
• Les nouveaux commits, les mises à jour des issues GitHub (créées, éditées, fermées), les nouveaux messages communautaires et les nouvelles pages web sont tous postés sur un chat Matrix dédié .
• Les packages de builds nightly sont postés sur un chat Matrix dédié . Ils sont également listés sur la page de pré-version GitHub .
• Les projets/issues ouverts et fermés peuvent être vus sur le tableau Kanban GitHub .