Maintenance du site web de Duniter

Communication
1

Titre original : Nous sommes en guerre ! (sur le dépôt duniter_website_fr)

Bonjour,

Il y un truc qui me chagrine depuis un bout de temps : le délai de fusion des MR.

Je veux parler ici plus particulièrement du dépôt duniter_website_fr sur lequel je contribue depuis quelques mois.

Tout d’abord, notons que je n’accuse personne, déjà parce que mon prénom n’est pas Émile, et parce que d’après moi il n’y a pas de responsable, juste des processus qui peuvent être améliorés.

Donc voilà :

Les problèmes

Des infos démotivantes

Il y a sur le dépôt sus-cité 8 demandes de fusions dont certaines sont très vieilles.

En tant qu’être humain, voir ça ne me donne pas très envie de contribuer.

À quoi bon faire une proposition si on est sûr qu’elle ne sera pas acceptée, n’est-ce pas ?

Des boucles de rétroaction trop longues

Je ne sais pas pour vous mais, personnellement, pour rester motivé, j’ai vraiment besoin d’avoir l’impression que ce que je fais sert à quelque chose.

Des commits mergés 3 mois après la demande me frustrent énormément.

Alors, peut-être que c’est moi ? Après tout, je suis certes un gros branleur. Je suis dans le 3ème percentile en industriousness quand je passe le Big 5. Et au test du marshmallow, je n’aurais probablement pas attendu le deuxième.

Un processus conflictogène

Alors, je suis certes peut-être encore un peu newbie sur GitLab.

Ceci dit, si je consacre 4 semaines pour refondre un site web, que dois-je faire des branches autres que master et des MR qui sont toujours en pending depuis 3, 7 ou 12 mois ?

Mon intuition en voyant ça, ça a été “MR ignorée = MR refusée”.

Et, visiblement, cette intuition n’a pas été la bonne, et on m’a pris à parti.

Mais qu’aurais-je dû faire ?

Comment pouvais-je prendre en considération les modifications effectuées sur 7 branches différentes ? Comment savoir lesquelles de ces branches n’étaient pas pourries ou obsolètes ? Comment distinguer l’ivraie du bon grain ?

Et, autant être patient c’est compliqué pour moi, autant gérer des conflits avec d’autres êtres humains ça m’est insupportable.

On commence à être un peu nombreux sur ce projet, et on n’a malheureusement pas eu l’occasion de se prendre une grosse cuite tous ensemble. On commence à dépasser le seuil de convivialité, et ça va devenir, il me semble, compliqué de garder de bonnes relations avec des gens qu’on n’a pas rencontré IRL, surtout avec la froideur de l’écrit.

Il semble donc d’autant plus important d’avoir des processus fluides, moins susceptibles de générer ce genre de déconvenues.

Les solutions ?

Je ne sais pas exactement tout ce qui se passe en coulisse quand @Moul valide mes MR, donc je me sens mal placé pour les proposer.

Par ailleurs, je n’ai pas spécialement envie d’avoir plus de responsabilité que ce que j’ai déjà, mais s’il faut, je me débrouillerai pour monter en compétence (il suffira de me préciser ce que je dois savoir et j’irai chercher des tutos pour l’apprendre).

D’un autre côté, même si je savais gérer les aspects techniques de la validation de MR et de la CI/CD GitLab, je ne serais pas pour autant capable de valider des MR relatives à du contenu sur des pages techniques.

Ne serait-il pas possible qu’on soit davantage à avoir le statut Maintainer de sorte de pouvoir faire un truc similaire à ce @poka a mis en place sur le dépôt du site web de Cesium ?

Comme dirait Vladimir : “Que faire ?”

CC: @HugoTrentesaux, @Moul, @Paidge, @sveyret, @elois

8 Likes
2

On manque surtout d’un mainteneur compétent et ayant suffisamment de disponibilité.

Le projet duniter_website_fr est sans-tête, @Moul joue un peu ce rôle par défaut mais il est déjà bien trop pris par ailleurs.

En fait accueillir les contributions ça demande d’y consacrer du temps, si personne ne le fait alors les valeureux contributeurs comme toi se retrouve déçus car il n’y a personne en face pour accueillir leur contribution (ou avec un retour trop tardif).

Mon expérience sur Dunitrust m’a montré que c’est très chronophage d’accueillir les contributions, de reviewer les MR, de tester si ça fonctionne bien, de faire des retours aux contributeurs, etc
C’est pourtant indispensable si on veut éviter le bus factor, et c’est ce que je vais mettre en place sur Duniter, mais je doit d’abord baliser le chemin, documenter, structurer, etc

