[spip-dev] Mode de fonctionnement de la communauté

cerdic · Janvier 16, 2013, 9:29

Hello,

la discussion en cours sur la nouvelle proposition de logo illustre parfaitement une tendance forte de notre fonctionnement collectif ces derniers temps (mois ? année ?...) :

On est devenu très forts pour dégouter toute tentative de contribution qui change l'existant.
et corolairement, on est devenu très fort pour dégouter les contributeurs...

Le même scénario se reproduit à chaque fois : quelqu'un apporte une proposition pour faire évoluer un truc qui existe, ça ne plait pas à un autre contributeur (qui souvent se sent affectivement lié à l'existant) qui le dit vertement, et la discussion part en troll, pourri car rien n'est décidé, ce qui revient à entériner que l'on ne touche à rien. Et contribue à accumuler des rancoeurs.

Le seul espace de liberté de proposition possible pour un (nouveau) contributeur consiste à créer quelque chose de nouveau (et encore, on arrive de plus en plus souvent à flinguer aussi de telles contributions en leur reprochant de pas tenir compte de l'existant).
Pas étonnant dans ces conditions que l'on multiplie les sites de doc, les plugins-qui-font-la-même-chose-mais-pas-pareil, et que l'existant périclite, obsolète, jusqu'à ce que mort s'en suive...

On peut sans doute analyser cela de diverses façons.
Plutôt que pointer tel ou tel point, j'aimerai que l'on essaye de trouver un mode de fonctionnement collectif plus positif.

En particulier, j'ai pu observer récemment le renouveau de la communauté OpenWeb qui était assez sclérosée dans un fonctionnement historique de validation par consensus (où tout le monde devait être d'accord pour publier un nouveau contenu).
Ils ont décidé de passer à un mode de fonctionnement où il suffit que N personnes donnent leur accord pour qu'une proposition soit adoptée. De ce que je vois cela a énormément fluidifié les choses, et remotivé les contributeurs qui savent que leurs propositions peuvent aboutir (à condition évidemment d'être suffisamment murie) au lieu de rester mourir dans un placard.

Je me demande si une telle règle de fonctionnement ne déverrouillerait pas beaucoup de choses, évitant les situations de blocages et de dégout auxquelles on arrive ici de plus en plus souvent, et évitant aussi les passages en force de l'un ou l'autre.
Il faudrait la formaliser un peu, et voir quel est le seuil pertinent pour le nombre d'avis favorables.

Qu'en pensez-vous ?

Cédric

PS : oui ceci concerne la liste spip-dev qui regroupe tous les contributeurs au développement de SPIP

fil · Janvier 16, 2013, 9:43

Entièrement d’accord sur le constat, mais plutôt que d’importer une règle de vote à N, très facilement manipulable et posant le risque de conduire à la fragmentation, on peut se reporter à SPIP-Zone, qui était le fruit d’une réflexion menée en 2005, et qui a pas mal marché depuis

Bref, la réflexion de 2005 avait conduit à prévoir un “mécanisme de résolution des conflits”
cf http://zone.spip.org/trac/spip-zone/wiki/CharteDeFonctionnement

Mécanisme de résolution des conflits

Un règlement interne ne saurait être complet sans préciser ses mécanismes de résolution des conflits. Cette section évoluera probablement au cours du temps, en fonction du nombre et de la nature des conflits à traiter, mais il faut bien démarrer par quelque chose.

Une commission d’arbitrage sera désignée. En cas de conflit, tout participant peut saisir cette commission. Celle-ci statue en conscience, en se basant sur les critères définis ci-dessus, et dispose de toute latitude dans le règlement du conflit.

larmarange · Janvier 16, 2013, 9:51

Bonjour Cédric,

il est toujours pertinent de discuter de nos modes de fonctionnement collectif et il n’y a pas de mal à les faire évoluer.

Tu évoques la communauté OpenWeb qui ont adopté un nouveau mode de fonctionnement pour dynamiser leurs prises de décision. Il est vrai que l’on a souvent du mal dans SPIP à arriver à une décision collective. Je suppose également que la communauté OpenWeb a voulu aussi éviter la dérive qui consisterait uniquement à aboutir à un comptage de “J’aime” à la Facebook.

