Nous sommes en guerre ! (sur le dépôt duniter_website_fr) | Maintenance du site web de Duniter

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

6 J'aimes

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.

2 J'aimes

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

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.

3 J'aimes

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 J'aime

@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

1 J'aime

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…

4 J'aimes

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 J'aime

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.

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 J'aimes

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 J'aimes