Faire cela correctement pour Duniter va déjà me demander quasiment tout mon temps, donc je ne peut pas le faire pour le site web, et je n’ai pas les compétences de toute façon, n’ayant personnellement jamais manipulé pelican.

Je pense qu’on a besoin que quelqu’un qui en ai vraiment envie prenne un peu le « leadership » sur les dépôt des sites web duniter_website_fr et duniter_website_en.

Et clairement il faut définir des process, des conventions, comme dans tout projet, sinon les uns passent leur temps à défaire le travail des autres.

3 Likes
3

Je ne pense pas que ce soit nécessaire ; on touche très rarement aux fichiers *.py (fichiers de configuration de Pelican).

4

Désolé pour avoir été celui qui « te prend à parti ». Devoir recommencer le travail que j’avais déjà fait ne m’a pas particulièrement enchanté et je ne voulais pas laisser passer sans rien dire. Ceci dit, tout comme toi visiblement, je n’aime pas les conflits, et si nous étions en face à face, et non à l’écrit, tu aurais pu constater que le ton que j’ai employé n’était pas agressif… :smile:

J’approuve totalement ton message, il faut essayer de trouver un meilleur processus. La MR que tu as vu a également son pendant dans la version anglaise du site, et n’est toujours pas fusionnée non plus depuis plusieurs mois. Cela fait que le mode d’emploi n’est plus à jour pour ceux qui tentent d’utiliser l’image Docker de Duniter.

Je comprends toutefois que ce ne soit pas forcément évident, car si beaucoup font comme moi, c’est-à-dire s’investir durant quelques semaines, puis ne plus donner signe de vie pendant des mois, il est difficile de les nommer Maintainer !

La solution pour le site serait peut-être de le transformer Wiki, que chacun peut mettre à jour, avec des possibilités de bloquer une page en cas de conflit, revenir en arrière en cas de vandalisme, etc.

6 Likes
5

S’il y a 12 maintainers et que chacun est là un mois de le l’année, si ça fait le taf alors on s’en fiche du titre, non ?

Ouais alors ça ça risque d’être un sacré boulot (qui veut le faire ?), et je ne suis pas convaincu que ça règle le problème :thinking: @ManUtopiK m’a parlé un peu de Wiki.js qui, d’après lui, est pas mal. À voir, c’est peut-être un truc à envisager.

1 Like
6

@anon88550267 @sveyret @Moul j’en ai déjà parlé ici mais j’insiste car ça me semble essentiel : Cycle de la documentation du projet Duniter : dans le dépôt git, sur le site web

Je préférerais que toute la doc technique soit dans le dossier doc du dépôt de Duniter, et que le wiki du site web aille piocher son contenu dans ce dépôt (sur la branche de production). Ainsi, quand une release est poussée en stable, ça mettrait automatiquement à jours la doc du site sans qu’on ait besoin d’y penser

2 Likes
7

Pour l’historique, Cédric a lancé les projets les projets des sites web Duniter, puis s’est concentré sur le logiciel Duniter. J’ai repris la main dessus au moment où on a eu des problèmes de spams XMPP qui mettait dans les choux les sites web à cause d’un problème de génération. Inso a migré les sites web sur un autre serveur et a géré leurs reproductibilités avec Ansible.

J’ai intégré tes changements Boris, car ils apportaient leurs lots d’améliorations au site web que je ne pouvais pas laisser mourir dans une MR. Je l’ai également fait pour t’intégrer dans le projet, car je sentais un potentiel contributeur. Cette migration m’a demandé une bonne tâche d’adminsys et de review que j’ai assuré et que je ne peux pas assurer tout le temps. Par la même occasion, j’ai laissé derrière la contribution de sveyret. Désolé pour ça, ça a créé un conflit git. La priorité pour moi a été la superbe contribution de Boris.

Je sais bien que toi Boris, a une contribution en attente qui demande une tâche d’adminys (de ma part). Je suis assez débordé. Je pourrais m’en occuper quand ça se calmera. Il me semble que c’était pas très critique. N’est-ce pas ? Personnellement, je ne souhaite pas m’occuper des sites web. C’est pas trop mon truc, et si je m’en occupe je ne fais plus de Silkaj ni de GitLab.

