Après avoir relu ce fil de discussion de bout en bout j’aimerais coucher mes réflexions ici (dodo).
Disclaimer
Déjà, points importants à prendre en considération:
- je suis nouveau donc pas mal de trucs doivent m’échapper
- ce que je dis a probablement été dit ailleurs mais j’ai pas trouvé (pas encore épluché tout le wiki)
- éléments influençant mon point de vue:
- ma formation (master en cours en sécurité informatique)
- mon expérience avec une organisation essayant d’aller vers plus de transparence: une communauté d’agglo donc pas forcément adapté ici.
Selon moi il y a plusieurs “courants”, la transparence et l’ouverture ne sont pas des états en soit mais des cheminements qui doivent être effectués d’une manière constante. Ce sont des démarches difficiles car de l’extérieur même quand tous les efforts sont faits si la communication n’est pas suffisante/adaptée il peut sembler à un observateur que l’organisation a des trucs à cacher. Dans ces deux démarches il y a deux éléments bien différents qu’il faut séparer dès le design pour avoir un tout cohérent:
- transparence des processus
- transparence des états internes
Deux analogies qui pourraient aider: si je dessine un automate et que je ne documente que les transitions entre les états je donne la transparence des processus (le résultat sera pas très compréhensible vu qu’on ne sait pas quels sont les états)
si je dessine que la description des états je donne la transparence des états internes (on peut vaguement déduire une partie des conditions nécessaires au transitions, pas super non plus)
Pour un non informaticien si j’explique “pour arriver à telle décision on a effectué un vote dont voila la procédure et le résultat” transparence des processus. Si je dis juste “après telles discussions dont voila les transcriptions on a voté pour ça” transparence des états, on sait pas quel groupe a voté, comment, entre quoi et quoi. ça peut sembler pas très important comme différence mais selon moi il faut faire le distingo.
Qu’est ce qui se passe si les gens ne sont pas au courant des API ou de la localisation des services qui contiennent les données: ça ressemble à un manque de transparence.
Qu’est ce qui se passe si les gens ne sont pas au courant d’une démarche de migration de services (ayant pour but ou non plus de transparence) et en voient juste les effets (fermeture des services auxquels ils sont habitués) ça ressemble à une opération de verrouillage.
transparence des processus
Une organisation doit définir un but à atteindre en terme de transparence, même si les membres savent que les efforts pour s’en rapprocher amèneront à une asymptote. C’est pas grave, c’est normal, dans le cas contraire l’organisation est figée dans l’espace et dans le temps et il s’agit juste de faire de l’accessibilité sans production de nouvelles données.
Ici ce qui me semble désirable avant tout c’est une transparence des processus complète (comment sont proposées les décisions, qu’est ce qui se passe si on est extérieur à un bureau et qu’on veux faire une proposition qui sera discutée au sein de ce bureau, etc). Ca demande du boulot de documentation et de communication (le wiki est une piste, le site principal une autre), comment faire si on est pas adhérent pour proposer quelque chose? Ici un automate peut faire l’affaire pour décrire tout le fonctionnement d’une manière visuelle, en plus il a l’avantage de montrer d’éventuelles failles de fonctionnement.
Pour la question de la migration mailing lists/forums -> discourse (si j’ai bien compris) là encore: il y a probablement déjà un plan de migration avec la liste de toutes les fonctionalités et de tous les services qui vont être migrés mais je ne l’ai pas trouvé, donner de la visibilité à cette liste, la maintenir à jour (expliquant par exemple que "pendant la migration du service truc les fonctionalités machin et chose seront TEMPORAIREMENT INDISPONIBLES, durant cette période vous pouvez aller sur le service blette pour une implémentation ad hoc des fonctionalités machin et chose).
Comme ça pas de risque qu’un observateur dise “hey, ils verrouillent tout, ils ont fermé le service truc et son API!”
ça s’applique aussi au site et aux services type congressus: avec des outils comme docker on peut faire un rollout facile de nouvelles fonctionalités avec la possibilité en une commande de faire un rollback vers l’ancien service: faut le dire, faut préciser “on a rajouté tel et tel trucs, on teste et si ça merdouille ya toujours la possibilité de revenir en arrière”. Ces informations apparaissent habituellement dans les commits/release notes mais les utilisateurs non techniciens n’en ont pas forcément conscience.
Transparence des états internes
L’accès aux sections et au contenu des discussions est un bon exemple:
Certaines discussions n’ont pas besoin d’être en place publique pour la bonne raison qu’elles n’ont pas forcément d’influence sur la posture/politique d’une organisation. Si je veux discuter du fait que je trouve une héroïne d’overwatch particulièrement sexy à la machine à café avec des collègues ça n’a pas besoin d’apparaître dans les minutes des réunions, pareil si j’ai envie d’organiser un raout avec des membres de ma section locale pour faire une lan/boire un verre j’ai pas forcément envie que la terre entière le sache. Il faut aussi responsabiliser les utilisateurs de ces sections fermées: on n’y discute pas le fonctionnement de l’organisation où les démarches à effectuer. Je pense que tout le monde peut se comporter en adulte responsable et jouer le jeu. Après si une discussion dérape en direction de ces sujets elle peut être poursuivie en publique.
Je ne pense pas qu’il est bon de donner l’image d’une organisation au garde à vous le doigt sur la couture, donc avoir des zones de discussion accessibles au monde en lecture (mais pas en écriture) pour les échanges sur les buts/fonctionnements me semble nécessaire. Ce n’est pas une marque de faiblesse de montrer qu’il y a des désaccords, bien au contraire et ça peut pousser des gens à venir s’exprimer, voir adhérer pour participer aux votes.
Il est aussi bénéfique de mettre à la disposition du publique des statistiques pas nominatives (sauf accord des gens concernés) sur l’organisation: nombre d’adhérents, de sections, nombre de discussions en cours, de réponses, décisions en cours de vote, etc. ça doit pouvoir s’automatiser pas trop difficilement en plus.
Quelqu’un (je sais plus qui) a évoqué des zones accessibles à l’extérieur fortement modérées. Je suis d’accord aussi, cela permets à d’autres de venir donner leur point de vue, par contre la question de la modération me pose problème. On voit souvent des cas de modérateurs qui se baladent et collent des coups de banhammer à tout va, c’est pas super transparent. Avoir une charte précise qui explique “qu’est ce qui se fait, qu’est ce qui ne se fait pas” dans ces sections est un bon mode de fonctionnement, cela permet aux modérateurs de justifier leurs actions (en vertu du paragraphe 3 alinéa 2 de la charte j’applique telle sanction pour le comportement ici ici et ici). Le contenu de cette charte doit aussi avoir été décidé via un processus démocratique et en bas de la charte on doit trouver des liens vers les différentes ressources (fils de discussion dessus, logs anonymisés des votes, etc). Une telle section pourrait même permettre de faire des suggestions à mettre au vote des adhérents, pourquoi pas!
Cibles du mécontentement
Avoir des gens qui se font pourrir d’une manière récurrente montre (pour moi) que ya peut être des améliorations à apporter, à moins bien sur que le but est d’avoir un “lider maximo” notre père/mère à tous responsable de tout évidemment. En mettant de la transparence dans les processus et les états et en responsabilisant tout le monde via des votes/discussion d’un coup ça devient impossible de pourrir une personne en particulier pour une décision. Après pourrir le développeur pour son implémentation c’est autre chose. Je suis dans le camp du “ah oui? c’est de la merde ce que j’ai fait? Ba montre moi ton alternative avant de pisser sur ma parade!”
D’autres discussions (point possible de débat) ont besoin de rester secrètes.
Nécessité du secret
Le meilleur exemple est le processus de test/sécurisation des actifs. On a pas besoin d’aller baver qu’on emploie le membre chose pour faire des tests d’exploitation sur l’infrastructure, pour la bonne raison que monsieur/madame chose pourrait devenir une cible si cela se sait. Idem on a pas besoin d’expliquer qu’on utilise la version x.x du serveur web blargh pour le site, parce que ça pourrait faciliter le boulot d’attaquants potentiels. Mettre le code du site en lui même open source est autre chose bien sûr.
Par contre il faut limiter le plus possible ces zones secrètes et la meilleur méthode pour le faire c’est de bien les définir afin qu’un observateur extérieur puisse facilement trouver une liste des éléments qu’on ne dit pas et de la raison pour laquelle on ne les dit pas, cela offre aussi la possibilité de discuter ces éléments si certains pensent qu’il faut les rendre publiques (processus démocratique).
ça peut sembler contradictoire, dire qu’est ce qui est secret et pourquoi mais c’est une nécessité: si on ne définit pas clairement les zones d’ombres (vous suivez?) alors d’un coup tout devient suspect.
Où mettre tout ça?
Le site principal: https://www.partipirate.org/
me semble être le bon endroit.
Conclusion
Voili voilou, je pense que j’ai fait le tour. Désolé si ça sonne yakafokon c’est juste les idées qui me sont venues en lisant ce fil, c’est pas des propositions ou des éxigences. après si ya besoin d’un coup de main pour certains trucs je peux aider aussi en fonction de mon temps libre (j’ai remplis ma liste de compétence sur fabrilia mais perdez pas de vue que comme tout le monde je subis l’effet dunning kruger).
patapay, sivouplé je suis encore un n00b 
