Frankenstein nous guette.

• Est-ce qu’on implémente un chat sur le site ?
• Est-ce qu’on doit pouvoir créer un topic sur un forum sans passer par le forum, directement depuis un bouton placé sur la page d’accueil ?
• Est-ce qu’on veut pouvoir choisir entre la syntaxe Markdown et la syntaxe reStructuredText en rédigeant sur ZdS ?
• Faut-il retravailler la page d’accueil pour mieux y mettre en avant les contenus, ou plutôt faire une page d’accueil séparée “contenus” pour les mettre en valeur ?
• Quand un utilisateur non-connecté clique sur le lien “Dernière réponse : 12h33” sur le forum, doit-on renvoyer au premier message du sujet ou au dernier, sachant qu’on ne peut pas l’envoyer au dernier message qu’il a lu ?
• Quel est le plus important, pouvoir “@pinger” les membres sur les forums ou permettre d’insérer des sondages dans les posts ?

Ces questions ont un point commun : personne n’a la responsabilité d’en décider. Parfois il y a un vote sur le forum, parfois juste une discussion de 25 pages sans suite, parfois une proposition vient directement dans une Pull-Request et personne n’est habilité à décider que c’est une mauvaise suggestion pour ZdS. Dans la situation actuelle, c’est pas les devs qui manquent, c’est une vision produit. Et sans vision produit, chacun ajoute sa petite feature à la plateforme, et demain ce sera un patchwork difforme, incohérent, incompréhensible, inutilisable, et pas maintenable.

Je viens vers vous avec la double casquette de DTC embêté par cette situation et membre du CA avec le mandat de demander l’avis de la communauté sur la question suivante :

Êtes-vous d’accord que ZdS délègue les décisions produit à un ou une responsable produit, ci-après Product Owner.

On n’est pas fan des cahiers de charges hyper détaillés, c’est lourd et c’est pas utile dans une petite structure bien guidée par son CA et où la confiance règne, du coup évitons de perdre du temps avec ça et concentrons-nous sur la proposition dans les grandes lignes, et comment ce nouveau rôle cohabite avec le rôle existant de DTC :

• Le PO (Product Owner) a une vision globale de l'état actuel de la plateforme et de la direction qu'elle doit prendre à moyen terme :
  • Il priorise les évolutions et les nouvelles fonctionnalités.
  • Il a le droit de refuser ou d'accepter les features et de dire lesquelles sont préférablement les plus importantes / attendues (on ne peut rien imposer).
  • Il vaut mieux le consulter avant de faire une PR qui introduit une nouvelle fonctionnalité, ne serait-ce que pour savoir si on veut vraiment cette PR sur ZdS.