Sais-tu s’il y a trace de leurs discussions concernant les évolutions de leur mode de fonctionnement ? Comment centralisent-ils les débats avant prise de position des uns et des autres ? Ont-ils dû adopté des règles complémentaires ou cette seule règle du nombre d’avis favorables c’est avérée suffisante ?

Bref, as tu à ta connaissance des retours un peu plus importants sur leur dynamique qui pourraient nous éclairer/inspirer ?

Bien cordialement

cerdic · Janvier 16, 2013, 9:58

En pratique ? Elle est où cette commission ? Qui la compose ? Comment on la saisit ?
C'est une solution théorique jamais éprouvée...

Et je ne sais pas si on peut dire qu'elle a marché puisque sur la zone même on retrouve les problèmes que j'évoquais : bashing des nouveaux arrivants si ils proposent un nouveau truc qui fait doublon avec un existant, et bashing si ils modifient un existant qui perturbe l'ordre établi...

Mais bon, c'est une piste à suivre et qu'on peut essayer. Je crois que tout sera mieux que le statu quo actuel...

Cédric

fil · Janvier 16, 2013, 10:14

En pratique ? Elle est où cette commission ? Qui la compose ? Comment on
la saisit ?
C'est une solution théorique jamais éprouvée...

Tout à fait, puisque jusqu'ici il n'y a pas eu de conflit nécessitant ce
recours … mais c'est ce qu'on a décidé collectivement à l'époque et que
chaque contributeur a depuis lors "signé", et à ce titre c'est plus
légitime que d'inventer à la va-vite une règle.

Et je ne sais pas si on peut dire qu'elle a marché puisque sur la zone
même on retrouve les problèmes que j'évoquais : bashing des nouveaux
arrivants si ils proposent un nouveau truc qui fait doublon avec un
existant, et bashing si ils modifient un existant qui perturbe l'ordre
établi...

En l'occurrence ça me semble être deux choses qui se jouent à des niveaux
différents : dans un cas, le conflit, avec une procédure pour essayer de
produire une décision plutôt qu'une discussion qui s'enlise ; dans l'autre,
les micro-relations au quotidien dans le groupe.

Mais bon, c'est une piste à suivre et qu'on peut essayer. Je crois que
tout sera mieux que le statu quo actuel...

yeppo

-- Fil

Ybbet · Janvier 16, 2013, 10:18

Bonjour,

Je prends la conversation en cours en ayant vu et lu les différents échanges qui ont abouti à ce topic.

Il y a de cela 1 an voir 2 ans, RastaPopoulos avait proposé de mettre en place une boîte à idées… (troll non permis, ce n’est pas le but de la conversation).

Cédric parle du système de vote d’OpenWeb. La boîte à idées avait pour mode de fonctionnement ce principe. Oui, on entre dans un mode “J’aime” facebook-like mais Facebook n’est pas l’inventeur de cette solution mais celui qui l’a démocratisé et surtout vulgarisé dans tous les sens du terme.

J’avais (mais je ne suis pas le seul si mes souvenirs sont bons) proposé un système à la uservoice. Exemple : http://siwapp.uservoice.com/

On propose des idées, des améliorations, des tâches à accomplir et on s’y attèle à la tâche.

On ferait une sorte de redmine (core.spip.org) pour attribution des tâches. (Plus exactement, une ou DES personnes disent “on le fait”).

Pourquoi ne pas (re)mettre cela en place ?

klaus · Janvier 16, 2013, 10:37

Salut,

je ne pense pas que des mécanismes techniques puissent apporter une solution ici. La solution se situe plutôt dans la pratique de discussions ouvertes et respectueuses.

Comment arriver à des décisions ? Si on se rappelle de la particularité du projet SPIP qui le caractérise depuis >dix ans on a déjà gagné à moitié. Ce sont la volonté de rester ouvert, de servir à qc qui dépasse le cadre technique et de se retrouver (plus ou moins) amicalement autour d'un truc où chacun peut apporter son grain de sel. Cet accord commun est bâti autour d'un outil permettant à chacun de s'exprimer librement et comme il le veut.

