Un Zest'Meeting

On peut aborder le sujet des incohérences entre User et Profile ?

On avait dit qu'on le resortirait à la fin du développement de la ZEP-12 …

Hugo : C'est inclut dans le point sur l'API.

Edit : Après réflexion, il serait plus pertinent d'aborder le bug de User/Profile et pas l'API des forums.

Sans plus attendre et au vu du consensus rare et unanime qui se dégage du framadate (première fois je crois !), le ZM aura lieu jeudi 1^er octobre à 20h !

Je me demandais si on ne devrait pas parler de la manière de prendre de décision rapidement sur ZdS. L'objectif n'est bien sûr pas de bâcler la partie réflexion mais de passer rapidement à la l'acte une fois qu'elle est terminée.

Par exemple, combien de temps cela aurait-il pris de renommer la Bêta zone si on s'était contenté d'une suggestion dans le forum B&S et non d'un débat houleux dans le Bar ?

J'ignore si ça vaut le coût d'être abordé (s'il y a effectivement un problème et, le cas échéant, s'il y a une solution).

Pour moi, y'a un souci à ce niveau là. Je ne suis pas sur que ça soit le moment, ni les bonnes personnes et ni l'endroit.

Ce n'est pas sujet à aborder sur un coin table avec un groupe restreint de personne. Après, on peut en parler ensemble, pour avoir une politique commune mais je doute qu'on arrive tous à se mettre d'accord car on n'a pas tous la même vision des choses. Mais je peux me tromper (je l'espère !).

A mon avis ça ne relève pas de la technique, c'est purement process tout ça et ne concerne pas (trop) les dev'

Et pourtant. Dans les faits, des points "idiots" comme désanonymiser les pouces rouges/verts sont bloqués à cause du fait que le sujet à généré un débat tellement sanglant et que plus personne n'as envie de s'y coller. J'ai d'autres exemples en tête (la ZEP-04 pour ne pas la citer), mais l'idée est là : notre process est hyper-lourd, et il faut des nerfs d'acier en temps que dev' pour y résister.

et il faut des nerfs d'acier en temps que dev' pour y résister.

Imagine un peu le petit débutant (pas nécessairement en dev, seulement en projets open source) qui souhaite contribuer au dev…

A mon avis ça ne relève pas de la technique, c'est purement process tout ça et ne concerne pas (trop) les dev'

Il est vrai que c'est du process, mais ça concerne les dev. Par contre, et je pense que c'est ce que tu as voulu dire, ce n'est peut-être pas à eux d'en discuter directement. On pourrait alors envisager d'organiser d'autres types de Zest'Meetings, à l'image de celui qui se déroule au niveau du staff. La question est : qui gère le process ? Le CdP et le DTC ?

Honnêtement pour le coup je pense que c'est un mauvais exemple. Il y a un an, la décisions le supprimer cet anonymat a été prise sans gros problème, et pourtant personne ne s'est bougé pour le faire. Probablement parce qu'en réalité, tout le monde s'en cogne de cette fonctionnalité, en particulier chez les développeurs.

Quant à la lourdeur, c'est aussi un problème d'avoir dit « la communauté décide et l'association ne fout rien tant qu'elle n'est pas obligée d'agir ». C'est intrinsèquement lourd puisque personne ne prends de décisions, en fait. Wikipédia, à bien plus grande échelle, a exactement le même problème (et d'autres encore).> > et il faut des nerfs d'acier en temps que dev' pour y résister.

Tout dépend de ce que veut toucher le débutant. On a des dizaines de tickets assez simples et pas du tout sujets à débat. Et il faut se rappeler que Zeste de Savoir est un gros projet techniquement.

Cela dit, j'ai vraiment l'impression qu'on se trompe de débat et a tendance à inverses causes et conséquences. Le renommage du forum bêta, pour revenir à l'exemple d'origine, n'a pas posé problème, il s'est juste retrouvé dans un débat infiniment plus large. Une suggestion sur le forum aurait sans doute été acceptée très rapidement.

Et il faut se rappeler que Zeste de Savoir est un gros projet techniquement.

Justement, peut-on se permettre de procéder de la manière « la communauté décide et l'association ne fout rien tant qu'elle n'est pas obligée d'agir » ? C'est une vraie question hein : je ne dis pas qu'il faut changer, vu que je n'ai aucune expérience en la matière.

