Outils pour utilisateurs

Outils du site


Panneau latéral

Mycélium

Documentation

Travaux

Membres

Wiki

travaux:reflexions:fonctionnement_collectif

Note: les notes sont complètes, c'est bon.

FONCTIONNEMENT COLLECTIF

Écrit le 20/07/2017

Sur la prise de notes : ça me paraît toujours délicat de la faire en direct dans le wiki, d'autant que ça signifie que les notes ne seront pas relues (donc pas comme quand on recopie ses notes du papier vers l'écran). Personne ne fait part du fait que les notes ont été prises et sont consultables, c'est dommage car il s'agit d'un résumé de l'activité, et une preuve de l'avancement. A partir de quand on considère que les notes sont finalisées ? 3 jours après la réu tout le monde a ajouté ses éléments ? (Réponse : when it's ready : c'est le rôle des personnes désignées pour prendre les notes de signaler sur la liste de diffusion que c'est prêt) Pour moi il faut signaler que les notes sont finalisées. C'est moins nécessaire pour les CRs de groupes de travail, mais c'est nécessaire pour les AGs.

Prise de parole : un problème : permettre que chacun puisse participer et se sente impliqué. Ne pas monopoliser les échanges. C'est franchement pas agréable que ce soit “une” personne qui apprenne et que les autres restent en touche. Ne pas se précipiter dans le vif du sujet en début d'atelier/de réu, réfléchir/veiller aux conditions pour bien démarrer l'activité collective, éventuellement systématiser le tour de table.

Communication sur l'avancement : ça se fait via les CRs, ça recoupe les points précédents. Ce qui me gêne c'est que l'avancement ne soit connu qu'au sein d'un cercle (le groupe de travail qui a réalisé l'opération). L'AG mensuelle vient rattraper le coup : il y a normalement un résumé de la part du GdT de ce qui a été fait. Mais je trouve ça assez différent d'autres projets (exemple: le projet Debian) où l'on peut suivre tous les aspects au jour le jour pour peu qu'on choisisse de suivre les échanges via les canaux de communication idoines. C'est les outils numériques et la transparence qui permettent ça (voir point “Transparence”). La raison de tout ça, c'est d'éviter le sentiment qu'il n'y a qu'un groupe de personnes qui “est au courant de la situation”, éviter le “t'es à la ramasse, t'es pas venu à la dernière réunion technique”, ou bien apprendre ce qui a été accompli de manière fortuite (de la bouche des personnes : car ça veut dire que l'information n'a pas circulé). Je ne vois pas de mesure à prendre particulière, mais pour moi ça montre l'importance des CRs et du soin potentiel à fournir sur la communication de l'avancement. Je trouve plus agréable que ces informations soient partagées.

Transparence : la transparence et la vie privée. Une illustration de la transparence pour moi c'est le développement des logiciels libres sur internet : code source public, rapports de bugs publics, listes de diffusion avec archives consultables. C'est une condition pour que la collaboration soit possible et pour éviter les situations où des personnes contrôlent le projet (sur la gestion des accès, ou sur le fait qu'il puisse y avoir un fonctionnement qui se fasse en coulisse). Le modèle du logiciel libre est l'opposé du fonctionnement précautionneux pratiqué dans d'autres collectifs (effacer les archives de discussion, ne diffuser les informations que dans des cercles plutôt que public…) Hormis l'anonymat/pseudonymat, est-ce que ça pose problème à qqn d'assumer cette transparence fonctionnelle ?

La question reste ouverte sur le “qu'est-ce qui doit être transmis à la liste, qu'est-ce qui peut circuler entre les personnes” (par exemple: une personne est mandatée pour une tâche, comme prospecter pour l'hébergement de Crucibule. Elle ne va pas transmettre toutes ses correspondances à la liste de diffusion.).

A part ça cette question reste encore un peu vague, je flaire que la question puisse poser problème, mais je peux pas dire qu'actuellement il y a un problème à ce niveau. (disons qu'après avoir passé mes coups de gueule sur les CRs, ça a ptet déjà suffisamment retranscrit mes craintes).

STATUTS

Rappel que les statuts ont été validés pour débloquer la situation administrative. Certains trucs ont l'air de bien fonctionner : orga en groupes de travail… Juste pour signaler donc qu'ils n'ont actuellement rien d'officiels/effectifs, certains bouts des statuts sont exacts et d'autres pas. Proposition de rajouter une mention explicitant ce problème dans la page statuts du wiki. https://mycelium-fai.org/wiki/doku.php/statuts Il fallait en effet répondre à la question : quel est le statut de nos statuts : en plus de leur valeur juridique, est-ce qu'on peut déjà imposer chacune de ses lignes directrices au public, et si non, mentionner au public que les statuts sont “déclaratifs” mais qu'ils n'ont pas pour rôle d'établir (ou de faire autorité/référence) le fonctionnement de notre asso. Pas d'urgence à refaire une réunion pour retravailler ces statuts.

note: On n'a pas rédigé la fiche de correspondance “président / trésorier > quelle entité dans notre asso ?” (mandat cachou+fab)

ARCEP

C'était juste faire un topo, s'assurer qu'on est un minimum carrés avec nos pièces administratives, nos rôles et assignations, adresses de contact.

LOGO

La typo airstrip me va. J'aurais par contre souhaité d'autres propositions de couleur.

micro-point technique : rendre l'upload du .svg possible dans le wiki. Voir dans les fichiers de config de dokuwiki, mime.local.conf je crois.

travaux/reflexions/fonctionnement_collectif.txt · Dernière modification: 2019/11/09 15:45 par tyrben