A mon avis il suffit de ne pas perdre de vue cette base - après il est toujours possible de se mettre d'accord sur des méthodes plus ou moins techniques pour s'attaquer à une question particulière et pour céer une situation dans laquelle il est possible de prendre des décisions.

:-)klaus++

cerdic · Janvier 16, 2013, 10:45

Je ne suis pas vraiment d’accord avec cette affirmation.
Il y a eu plein de conflits larvés non résolus, qui chacun laissent des blessures aux protagonistes.
Peut-être non résolus parce que cette commission de recours n’existe qu’en théorie à tel point que personne n’y pense ou n’y croit vraiment. Peut-être aussi parce que cette commission n’est présentée que pour réguler la zone.

Est-elle compétente pour décider d’adopter ou non une nouvelle syntaxe de squelette dans SPIP ? un nouveau logo pour le projet ? une proposition de refonte pour un site de la communauté ?..

Il suffit de reprendre la liste spip-dev et de remonter les topics pour trouver plein de questions de ce type « en suspens », non résolue, en cours de pourrissement par abandon des combattants, qui s’en sont parti faire autre chose de plus constructif autre part…

Cédric

klaus · Janvier 16, 2013, 11:02

Je ne crois pas non plus qu'une commission soit nécessaire à ce point :

Tout à fait, puisque jusqu'ici il n'y a pas eu de conflit nécessitant ce recours …

Je ne suis pas vraiment d'accord avec cette affirmation.
Il y a eu plein de conflits larvés non résolus, qui chacun
laissent des blessures aux protagonistes.

Oui, sans doute, mais est-ce qu'un mécanisme formalisé aurait évité les blessures ?

Est-elle compétente pour décider d'adopter ou non une nouvelle syntaxe
de squelette dans SPIP ? un nouveau logo pour le projet ?
une proposition de refonte pour un site de la communauté ?...

J'ai toujours fait confiance aux membres de la communeauté parce que chacun apporte ses contributions de son propre gré et parce que la communeauté n'est pas gérée par une entreprise privée ou un organisme officiel.
En bref c'est rassurant il n'y ait pas de "propriété privée" allant au delà du respect de la licence GNU, il n'y a justement personne pour obliger les autres à ... .

Ensuite les différents auteurs des sous-projets font ce qu'ils veulent, libre à chacun de forker quand il n'y a pas d'entente possible. C'est valable pour SPIP aussi : si je trouve qu'un truc ne me convient pas, je le dis et si ma critique n'est pas acceptée ou réfutée d'une manière convaincante, je forke ou je change de SPIP

Dans le cas présent je pense qu'un nouveau logo sera le sujet de vives débats jusqu'à ce qu'il plaise à presque tout le monde.

klaus++

spipfactory2 · Janvier 16, 2013, 7:52

ben si les mails arrive pas … c’est sur qu’on perd le fil ---------------------------------------------------------------------------------------------------------------

JLuc · Janvier 17, 2013, 12:14

la discussion en cours sur la nouvelle proposition de logo illustre parfaitement une tendance forte de notre fonctionnement collectif ces derniers temps (mois ? année ?...) :
On est devenu très forts pour dégouter toute tentative de contribution qui change l'existant.
et corolairement, on est devenu très fort pour dégouter les contributeurs...

Je suis d'accord avec toi, et ce thread même en a été d'une certaine manière une illustration,
vis a vis de de ta proposition de changer le mode de fonctionnement et décision.

> Plutôt que pointer tel ou tel point, j'aimerai que l'on essaye de trouver un mode de fonctionnement collectif plus positif.

Oui. J'aimerais bien que cette proposition ne finisse pas comme ce que tu évoques plus loin,
comme une question ""en suspens", non résolue, en cours de pourrissement par abandon
des combattants, qui s'en sont parti faire autre chose de plus constructif autre part...".

Ils ont décidé de passer à un mode de fonctionnement où il suffit que N personnes donnent leur accord pour qu'une proposition soit adoptée. De ce que je vois cela a énormément fluidifié les choses, et remotivé les contributeurs qui savent que leurs propositions peuvent aboutir (à condition évidemment d'être suffisamment murie) au lieu de rester mourir dans un placard.

Ma foi, je serai pas contre.
On pourrait essayer sur une période d'essai au moins.

