# Organisation et décisions dans une optique autogérée et non-argentée ![Gentil polatouche](http://f.ldd.fr/images/spipoulet/polatouche-2.png)
# Parce que c'est NOTRE PROJEEEET
# 1. Fonctionnement actuel Régulièrement revient sur le tapis - et c'est très bien - le questionnement sur comment nous organisons la communauté, comment les décisions sont prises.
* Chacun⋅e bosse sur ce qui l'intéresse ou ce dont ille a besoin * Si problème, on discute et on cherche un consensus * Si pas de consensus : rien. Nada. * Mantra 1 : « du logiciel libre et de la tendresse » * Mantra 2 : « on commit et on s'engueule après » * Mais du coup en vrai c'est la loi de la jungle. C'est de l'autogestion "à minima", sans formalisation de résolution des conflits.
# 2. Des problèmes ? Voici quelques exemples de chantiers qui ont capoté dans le passé.
## 2.1. Le logo La communication autour du projet de logo a abouti à un gros bazar où personne n'était d'accord, où le pauvre graphiste s'est retrouvé au pied du mur sans rien comprendre, et au final avec un blocage complet, et aucune suite donnée au projet.
* Un groupe de personne (plutôt du noyau) ont demandé à Seb. * Mais projet pas public, plutôt semi-public. * Quelques personnes précises le savaient, et commentaient/critiquaient. * Présenté à __toute__ la communauté sur spip-dev __à la fin__. * Découverte du projet par la plupart, avec plein d'avis d'un coup. * Et là tout le monde s'est mis à faire ses contres propositions, chacun faisant son logo, en ayant les compétences ou pas. ![SPIIIIP](http://f.ldd.fr/images/spipoulet/charte/logos.jpg)
## 2.2. La proposition d'admin avec onglets * Quelques personnes avait commencé à réfléchir à une ergonomie différente pour éditer les contenus. * La proposition était d'utiliser des onglets, afin de séparer le contenu lui-même, de ses méta-informations/liaisons. * Elle a été commité dans le noyau... * ...Et annulé par Arno* un peu plus tard, avec pas mal de disputes sur les listes.
## 2.3. D'autres chantiers qui n'avancent pas * D'autres chantiers n'ont pas forcément eu encore de blocages * Mais sont bloqués depuis de nombreuses années. * Potentiellement candidats à des blocages similaires si des gens s'y mettent. * Sûrement une des raisons (même si pas la seule) qui fait que c'est difficile de s'y mettre, appréhension que ça bloque pareil.
## 2.4. Image de SPIP, vue depuis l'extérieur * « Les gens » ne savent pas trop ce qui se passe dans SPIP, ni comment la communauté fonctionne, ni même si c'est toujours vivant * Manque de communication et de transparence : * Comment fonctionne-t-on ? * Comment on rentre ? * Comment on gère les propositions et les conflits ?
* Nous-mêmes en interne on aurait du mal à répondre à certaines questions (gestion des conflits) * On sait des fonctionnements mais de manières empiriques, parce qu'on les a vécu * Ce sont des informations **qui doivent être explicites et publiques** pour la bonne marche démocratique du groupe.
# 3. Les risques si on garde ce fonctionnement
* Blocages / avancement compliqué sur ces sujets * Peu de nouvelles personnes (devs, graphistes, ergonomes, etc.) * Image faussée d'un truc qui n'avance pas * Mauvais retours des décideureuses / mauvaise presse * Risques de «solutions» en désaccord avec les valeurs d'origine (assocs, bureau, argent à gérer…)
On voit à la fois un manque de communication, et un manque de gestion des conflits et des décisions quand on doit changer plus que des petites choses.
## S'accorder sur le constat * Il y a bien des soucis qui causent des blocages. * On ne peut pas se contenter uniquement du consensus en permanence. * Il est possible d'avancer sur des choses bloquantes de longue date tout en restant une communauté **autonome, autogérée et sans gestion d'argent direct**.
# 4. Des pistes de solutions Nous ne pensons pas que tous les problèmes peuvent se résoudre par les mêmes solutions, et nous n'avons pas de réponse à tout, c'est un ensemble d'outils humains à construire en commun. Mais nous aimerions présenter quelques idées et pistes que nous trouvons intéressantes.
## 4.1. Des groupes de travail mandatés en amont
* Des groupes mandatés par la communauté pour avancer sur un sujet précis * Mandats révoqués une fois le sujet clos * Le groupe a autorité pour prendre des décisions et trancher sur les bloquages * __Des obligations pour le groupe de travail :__ * S'engager sur une certaine disponibilité pour participer à un groupe * Communiquer régulièrement sur l'avancement du projet * Consulter et demander l'avis de la communauté (emails, votes, etc) * Prendre en compte les retours de la communauté * __Des obligations pour la communauté :__ * Payer des bières au groupe de travail ?
Des questions à résoudre : * Quelles sont les prérequis pour participer à un groupe de travail : compétences, disponibilité, etc. ? * Comment acter/matérialiser le fait que "la communauté" donne mandat à un groupe de gens ? => ne pas juste déplacer le débat interminable en amont * À quel niveau et selon quelles modalités les gens externes à un groupe de travail peuvent-ils s'impliquer ? * Comment/où communiquer avec la communauté ?
## 4.2. Différentes manières de voter * Vote par [jugement majoritaire](https://seenthis.net/messages/583022) * Outils de vote, d'aide à la décision (framatrucs, notamment [framavox avec loomio](http://framavox.org/))
## 4.3. Une charte SPIP pour l'ensemble de la communauté * Partir sur la base de celle de la zone * L'augmenter en explicitant ce qui se passe quand il n'y a pas consensus * Et peut-être d'autres ajouts à définir… * La généraliser à l'ensemble de la communauté, quelques soient les "lieux"
## 4.4. Une Feuille de route possible * Monter un groupe de gens intéressés pour mettre à plat les pistes de solutions * Définir les modes de fonctionnement pour les gros chantiers * Rédiger une charte pour l'ensemble de la communauté
# There is no alternative