Donc oui, la situation sur ce dépôt est clair : Il n’y a pas de mainteneur. Il y a un poste à pourvoir. Je pense que les contributeurs de dépôt sont d’accord pour te l’accorder.
Et mon idée était que tu prennes la maintenance sur ce dépôt, si tu le souhaites. Maintenant que tu as fait tes preuves, tu pourrais contribuer, du moins sur la technique du site web et sur son contenu. Je sais bien que tu ne maîtrises pas tous les aspects techniques de l’environnement logiciel Duniter, mais tu pourrais prendre la maintenance malgré tout. Et moi, je pourrais m’occuper de temps à autre de la partie DevOps/AdminSys quand tu en as besoin, car tu n’as pas accès ssh au serveur. On pourrait même réitérer pour le site web en anglais.

Voilà, dis-nous si tu veux ce poste, et je propose de te passer mainteneur sur le groupe « websites ».

Après, tu vois les choses comme tu le veux. Tu peux arrêter à tout moment, tu peux merger que ce que tu maîtrises. Tu peux merger tes petits changements sans review. Tu peux toujours demander à un autre contributeur s’il peut review, au risque qu’il ne soit pas disponible et que tu décides de merger sans review malgré tout.

J’espère que mon propos a éclairci la situation et que tu sauras en faire bon usage dans la paix…

6 Likes
8

Et même si tu ne souhaite pas être mainteneur @anon88550267, je pense que c’est une bonne idée que tu est les droit pour merger tout seul quand tu sais que c’est un petit changement et que tu est sûr de toi.

je sais que tu vérifiera derrière si le site fonctionne toujours bien, et si quelque chose est cassé il est toujours possible de revert le merge depuis le gitlab afin de rétablir le site :slight_smile:

1 Like
9

Une publication automatique, mais plutôt sur un site de test, me paraît une bonne idée. Puis vers le site de production depuis une autre branche.

10

Ok, j’accepte les privilèges Maintainer.

Je ne suis pas convaincu que je vais pouvoir/vouloir continuer à m’intéresser à la ML sur le long terme, mais si je peux merger les quelques contributions pour lesquelles il me reste un peu de motivation c’est cool :slight_smile:

2 Likes
11

J’avais eu le même problème à l’époque où j’avais fait la version multilingue du site, et du coup, ça n’avait jamais abouti. Je ne me sens pas la force de contribuer sur quoi que ce soit en ce moment et jusqu’à ma thèse se finisse (par soutenance ou par abandon), par contre, je veux bien participer à la relecture des contributions sur les trucs pas trop technique comme les site web. Il faut juste que je trouve comment me mettre dans la boucle pour ne pas louper les MR et que j’ai les permissions.

2 Likes
12