Il faudrait la formaliser un peu, et voir quel est le seuil pertinent pour le nombre d'avis favorables.

Qu'en pensez-vous ?

Voilà.

JLuc

cerdic · Janvier 17, 2013, 2:13

Je crois bien plus sain que des décisions soient prises. Certains trucs seront jetés/refusés et ça fera chier, mais si on sait pourquoi ça peut permettre d'aller ensuite dans la bonne direction. Et certains trucs seront mis en oeuvre. Ou alors quand on voit ses propositions toujours rejetées on se dit qu'on colle plus avec l'esprit du projet et on va jouer autre part.

Mais là il y a une espèce d'immobilisme larvé qui fait bien plus mal : les propositions se font lyncher par l'un ou l'autre (et on est très forts pour que occuper chacun son tour le rôle du méchant), ça tourne en eau de boudin sans même savoir si la proposition est définitivement morte, si il y a moyen de l'améliorer pour être acceptable, ou même si c'est juste bloquant pour *un* seul d'entre nous et qu'il faut peut être pas s'arrêter à ça.

Peut-être que c'est tout autant le manque d'engagement général qui ne va pas qui fait qu'on ne réagit à une proposition que si elle nous plait pas et qu'on ne prend pas part à la discussion quand ça nous irait mais qu'en fait on s'en fout...

Pour revenir à ta question, oui je crois fondamentalement qu'une décision (que ce soit un oui ou un non) vaut beaucoup mieux qu'un pourrissement. Surtout quand le scénario se répète.

Cédric

Suske · Janvier 18, 2013, 11:31

Salut,

J'aurais dû tout lire avant de poster mais voilà, moi aussi je me sens
concerné...

Pour revenir à ta question, oui je crois fondamentalement qu'une décision (que ce soit un oui ou un non) vaut beaucoup mieux qu'un pourrissement. Surtout quand le scénario se répète.

Du point de vue de la communauté, si on était dans un schéma
organisationnel/décisionnel, oui. Mais je crois qu'on est dans un schéma
communautaire. Les décisions se prennent par consensus entre celles et
ceux qui sont en contact. Et pas ceux qui agissent. La difficulté du
passage sur spip-dev c'est que brusquement des projets et travaux sont
soumis au commentaire, généralement sans le background/l'information
préalable qui serait nécessaire dans ce contexte. En communauté, c'est
le deuil de l'unanimité qu'il faut faire et le consensus nécessite
souvent beaucoup de temps pour se construire.

La "solution" a été expérimentée déjà, et elle apporté un réel Bonux à
SPIP, permis à chacun d'avancer et au core aussi... Je propose donc par
ailleurs qu'on passe sur la zone pour faire un plugin des travaux de
Sébastien. Il me semble ue les soutiens à son travail sont suffisemment
nombreux et exprimés pour continuer sur cette base-là. Que déjà on
puisse l'utiliser si on aime. Et puis SPIP, c'est un core et des
plugins-dist non ?

Le comité d'arbitrage il concerne la zone, pas SPIP amha. Il devra être
saisi si des gens s'opposent au dépot sur la zone d'un projet de plugin
"logo-eventuel" mais cette opposition ne serait pas recevable me
semble-t-il. Si des décision oui/non *doivent absolument* être tranchées
par SPIP, il faut renvoyer ça à ses auteurs (c). Et je n'ai pas regardé
ça récemment mais il serait peut-être bon que tu y sois ajouté (ça ne me
regarde pas vraiment, je sais) ?

eric_tonton · Janvier 19, 2013, 9:50

Yop,

Du point de vue de la communauté, si on était dans un schéma
organisationnel/décisionnel, oui. Mais je crois qu’on est dans un schéma
communautaire. Les décisions se prennent par consensus entre celles et
ceux qui sont en contact.

Ce n’est pas ce que les dernières années attestent même si on a eu parfois un peu de chance…
Le fantasme du consensus global pour avancer dans SPIP est justement à l’origine de tous ces pourrissements qui sont autant de boulets aujourd’hui.
Donc le constat de Cédric est bien le bon et il faut trouver une solution acceptable pour sortir de cette torpeur.

La « solution » a été expérimentée déjà, et elle apporté un réel Bonux à
SPIP, permis à chacun d’avancer et au core aussi…