Je millessoie toute demarche qui vise a dés-alourdir les process de dev.

Le like ne suffisait pas.

Ça, c'est une question à voir avec l'association, pas pendant un zest'meeting.

Tu peux détailler que que tu trouves lourd dans ce process ? En l'état, c'est vachement vague et ne permet pas d'y réfléchir avant la réunion.

Bon, je vais parler pour moi, et dire à peu près ce que j'ai dit sur IRC précédemment :

ZdS est un projet génial, ou il y a plein de possibilité de faire du "chouette" code et de développer des choses qu'on ne pourrait pas faire ailleurs. Du coup, perso, je me suis 10 000x plus amusé à coder la ZEP-12 qu'à faire du bugfix, et ne me faite pas dire ce que je n'ai pas dit, le bugfix est important, nécessaire et j'en ai déjà fait (là, normalement, je prend une pluie de pouces rouges).

Le problème, c'est qu'à l'heure actuelle, pour implémenter des nouvelles fonctionnalités (donc pas du bugfix), il faut passer par notre processus de ZEP, ce qui est bien entendu intéressant, mais pose d'énorme problème. Puisque je vais parler de ce que je connais, je vais prendre l'exemple de la ZEP-12 : j'ai l'impression que certaines décisions ont été prises à l'usure, ce qui n'as rien d'efficace. Le processus de spécification de la ZEP-12 a duré 6 mois (!), j'ai eu le courage de le faire une fois, est ce que je le referait une deuxième fois ? Le carnage (en terme de nombre de pages de topics "inutiles") qu'a été la ZEP-04 est-il à chaque fois nécessaire ?

Autrement dit, pour faire passer une décision, il faut maintenant s'investir à 400% dans une discussion qui n'as parfaitement rien à voir avec le dev's et qui est plus pénible qu'autre chose (les discussions virant souvent à des considérations étrangères à ladite ZEP ou pire, à des attaques sur personnes). Ça n'as rien de drôle, et je pense pas que ça doit être drôle pour les membres qui tente de s'y investir non plus : si une ZEP tourne en bataille tranchée de 10 pages ou plus personne n'as rien à dire au bout de trois et commence à répéter ce qui a été dis, ça sert à rien, c'est pas productif et ça donne pas envie d'avancer. Et dire "Wikipédia a exactement le même problème", même si c'est vrai, ça sert pas à grand chose : nous ne sommes pas Wikipédia, ni en terme de nombre, ni en terme de ressources.

Ajoutons à ça le fait qu'une ZEP ne fonctionne que si il y a un dev' pour l'implémenter derrière (toutes nos ZEPs finalisées en sont l'exemple), je me dis qu'on ne raisonne probablement pas de la bonne manière. Si la méthode ne marche pas, je pense qu'on a un an de dev' derrière nous pour se poser et y réfléchir, maintenant, avant que chaque ajout de fonctionnalité ne finisse en débat pour la survie du site et ces idéaux.

Les choses que je trouve lourdes :

• Les ZEP : comme l'a bien expliqué pierre_24, quand on en a fait une, on a plus envie de recommencer. Pour moi ce type de process doit etre réservé soit aux entreprises, soit aux communauté axées sur la technique avec des contributeurs essentiellement techniques. Mais j'ai bien l'impression que ça ne fonctionne pas chez nous.
• La QA :
  • devoir installer un environnement de dev chez soit pour faire de la QA, demande une motivation particulière. ce qui rend lourd le process.
  • l'absence de test d'integration oblige tout le temps a QA les memes fonctionnalités. C'est rebarbatif et n'aide pas à se motiver pour une tache qui est déja pas drole.
• Le deploiement : on s'est amelioré depuis que npm n'intervient plus en prod, mais là aussi on a encore trop de truc fait par un humain. Dans un monde meilleur, declencher une release devrait se faire via son navigateur (sans se connecter en ssh) en cliquant sur un bouton après avoir modifié 2-3 parametres. Le retour arrière devrait etre lui aussi en un clic.

Voilà mon ressenti après tout ce temps sur le dev'.

Les ZEP : comme l'a bien expliqué pierre_24, quand on en a fait une, on a plus envie de recommencer. Pour moi ce type de process doit etre réservé soit aux entreprises, soit aux communauté axées sur la technique avec des contributeurs essentiellement techniques. Mais j'ai bien l'impression que ça ne fonctionne pas chez nous.