Petite note pour le futur : il faudrait repenser la manière dont on communique en anglais. Je pense qu’on peut arrêter le site web duniter anglais (https://duniter.org/en/) et créer un wiki en anglais digne de ce nom pour duniter (https://git.duniter.org/nodes/typescript/duniter/-/wikis/). Ce wiki servira de « ground truth » pour tout site qui voudra donner des informations techniques comme le site duniter.org par exemple.

Dit autrement, la responsabilité de l’équipe de développeurs est de maintenir le wiki duniter. Maintenir le site duniter francophone (ou n’importe quel autre site qui voudrait présenter duniter dans une autre langue) relève d’une autre responsabilité.

Je veux bien me coller à cette tâche plus tard si vous êtes d’accord avec cette manière de faire.

Note à moi même (TODO) :

  • reprendre ce qu’il y a de bien dans le wiki actuel
  • reprendre ce qu’il y a de bien dans le site duniter en anglais
  • annoncer sur le site duniter francophone que les informations techniques les plus à jour sont disponible en anglais sur le wiki duniter
3 Likes
13

Ok, donc j’aimerais savoir qui sont en ce moment les interlocuteurs privilégiés pour

S’il n’y en a pas, je veux bien le devenir.

14

Je note mes pensées ici au fur et à mesure pour en garder une trace et réorganiser.

  • @elois a déjà beaucoup de boulot avec duniter et préfère écrire la documentation technique dans le même dépôt : https://git.duniter.org/nodes/typescript/duniter/-/tree/dev/doc
  • l’ancien wiki contenait en multilingue en/fr
    • un dictionnaire du vocabulaire du projet duniter (identity/membership/node)…
    • une sorte de FAQ
    • une ébauche d’explication de l’architecture
    • un guide pour rejoindre la communauté
  • la documentation présente dans /doc comporte
    • liens vers la RFC
    • description de l’API HTTP (BMA)
    • instructions de compilation manuelle et d’install docker
    • un guide basique des commandes en CLI
    • doc développeur comme
      • installation de l’environnement de développement
      • conventions git du projet
      • architecture des dossiers
  • le site duniter français contient
    • les bases de la monnaie libre
    • les bases de la ğ1
    • la base de la wot
    • une page annuaire « contribuer » qui lie vers les logiciels et des tas de liens
    • une page « forger des blocs » qui contient ce qu’était le wiki précédent mais pas à jour
    • un fil d’actualités qu’on ne met pas à jour
  • le site duniter anglais contient
    • les mêmes pages de wiki plus tout à fait à jour
    • l’ancien design du site

Je pense les choses suivantes :

  1. il est important de conserver des informations à jour pour ce qui touche à l’installation de duniter et à la documentation développeur. des informations dépassées nuisent à la compréhension et à l’adoption du projet
  2. il faut éviter de multiplier les sources d’information car cela rend les choses plus difficiles à maintenir à jour
  3. nous n’avons pas les ressources humaines ni une méthodologie adaptée pour la gestion de contenu multilingue évolutif
  4. la fonctionnalité « wiki » de GitLab ne permet pas de gérer le dépôt comme un dépôt normal, cad contributions, fork… il faut donc éviter d’avoir à y apporter trop de modifications
  5. il est important d’être clair sur la distinction monnaie libre / duniter / monnaie ğ1 / écosystème logiciel pour la ğ1

C’est pourquoi je propose ce qui suit :

  1. garder la documentation technique dans le dépôt duniter uniquement en anglais (y compris compilation manuelle par exemple)
  2. utiliser le wiki uniquement comme page de garde pour rediriger vers les ressources adéquates (doc développeur, site duniter en/fr)
  3. retirer tout ce qui est susceptible d’être modifié par la suite de la version anglaise du site duniter (actualités, informations liées à une version particulière du logiciel). viser une fréquence de mise à jour de ce site de 1/an maximum (j’ai les droits sur le dépôt, je vais le faire si vous êtes d’accord)
  4. mettre à jour le site duniter francophone et avoir une personne en charge de le mettre à jour dès qu’une modification est nécessaire (information importante à mettre dans les actualités, modification des instructions). je me propose pour cette tâche, j’ai déjà les droits sur le dépôt, je vais le faire dans la semaine prochaine unilatéralement à moins que quelqu’un ne s’y oppose ici.

Voilà, désolé de mettre tout ce que je pense, mais si vous n’avez pas envie de lire et que vous me faîtes confiance, laissez un :+1:, ça me permet d’avoir une forme d’approbation. @elois j’ai besoin des droits sur le dépôt duniter pour éditer la doc et le wiki, @cgeek, @anon88550267, @moul, @galuel, @kimamila , n’hésitez pas à vous exprimer aussi.

3 Likes
15

Je ne sais pas ce que tu nommes “le wiki de duniter”, ou alors tu parles de celui sur le site web, mais du coup bah c’est le site web.

Nous n’avons plus de référent sur les sites web aujourd’hui, @Moul gère ça par défaut.

Il faut surtout ne pas l’utiliser. Comme dit précédemment, on ne s’en servait que comme page de release, maintenant ça n’a plus de sens de s’en servir. Et comme tu le dis toi-même, il ne faut pas démultiplier les supports, donc je pense qu’il faut oublier la fonctionnalité wiki du gitlab,on n’en a pas besoin.

Pourquoi “uniquement en anglais” ? Non la documentation technique directement dans le dépôt je la rédige aussi en français, car je suis plus précis dans cette langue et que la plupart des contributeurs son francophone.

Pour la doc pas besoin, tu peux faire une MR. Et pour le “wiki” il n’y en a jamais eu sur le gitlab, je ne vois pas pourquoi on en créera un alors qu’on parle justement de ne pas s’éparpiller.

Je préfère le fonctionnement suivant :

  • Je maintiens la doc technique dans le dépôt.
  • On doit trouver quelqu’un pour maintenir le contenu des sites web.
1 Like
16

C’est d’ailleurs ce que tu devrait faire même si tu avait les droits sur le dépôt. Il ne faut jamais commiter directement sur la branche dev, il faut toujours faire une MR, y compris pour la doc.

1 Like
17

Permettez-moi de râler un peu en public, ça défoule. Ça m’énerve d’arriver sur un site qui a subi tellement de modifications qu’il est impossible à maintenir. La doc est dégueu et les dépendances moches. Il y a de la duplication de code et l’outil pélican a été mal utilisé. Je vais avoir encore une fois pas mal de boulot. Je pense de plus en plus sérieusement à remettre ça à plat en reprenant de zéro.

@elois, oui, je vois que tu as supprimé le wiki Gitlab de duniter. Je pensais mettre une page de garde pour rediriger, mais ça va aussi si on ne met rien. C’est sur ce dépôt que je voulais les droits pour force push les modifications. J’ai commencé un fork de la doc de duniter qu’on peut voir ici : doc · dev · Hugo Trentesaux / duniter · GitLab je ferai une MR quand je serai prêt.

Je vais le faire, c’est pour ça que je me dis que remettre à plat peut m’économiser des efforts par la suite.

…

Bon, après pas mal de temps à observer le site, je l’ai trouvé dans un état encore pire que quand j’avais fait le travail pour fusionner le site anglais et français. Je ne suis donc prêt à le maintenir que si je le reprends de zéro (tout en récupérant les contenus et designs). Si je fais ça il se pose quelques questions.

Le site est devenu un sorte de mélange entre

  • le site du logiciel duniter
  • un site sur la monnaie libre
  • un site sur la TRM
  • un site annuaire sur l’écosystème de la ğ1

Je pense que c’est trop d’ambition pour un site maintenu par une ou zéro personne. Il est donc temps de rassembler un peu les efforts qui ont été dispersés dans :

Plutôt que chaque site cherche à re-expliquer les concepts expliqués à d’autres endroits.

18

Je continue mon petit brainstorming tout seul.

publics visés

  1. grand public, qui ne connaît rien à la monnaie libre, la ǧ1, la trm, la blockchain, duniter
  2. public avec de vagues notions mais qui souhaite se renseigner un peu plus
  3. membre de la ğ1 ou futur membre qui souhaite approfondir sa connaissance du sujet
  4. utilisateur avancé qui cherche des informations pour maintenir son nœud duniter
  5. développeurs ou profils techniques qui cherchent à obtenir des informations précises

Chaque tranche de public est prête à investir un peu plus d’effort dans ses recherches, mais il faut que chacun sache où trouver les informations dont il a besoin.

Pour l’instant, aucun site n’identifie clairement son public, la base est du grand public, et c’est pour ça qu’on se retrouve avec la même information à quinze endroits différents mais mal dite.

Pour moi, le site duniter.org ne doit s’adresser qu’aux profils 3 et plus. Les profils 2 et moins devront plutôt être orientés vers monnaie-libre.fr. Partant de là, on peut complètement ré-organiser les deux sites pour sortir de cette bouillie vaseuse.

thèmes

  • la ğ1, une monnaie éthique fondée sur la confiance
  • la monnaie libre, une théorie monétaire relativiste, un référentiel de valeur
  • duniter, un logiciel qui fait fonctionner la monnaie libre ğ1
  • l’écosystème logiciel autour de duniter (wotwizard…)
  • les logiciels pour l’utilisateur de la ǧ1 (clients, places de marché)
  • la communauté de la ǧ1 (forums, sites locaux, discussions)

Tout site qui essaye de viser tous les publics et d’aborder tous les thèmes nécessite un travail monstrueux, largement hors de portée d’une personne unique. Donc soit on veut le faire quand même et on arrive à réunir cinq personnes sur le même projet et dans la durée pour avoir un ensemble cohérent, soit on découpe.

Là, je suis plutôt parti pour découper. Les sites des groupes locaux ont déjà fait un énorme travail de vulgarisation et je pense qu’ils couvrent assez bien le public 1 et réoriente correctement le public 2 vers les sources existante. Notre responsabilité est donc de faire un site pour les publics 3 et 4, ce qui est plus facile.

5 Likes
19

Totalement d’accord avec ça. Perso je ne redirige jamais un humain lambda vers duniter.org, mais je dirige les gens vers monnaie-libre.fr, qui redirige déjà les visiteurs en quête d’informations plus techniques vers duniter.org.

1 Like
20

De même, un utilisateur qui cherche plus d’informations sera gêné par le nouveau look du site duniter.org qui rend plus difficile de trouver les informations. Je ne m’étais pas rendu compte de ça.