Bof, je trouve pas justement que ce soit un bon exemple mais plutôt celui d’une fuite et pas d’une résolution de problème même si cela pouvait se justifier à l’époque.

Le comité d’arbitrage il concerne la zone, pas SPIP amha. Il devra être
saisi si des gens s’opposent au dépot sur la zone d’un projet de plugin
« logo-eventuel » mais cette opposition ne serait pas recevable me
semble-t-il. Si des décision oui/non doivent absolument être tranchées
par SPIP, il faut renvoyer ça à ses auteurs (c). Et je n’ai pas regardé
ça récemment mais il serait peut-être bon que tu y sois ajouté (ça ne me
regarde pas vraiment, je sais) ?

Si je regarde quelques exemples qui ont fonctionné cela a souvent été le résultat d’un travail en petits groupes. J’ai quand même l’impression que c’est une méthode qui correspond mieux à la communauté car elle n’oblige pas à demander la participation de tous pendant une période donnée.

Mais le logo a bien été le résultat d’un groupe de travail.
Ce qui a péché à mon avis c’est :

l’initialisation : quelle composition pour le groupe et quel objectif qui n’a pas été suffisamment explicite ?
la finalisation : pourquoi demander l’avis à toute la communauté alors que le travail a été fait par un groupe ?

C’est pourquoi je me demande si une solution ne serait pas :

On identifie et décrit un sujet
On crée un groupe pour y travailler : dès lors on a confiance en ce groupe pour porter le sujet jusqu’à sa réalisation.
le groupe instruit le sujet, en discute, et le réalise et démontre son intégration correcte dans SPIP.
le résultat est intégré à SPIP et il sera ensuite commenté au travers des tickets concernant le core.

Dans ce processus, on discute surtout pour démarrer (étapes 1) et 2) ) et tous ceux qui ont quelque chose à dire peuvent y participer en temps utile voire intégrer le groupe. Mais au moins, une fois lancé on devrait éviter la situation actuelle de blocage « sur le fil » comme pour le nouveau logo.

cy_altern · Janvier 19, 2013, 2:13

J'aurais tendance à faire le même constat que les "quelques exemples qui ont fonctionné cela a souvent été le résultat d'un travail en petits groupes"
Et du coup je serais assez pour essayer de généraliser une organisation de ce genre : de toute façon on ne pourra pas faire bien pire question "abandons avec jettage d'éponge des contributeurs de projets quasi-finalisés" et "on ne fait rien parce que de toute façon il faut tout reprendre de zéro" qui semblent se multiplier ces derniers temps...

Peut être faut il que ça passe par la formalisation de ce mode de fonctionnement comme le proposait Cédric (votes, système de consultation...)?
Pas certain mais dans tous les cas ça nécessite quand même qu'on essaie de fonctionner sur la base de "on a *confiance* en ce groupe pour porter le sujet jusqu’à sa réalisation"!

à bientôt,
cy_altern

fil · Janvier 19, 2013, 2:28

Je ne vois pas de meilleure solution que ces petits groupes "agiles".
Peut-être parce que, personnellement, c'est comme ça que je fonctionne le
mieux. De toute façon, on est trop nombreux pour marcher tous ensemble ; le
"consensus" crée des blocages ; les systèmes de vote traditionnels sont
pratiquement ce qu'il y a de moins démocratique (et ont une tendance à
accroître la division en "camps") ; le fonctionnement par comités désignés
a tendance à tomber dans la torpeur.

Si on veut se compliquer la vie on peut expérimenter avec des votes
compliqués (système Condorcet, "liquid democracy", etc) ; mais dans notre
cas, là il ne s'agit pas tant de discuter pour décider, que de permettre à
chacun d'agir, en tenant compte des avis, mais sans que ça crée des
entraves.

Une question subsidiaire, c'est celle de ce qui se passe quand un groupe
n'avance pas (pour de bonnes ou mauvaises raisons). Peut-être une bonne
règle serait qu'un groupe ne peut pas durer plus de x temps, sauf s'il
décide expressément de se reconduire. Ainsi si le groupe "logo" ne donne
plus signe de vie après 6 mois, un autre groupe "logo" peut se former sans
que ça froisse le précédent, qui "allait s'y mettre".

