Lorsqu’un mouvement se compose de nombreuses assemblées autonomes, un problème apparaît rapidement : comment faire circuler les arguments, objections et propositions entre elles sans qu’une coordination ou un petit groupe finisse par décider pour l’ensemble ?
Une possibilité consiste à organiser directement la circulation du travail entre les assemblées.
Chaque assemblée produit un résumé de ses discussions : les principales informations, les arguments, les objections, les propositions, les alternatives et, lorsqu’il y en a, les résultats des décisions prises.
Ces résumés sont transmis rapidement dans un espace commun et regroupés par thèmes pour produire une synthèse. Il ne s’agit donc pas d’attendre qu’une assemblée centrale nationale se réunisse quelque part plusieurs semaines ou plusieurs mois plus tard : la circulation des résumés et des synthèses peut accompagner le mouvement au fur et à mesure qu’il évolue.
La synthèse permet alors à chaque assemblée de savoir ce qui se discute ailleurs : quels arguments apparaissent, quelles objections sont soulevées, quelles propositions évoluent, quels désaccords persistent. Elle retourne vers les assemblées, qui poursuivent leurs discussions et peuvent à leur tour produire de nouveaux résumés.
La synthèse n’est pas un lieu de décision. Les décisions restent dans les assemblées, selon les modalités que les participants ont choisies. Les personnes qui réalisent une synthèse n’ont donc pas à décider quelle position serait celle du mouvement. Leur rôle est de restituer aussi fidèlement que possible l’état des discussions : propositions, arguments, objections, alternatives et désaccords significatifs.
Le fonctionnement devient alors un cycle :
assemblées → résumés → synthèses → retour aux assemblées → nouvelles discussions → éventuelles décisions → nouvelle circulation
Ce fonctionnement pourrait s’appliquer à quelques assemblées pendant une manifestation comme à un réseau beaucoup plus large d’assemblées réparties sur le territoire.
Il ne s’agit pas de proposer un règlement tout fait. La méthode est expérimentale : elle doit pouvoir être testée, critiquée et modifiée par celles et ceux qui l’utilisent.
Où voyez-vous les difficultés d’un tel fonctionnement ? Dans la fidélité des résumés ? La réalisation des synthèses ? Leur rapidité ? Le risque de manipulation ? La participation ? La prise de décision à grande échelle ? Ou ailleurs ?
Présentation de la méthode et premières affiches explicatives : methodeoh.codeberg.page/methodeoh/
On ne parle de Linus que quand il gueule mais c’est triste parce que justement il est très suivi parce qu’il est généralement gentil avec tout le monde. Sur les sujets techniques, il pousse parfois une gueulante, et il a pas le coté policé-faux-cul qui est la norme aux US du coup ça les choque/amuse quand il appelle un truc “bullshit” or “really dumb”, mais il serait tout le temps comme ça, personne ne travaillerait avec lui. Y a plein d’experts du kernel plus compétent que lui (de son propre aveu, la plupart des maintainers des composants du noyaux sont meilleurs que lui)
La liberté de partir c’est bien, mais là on parle de la liberté de faire un fork: une copie de l’organisation. Quand tu te barres d’une assoce, tu n’as plus accès aux locaux, à la tréso, à la messagerie, etc…
Dans l’open source les outils sont faits pour que quand tu forkes un truc, tu sois au même niveau que le projet original. C’est une condition de survie pour plein de projets orphelins ou peu populaires.
Je peux pas démarrer un état avec Poutou et Jancovici. Alors que demain on peut démarrer un fork d’Android avec eux s’ils veulent.
@keepthepace
Mon sujet c’est juste de dire que prendre la communauté open source comme exemple de communauté fonctionnant sans chefs c’est pas vraiment pertinent en pratique.
Mon sujet, c’est de dire que si.
Y a pas de lien hiérarchique entre les autorités reconnues d’un projet et les contributeurs. Si demain Linus Torvalds décide de ne plus supporter les architectures x64 sous linux et de se concentrer sur arm64, il y aura immédiatement un fork et sa décision sera basiquement ignorée. Aucune décision de ces «chefs» n’est contraignantes. Ce sont littéralement uniquement des avis et opinions qui ont exactement les conséquences que la communauté choisit.
Le “fork” est le mécanisme qui rend ça possible et c’est souhaitable de le dupliquer dans les communautés en ligne partout où c’est possible.
@keepthepace
Mais il y aurra un nouveau chef.
Tu vois pas le problème logique à dire :
Il n’y a pas de chef, la preuve c’est qu’ils peuvent être remplacé.
?
Il n’y a PAS de chef. À remplacer ou non. Y a personne qui donne des ordres et d’autres qui suivent. Y a pas de lien hiérarchique.
Dans quelle monde une personne qui ne donne pas d’ordres et qui n’a pas de subordonnés, c’est un chef?
La façon dont ça fonctionne c’est qu’une personne, en général développeur très actif du projet, annonce “j’accepte des contributions au projet”, avec plus ou moins de règles sur ce qu’il ou elle accepte comme contribution. Les gens en envoient, en fonction de ce qu’ils ont envie. Le maintainer (le terme correct) les accepte ou non. (Souvent le critère principal est juste le temps que le maintainer a à consacrer au projet) Si elles ne sont pas acceptées, elles restent disponibles publiquement dans des branches ouvertes (on appelle ça des PR) et sont disponibles pour qui veut devenir le maintainer d’un fork si trop de modifications populaires sont refusées et que quelqu’un le temps de les intégrer.
Il y a zéro mécanisme coercitif.