J'ai le sentiment inverse. Notamment car… une zep n'a pas à être technique dans sa rédaction initiale.

l'absence de test d'integration oblige tout le temps a QA les memes fonctionnalités. C'est rebarbatif et n'aide pas à se motiver pour une tache qui est déja pas drole.

Je vais peut être mais c'est long à coder (c'est mon taf actuel) et le nombre d'erreurs produits à la minute dans ces tests est très élevé.

Pour le déploiement, il me semble que deux pistes plus ou moins anciennes ont été avancées : puppet et docker. Faut voir ce qui est le plus réaliste.

La remarque sur Wikipédia était là pour illustrer le fait que même avec leur force de frappe, ils n'avaient pas trouvé de moyen apaisé de gérer cette « ultra-démocratie ».

La solutions est sans doute hélas de réduire la participation directe de la communauté. Par exemple :

1. N'importe qui peut écrire et commenter des ZEP (comme aujourd'hui).
2. À partir du moment où on s'intéresse de près à sa réalisation et donc que quelqu'un prends le développement en main, ce développeur devient responsable de la ZEP. Ce qui implique :
   • Qu'il tranche les décisions techniques en accord avec l'association (représentée par le DTC)
   • Qu'ils n'est en rien obligé de prendre en compte tous les désirs de la communauté

On aurait donc un cycle de la forme :

1. Étude avec la communauté, on laisse les débats débattre
2. L'association et les développeurs de la fonctionnalité figent la ZEP
3. Développement par le développeur, et là la communauté ne peut plus intervenir en profondeur

Cela dit, c'est un problème d'organisation, pas de zest meeting.

Concernant les remarques de firm1 :

1. Cf ci-dessus.
2. Je suis d'accord. Je pense que tout le monde est d'accord. J'avais vu des grandes déclarations sur ce qu'on peut faire pour corriger ces problèmes, mais rien n'a passé le stade du prototype. La, y'a pas de débat, il « suffit » de s'y coller… il faut « juste » trouver quelqu'un avec les compétences, le temps et l'envie. Comme d'hab quoi.
3. En ce qui concerne la prod, c'est un faux problème. Aujourd'hui, déployer en prod (hors actions spécifiques à une version donnée), c'est une connexion en SSH suivie une ligne de commande : ./update_and_deploy.sh <nom du tag>. Point. Le process que tu décris peut être intéressant dans une entreprise qui déploie tous les jours, mais dans notre cas il n'a aucune valeur ajoutée. Et très honnêtement, j'ai beaucoup de mal à comprendre pourquoi autant de personnes non concernées par le déploiement en (pré)prod font tout un foin pour « améliorer » une procédure qui fonctionne sans souci. Là pour moi on est exactement dans le genre de prise de tête inutile qu'on décrit par ailleurs sur les ZEP.

Concernant le déroulement des ZEP que tu proposes, je ne comprends pas en quoi il diffère de ce qu'on a actuellement. Il me semble que le premier point correspond à l'étape En rédaction, le second à celle En validation et le dernier à la phase Active. Non ?

Cela dit, c'est un problème d'organisation, pas de zest meeting.

On crée un autre sujet du coup ?

Juste pour rebondir si jamais ça peut être utile.

Je suis d'accord avec firm1 en ce qui concerne 2 points, pas les autres.

Je pense que des tests d'intégration automatisés feraient beaucoup de bien à ZdS. Pour plusieurs raisons :

1. ça permettrait à des gens de rejoindre le projet en douceur. N'importe quel langage permet de coder ce genre de tests pour peu qu'on dispose d'un ChromeDriver ou autre (selenium, cucumber et tous leurs copains). On pourrait même imaginer choisir une techno différente de la stack actuelle, et ça serait pas plus bête, ça ferait une bonne excuse aux devs pour qu'ils ne s'en occupent pas, et amènerait de nouvelles têtes à s'intégrer dans le projet

2. ça permet aux développeurs de coder le cœur léger. Ça peut paraître trivial et un peu bête, mais d'expérience c'est vrai, et ça fonctionne bien. Je l'ai vécu sur plusieurs projet, le gain en termes de temps de développement est loin d'être négligeable, même si au début on a l'impression que c'est long, rébarbatif, comme l'a souligné artragis. Le gain est réel. Et je peux vous garantir que c'est un confort dont on a du mal à se passer.