-- Fil

eric_tonton · Janvier 19, 2013, 2:46

Oui très bonne idée.
Ca complète bien le processus décrit et permettra a minima de se poser la question régulièrement à intervalle compatible avec la durée vie humaine

Ybbet · Janvier 19, 2013, 3:25

Oui très bonne idée.
Ca complète bien le processus décrit et permettra a minima de se poser la question régulièrement à intervalle compatible avec la durée vie humaine

Alors comment mettre cela en place ?
Il faudrait pourvoir « s’inscrire » sur tel ou tel projet. Un peu à la méthode de tickets.
Cela permettrait d’améliorer la communication et éviter que des personnes travaillent dans leur coin en « catimini »'. Cela a été un reproche à la communauté SPIP.
De plus, si des personnes (nouvelles ou pas) désirent y participer, elles sauront à qui s’adresser.

Pour ma part, le concept suivant (qui rejoint ce qui a été dit jusqu’à maintenant je pense) me plaît :

On crée un topic/ticket ;
On en parle par commentaires du topic pour avoir une feuille de route même brève ;
Des personnes décident de s’y atteler (on attribue la tâche à telle ou telle personne enregistrée) ;
Et on se lance dans le groupe de travail.

Par rapport à la deadline que propose Fil, on peut dire que dès que le ticket se trouve des acquéreurs, il passe en statut « démarré » et automatiquement, une deadline de 6 mois est affichée au ticket…
Méthode agile, gant ou pert… Selon l’envie et les affinités de chacun…

[HS]
Je ne sais pas si vous connaissez Trello, mais c’est un peu le même principe.
https://trello.com

Ybbet

rastapopoulos · Janvier 20, 2013, 12:45

Je ne vois pas de meilleure solution que ces petits groupes "agiles".
Peut-être parce que, personnellement, c'est comme ça que je fonctionne
le mieux.

Pour l'instant je ne peux qu'être d'accord, sachant que le 24 juillet je disais ceci à la team :

Au-delà du commit, je ne suis pas pour le leadership unipersonnel (je rejoins ce que vient de poster Emmanuel pendant que j'écrivais), mais je suis très pour des groupes "délégatifs". Autrement dit : je donne ma confiance à tel petit groupe de personnes pour réfléchir à un aspect précis de SPIP. Mais mais mais :

1) dans ce cas, les groupes doivent être *explicites* : on doit pouvoir savoir qui travaille sur quoi sans être sur IRC ;

2) même si ce n'est pas au début de sa formation, un groupe de réflexion doit à un moment ou un autre intégrer au moins une personne qui sait *coder* et qui peut *commiter* les modifs.

Dans cette configuration, il est évident que chaque groupe peut intégrer des personnes ne faisant pas partie de la team, ne sachant pas coder, etc.

Voilà, c'est toujours valable, y compris pour le logo.

Déléguer : oui, mais de manière transparente, que tout le monde puisse savoir qui fait quoi sans être un happy few.

Ybbet · Janvier 20, 2013, 12:50

Je ne vois pas de meilleure solution que ces petits groupes "agiles".
Peut-être parce que, personnellement, c'est comme ça que je fonctionne
le mieux.

Pour l'instant je ne peux qu'être d'accord, sachant que le 24 juillet je disais ceci à la team :

Au-delà du commit, je ne suis pas pour le leadership unipersonnel (je rejoins ce que vient de poster Emmanuel pendant que j'écrivais), mais je suis très pour des groupes "délégatifs". Autrement dit : je donne ma confiance à tel petit groupe de personnes pour réfléchir à un aspect précis de SPIP. Mais mais mais :

1) dans ce cas, les groupes doivent être *explicites* : on doit pouvoir savoir qui travaille sur quoi sans être sur IRC ;

2) même si ce n'est pas au début de sa formation, un groupe de réflexion doit à un moment ou un autre intégrer au moins une personne qui sait *coder* et qui peut *commiter* les modifs.

Dans cette configuration, il est évident que chaque groupe peut intégrer des personnes ne faisant pas partie de la team, ne sachant pas coder, etc.

On est tous d'accord alors :