• Le DTC (Directeur Technique Cuelquechose) a une vision globale des aspects techniques de la plateforme :
  • Il priorise les bugfixes (quels bugs sont critiques, avec quels bugs on peut continuer à vivre encore quelques temps au besoin…) et les évolutions purement techniques (par exemple refactoriser un module, tout passer à Python 3, etc)
  • In fine il reste celui qui décide ce qui sort dans une release et ce qui sera plutôt à faire pour les suivantes.
  • Il est donc aussi responsable des mises en prod (logique : c'est lui qui décide si inclure tel ou tel truc dans une release est risqué ou non, donc il faut bien que ce soit lui qui prenne le risque pendant la MEP, et réciproquement).

Ces deux rôles se complètent, doivent collaborer et faire des concessions entre eux. Dans certains cas le PO pourra vouloir une feature qui aurait un impact trop négatif sur la technique, le DTC devra l'en dissuader. Dans d'autres, le DTC jugera qu'un bugfix est mineur alors que son impact sur le produit est très important pour le PO, qui devra alors convaincre le DTC de reprioriser le ticket en question.

Nous attendons votre avis sur cette proposition. Tous les membres du CA et tous les membres de l’équipe technique qui se sont exprimés sur cette proposition jusqu’à maintenant s’y sont montrés favorables, mais ZdS prend ses décisions en public d’où le présent message. Merci donc de vous exprimer si vous avez quelque chose de pertinent à ajouter à la discussion. Dans le cas contraire, vous pouvez -1 ce message si vous êtes contre, +1 si vous êtes pour, l’ignorer si vous vous en fichez, attendre quelques jours si vous n’avez pas encore d’avis.

Les attributions annexes viendront avec le temps. Par exemple, on peut raisonnablement s'attendre à ce que le PO rédige en partie les articles de release, décrivant brièvement les nouvelles fonctionnalités, ce qu'elles apportent, et à quoi s'attendre pour la release suivante.

Si cette proposition est acceptée, nous en discuterons ensuite les détails. Gardez vos idées au chaud, nous reviendrons vers vous. Il s'agira probablement de supprimer le poste de CdP au passage (personne n'en connait l'utilité) et de changer le système de ZEP (plusieurs pistes ont été envisagées).

Nous réglerons également la question du recrutement de la ou du PO. Le plus important là maintenant est un accord de principe, la situation actuelle ayant un trou béant qui se creuse au fur et à mesure qu'on ajoute des trucs à la plateforme.

CdP au passage (personne n'en connait l'utilité)

Si, moi.

Quand j'étais DTC (Directeur Technique Canidé, donc), il est arrivé un moment où j'en avais marre de toute la partie « gestion de l'humain » du poste. Eskimon est arrivé à ce moment là pour reprendre cette partie, il fallait trouver un titre pour montrer qu'on splittait l'ex-rôle de DTC en deux parties aux responsabilités distinctes, et le premier truc qui nous est passé par la tête est « Chef de Projet ». C'est tout.

Pourquoi donner à ce rôle un nom anglais alors que les autres ont un nom français, que vous avez manifestement un nom français sous le coude (responsable produit), et que le terme anglais porte à confusion (owner signifiant « propriétaire ») ?

Pas de raison particulière. Je pense que le truc important c'est que le site devienne pas un monstre absurde, pas le nom de celui ou celle qui y veillera, là maintenant.

et que le terme anglais porte à confusion (owner signifiant « propriétaire ») ?

C'est comme "avocat" pour désigner un rôle dans le domaine du droit. La plupart des gens confondent pas ça avec le fruit. Pareil pour Product Owner.

D'accord sur le principe (c'est jamais qu'ene personne possédant le droit de dire oui ou non, comme sur d'autres projets, et ça se passe en géréral), mais encore une fois, on évite soigneusement la question du "projet". Comme je le dis souvent, le problème ici, c'est que personne n'est exactement d'accord sur ce qu'est le "projet". Ce à quoi Victor m'as très justement répondu que justement, personne ne pouvant décider, personne ne peux savoir c'est quoi le projet, mais quand même !