3. ça soulage incroyablement la QA, qui a, du coup, l'impression de faire des trucs utiles et pas de repasser sans arrêt le même plan de test. Ce qui, généralement, produit des effets catastrophiques : lassitude de l'équipe de QA qui passe les tests à fond la caisse parce qu'on veut pas retarder la MEP => on en oublie. Et encore, ça c'est dans le contexte pro, dans le contexte bénévole, ça revient juste à "ça sera sans moi". On a beau dire, c'est humain.

Franchement, des tests autos apporteraient certainement une bouffée d'air à ZdS.

Second point sur lequel je rejoins firm1 : le déploiement, quasiment pour les mêmes raisons : la sérénité, et du coup passer plus de temps sur des trucs sympas et plus importants. Ne connaissant pas la stack, délicat de juger. Mais il semblait qu'aux dernières nouvelles çça allait mieux (si SpaceFox peut confirmer).

Là où je serais moins catégorique, c'est pour les ZEP. Je pense que c'est un bon principe et qu'il devrait rester, l'idée étant justement de spécifier proprement (et de façon collaborative) pour que les devs n'aient pas à se poser les questions qu'on se pose sans arrêt ("Mais ça fait quoi quand je clique là ??" ou "C'est bien joli mais ça me dit pas ce qu'il faut faire dans tel cas merdique"). En cela, je trouve que les ZEP remplissent leur rôle.

Par contre, j'ai l'impression que les ZEP qui ont avancé le plus et le plus vite sont les ZEP où les seules ambiguïtés étaient techniques, on a discuté, débattu, on n'était pas toujours d'accord, mais au final soit il y avait de la littérature pour nous "départager", soit on a choisi un compromis acceptable, soit qqn a baissé son bouclier en se disant qu'au final ce n'était pas très important.

Pour les ZEP plus orientées fonctionnelles, j'ai l'impression que le problème n'est pas tant dans le concept de ZEP mais bien plus dans le comportement des gens qui participent, qui oublient parfois (souvent) que le but du jeu c'est d'aider les développeurs, de spécifier, débloquer, et avancer/itérer rapidement histoire que le(s) développeur(s) puisse(nt) avoir matière à avancer. Et c'est vraiment essentiel. On l'a vu sur les tags, la catégorisation des contenus, et plein d'autres.

Les specs partent totalement en fantasme fonctionnel (en sucette, quoi). Et c'est par excellence le truc qui donne l'impression que le process' est lourd, qu'on n'avance pas, … Dans un projet comme celui-ci, avec des bénévoles passionnés, plein de fonctionnalités avancées etc. Il faut vraiment faire gaffe à ça. Donc plutôt que de jeter les ZEP à la poubelle, peut-être vaudrait-il mieux faire attention aux interventions des gens dans les ZEPs, et éviter les débordements du style "je campe sur mes positions" ou "puisque c'est comme ça je boude" ou "je pinaille pour le plaisir" ou encore "attendez j'ai une idée formidable" et garder vraiment vraiment à l'esprit qu'il faut avancer petit à petit, mais vite.

Les specs partent totalement en fantasme fonctionnel (en sucette, quoi).

Je ne comprends pas trop ce que tu veux dire par là. Aurais-tu des exemples ?

Aurais-tu également des solutions pour pallier cela ?

Il faut que je réfléchisse plus à la question pour développer l'idée, mais le problème vient de notre fonctionnement communautaire, du fait que tout le monde a son mot à dire. Peut-être pourrait-on envisager créer des groupes de travail, avec de restreindre le nombre de participants et de ne demander son avis à la communauté que fois qu'on a un truc abouti ?

Je confirme à 100%.

C'est ça que je trouve assez dingue en fait : que plusieurs personnes remettent en cause le déploiement actuel alors qu'il est serein et qu'on ne perds plus de temps avec depuis plusieurs mois. Il y a des tas de trucs à améliorer sur notre infrastructure et qui sont des sujets potentiels d'inquiétude, mais le déploiement en lui-même est très loin au fond de cette liste d'amélioration.

Et je plusseoie complètement Javier sur son analyse des ZEP.