Le PO, qui qu'il ou elle soit, aura donc "plein pouvoir" sur le devenir de la plateforme. Même si c'était pas aussi aigu, je me souviens que Spacefox avait déjà tranché sur certains points¹, dans la même optique, donc ça ne ferait qu'officialiser la chose. Fort bien, mais pour moi, il faut qu'il exprime ces intentions, a priori avant d'être élu (justement pour qu'on sache dans quelle direction ça va et "c'est quoi le projet"²), et à postériori quand il refusera des trucs (les exemples donnés ci-dessus se balayant difficilement d'un simple "non").

Bref, ce qui m'inquiète ici, c'est pas de remettre l'avenir technique de ZdS entre les mains d'une personne, c'est d'être sur que cette personne sais ce qu'elle veut, et qu'elle le veut pour les bonnes raisons. Donc la phrase "on va pas d'embêter avec un cahier des charges", elle m'ennuie un peu, particulièrement en tant que dev' : justement, j'aimerai savoir dans quel sens on va. Au moins dans les grandes lignes. Et qu'on arrête d'esquiver cette question du "c'est quoi, ZdS"³.

Je rejoins les discussions plus haut, par contre j'aimerai laisser un bémol sur celle-ci :

Il me parait important que le responsable produit ne décide pas tout seul dans son coin de ce qui est important pour la communauté. Dans ma vision des choses, le responsable produit peut dire "les tribunes libres sont très importante, concentrez vous dessus" ou encore "on s'en fou des caractères utf8mb4" parce que c'est celui qui maitrise les envies de la communauté. Il doit être celui là qui suit les suggestions de la communauté, qui pose des questions quand il y'a un doute, il se renseigne, mais en aucun cas il ne doit décider selon ses envies, mais toujours dans le sens de la communauté.

EDIT : d'après victor on aura le loisir de parler du rôle en détail, mais je tenais quand même a mentionner ça.

Ce que tu proposes, c'est un procès-verbaliste. Ce qu'il nous faut, c'est un responsable.

Il nous faut quelqu'un avec un peu de vision, et un peu de marge de manoeuvre. "Le client sait ce qu'il veut" et "Le client a toujours raison", ça fonctionne dans les magasins de chaussures, pas dans notre contexte. Si toute décision produit est prise à la majorité des gens qui se sont exprimés à son sujet, on l'aura notre patchwenstein. Un bon compromis est une décision qui ne satisfait personne, et si chaque décision est un bon compromis on donnera un coup de pelle à droite, un coup de pelle à gauche, jusqu'à être sur une île atrocement laide dont le seul moyen de s'échapper sera de flanquer zds-site à la poubelle et repartir de 0.

Il faut toujours écouter ce que le client (la communauté) a à dire. Et il faut pouvoir lui dire non quand on pense qu'il se plante. C'est ça, la bonne gouvernance d'un projet open source. C'est pas merger les features au gré des pouces verts sans se soucier de la cohérence du produit.

Attention, je ne parle pas de compromis ici (je n'en suis pas très fan de toute façon). Je ne suis pas en train de dire ici que le client à toujours raison.

Mon point de vue ici est de dire que le responsable produit, c'est celui qui sera capable de suivre les 12 pages de débats sur le site (quand il y a des sujets à débats), c'est celui qui suit toutes les suggestions qui sont proposées et a une bonne connaissance de ce que veut la communauté. Il n'est pas obligé de dire Amen à tout, mais justement parce qu'il est proche de la communauté et à une bonne vision de la communauté et une vision du produit, il sera à même d'accepter/refuser certaines choses en toute connaissance de cause.

Perso, je trouverai ça moyen que celui qui décide du sens dans lequel va zds "ait la flemme de suivre les débats du site" (pour prendre un exemple).

Je suis d'accord avec ton dernier message, très différent du précédent. Comme je l'ai dit, il doit être à l'écoute de la communauté. Par contre si, il doit justement être capable de décider tout seul dans son coin et pas toujours dans le sens de la communauté.

Je comprend bien que tu veux quelqu'un qui soit autorisé (dans le sens "pouvoir décision" et pas "pouvoir capacité") de prendre des décisions qui fâchent, parce que tu as peur de "ZEP-ifier"¹ le développement de la plateforme. C'est légitime, on voit bien que ça fonctionne pas des masses.

Pour autant, si un débat s'ammène, faut pas non plus que le PO arrive en disant "ah, nan, vos g***, flemme de lire vos débats, de toute façon j'ai déjà décidé". Il faut au moins qu'il écoute (lise, en fait), les arguments, quitte à prendre une décision qui va pas dans le sens commun à la fin, j'ai bien compris que ça te tenais à coeur, et je suis d'accord. Et du coup, oui, ça va rendre la fonction pas sympa, parce qu'il va falloir être à l'écoute de la communauté (ce qui, en encore une fois, ne veux pas dire répondre à ces moindres désirs, si c'est réfléchi). Si le but du jeu, c'est de court-circuiter les débats "parce que c'est chiant", c'est non.

Pour se protéger des court-circuits, ne pourrait-on pas, à l'instar des presses-agrumes, partager les responsabilités en plusieurs catégories (écriture de contenus, lecture, navigation, validation, forum…) ?

Non seulement ça éviterait qu'une seule personne décide de tout, mais ça permettrait aussi de partager la charge de travail. D'un autre côté, ça augmente le nombre de pistes de travail donc disperse un peu plus les forces de développement.

Un truc intéressant serait d’écrire (collaborativement) un document décrivant dans les grandes lignes l’orientation du site (je dis un truc idiot, mais du genre avoir un équilibre de contenu entre info, SHS et sciences, principe KISS dans le dev). Après le responsable produit pourra suivre dans cette optique (et éviter l’effet dictateur bienveillant). On peut même limite voter pour le responsable produit régulièrement historie d’apporter un semblant de démocratie.

je dis un truc idiot, mais du genre avoir un équilibre de contenu entre info, SHS et sciences, […]

Ça concerne uniquement le développement ici

D'un autre côté, ça augmente le nombre de pistes de travail donc disperse un peu plus les forces de développement.

Exactement. En plus il y a pas assez de personnes. Pour moi, une personne, ça suffit.

@pierre-24 : L'idée que le PO doit pas écouter la communauté ou pas lire les débats, c'est un fantasme, personne n'a dit quoi que ce soit dans ce sens. C'est pas une question de ZEP ou de court-circuiter le débat. C'est une question de cohérence. Même si le processus de ZEP était super, que chaque ZEP se soldait par 3 pages de débat où chaque post est constructif, et qu'ensuite chaque ZEP se prenait soit une unanimité positive soit une unanimité négative, le problème resterait, et la solution proposée ici resterait une réponse possible au problème qui nous préoccupe.

Peux-tu détailler comment tu vois ça, et comment ça peut contribuer à résoudre le problème ?

(↓↓ Une usine à patchwork, ça le ferait.)

Attention à ne pas remplacer un patchwork par une usine à gaz, je ne suis pas sûr qu'on y gagnerait au change

Je ne vois pas où il est question de court-circuiter les débats : le PO, tout comme les DT, sont mandatés par l'asso. Si vraiment il y avait un jour une dérive autoritaire, le conseil d'administration de l'asso aurait toute latitude pour agir.

Par ailleurs, le principe de nommer une personne pour cela (+ un suppléant), est précisément ce qui permet d'avoir une vision claire et cohérente sur l'avenir de la plateforme. Nommer un commité n'apporterait rien de plus par rapport à ce qu'on a aujourd'hui.

Plutôt que d'avoir une seule personne responsable de la direction du site tout entier, on aurait plusieurs responsables, chacun en charge d'une sous-partie du site seulement. Ces sous-parties resteraient à déterminer, mais pourraient être celles mentionnées dans mon message précédent.

Plus concrètement, chaque responsable déterminerait ce qu'il est important de développer pour dynamiser sa partie (par exemple, pour l'écriture, avoir un système pour faire facilement des retours sur un contenu ; pour la lecture, un système d'annotation des contenus, ou que sais-je d'autre). Puis les responsables décideraient (voteraient ?) entre eux quelles fonctionnalités prioritaires au niveau d'une sous-partie le sont au niveau du site (pour reprendre l'exemple précédent, est-il préférable de favoriser les relecteurs ou les lecteurs ?).

Le problème est que ça induit de la friction, alors que l'introduction de ce poste a justement pour objectif de la diminuer. En même temps, travailler en groupe (restreint) reste toujours plus stimulant.

Ouep. Comme d'hab', le mieux est probablement de tester un truc simple, avec un seul responsable produit, puis de faire évoluer le truc si nécessaire.

Sauf si ce comité est en nombre réduit ?

@pierre-24 : L'idée que le PO doit pas écouter la communauté ou pas lire les débats, c'est un fantasme, personne n'a dit quoi que ce soit dans ce sens. C'est pas une question de ZEP ou de court-circuiter le débat. C'est une question de cohérence. […]

et

… Parce que tout ce qui a causé ce débat, c'est entre autre le problème des "25 pages de discussions qui n'aboutissent à rien" (ce qui fait que les devs prennent la tangente et propose des POCs sans en référer à personne au préalable, d'ou la situation actuelle). J'avais donc peur qu'on parte sur "f*** les débats". Tant mieux si on est d'accord

Sauf si ce comité est en nombre réduit ?

2 ?

Si ces deux personnes se sentent capables de satisfaire les critères (temps, motivation, vision globale), ouais.

Avoir un nombre de PO >= à celui des devs risquent pas d'être plus efficace