Formalisation des groupes d’action et du mandatement

il faut totalement laisser de côté la partie soutien financier, tu as raison.

Plone décrit précisément le processus pour devenir un membre reconnu : https://plone.org/community/membership/process
Quelques contributions ne suffisent pas

.. et il n'y a pas tant de membres que ça qui ont un droit de vote
https://plone.org/community/membership
Par contre il y en a plus qui participent autrement https://plone.org/foundation/members

En tout cas ils semblent actifs et efficaces https://plone.org/foundation/meetings/minutes

Je réfléchissais aux grandes étapes du déroulement d'un chantier dans le cadre d'un groupe de travail mandaté, sans rentrer dans les détails techniques, juste les grandes lignes. Pour l'instant, j'imagine que ça ressemblerait à ça :

• Une personne ou un groupe de personnes a une idée de projet formidable, plutôt complexe et nécessitant une collaboration à plusieurs. Il en fait l'annonce détaillée et soumet cette proposition à la communauté.
• La communauté donne son avis, des volontaires se manifestent. Si les retours sont positifs, le groupe de travail est « officiellement » mandaté.
• Le projet est lancé : il est matérialisé sur l'outil de collaboration avec publication des intentions initiales, puis le groupe de travail avance, communique, et gère les retours selon les modalités qui lui conviennent.
• À l'issue du travail, un compte rendu est publié, le projet est publié et/ou intégré, tout le monde se réjouit !

A mon avis, il faudrait prévoir un seuil / un critère précis qui permette de dire "le groupe est officiellement mandaté". Par ex : x utilisatrice·teur·s soutiennent le projet de GT et Y sont près à y participer. Une fois le projet de GT acté, dans un second tps doit se constituer le GT et la validation de sa composition par la communauté.

Mon message concenait le p.2 de tcharlss, je suis globalement d'accord avec le reste mais le 2 doit être affiné.

Ah, RastaPopoulos a répondu pendant que j'étais en train d'écrire :)

Du coup il y a juste un point sur lequel je pouiche : je suis pour simplifier au maximum le processus, aussi je ne crois pas qu'il y ait besoin de 2 étapes pour mandater un chantier (une fois pour valider l'idée proposée, et une autre fois pour valider ses membres).
À mon avis, dès le début quand on propose un chantier on dirait : voilà ce qu'on veut faire, et voilà qui est dans le groupe à la base.
Une fois mandaté, à l'initiative du groupe, il peut lancer un appel pour d'autres personnes intéressées.

Ensuite, c'est vrai qu'on n'a pas abordé la question de l'équipe du noyau.
On ne pourra pas conclure les projets si il n'y a pas l'assentiment des gens qui ont les clés quand ils ne font pas partie des groupes (pour intégrer du code dans le core, pour faire des modifs sur les sites officiels...).

Mais d'autre part, on perdrait tout de même une "légitimité" communautaire si on ne demande pas l'avis de la communauté.
Il faudrait trouver une façon de prendre en compte les 2.

Ça pourrait être des choses comme : vote de la communauté et un nombre minimum de gens du noyau qui donnent leur accord, ou alors vote de la commnauté et les gens du noyau ont un droit de véto, etc.

ok avec tes observations sur le process et sur le rôle essentiel du core. Rien ne pourra se faire si ces derniers qui ont "les clés" ne sont pas d'accord de toute manière.

Je vois le process comme suit :

1) Livre blanc proposé par une ou plusieurs personnes qui décrit l'idée et appelle à des observations / à des volontaires

2) Livre vert : synthèse des échanges / liste des contributeurs du GT / mandat du GT

=> décision (avec un mix vote communautaire / vote du core ?)

3) Le GT produit une note de cadrage et un roadmap publics qu'il actualise pour recueillir les avis de la communauté.

Le GT doit pouvoir aussi coopter des intervenants pehndant la vie du projet pour compléter les compétences / remplacer les défections.

Oui, je voulais relancer ce point, mais par contre je ne suis pas d'accord avec "soutiennent ET sont près à y participer". Ce sont deux choses totalement différentes. Un groupe, pour justement avancer, ne doit pas contenir 50 personnes à priori. Et souvent quand on parle de monter un groupe pour lancer un chantier, c'est parce qu'on a déjà des gens intéressés sur le sujet : parce que le truc doit être faisable. On ne demande pas un accord, un mandatement, si c'est juste un truc théorique et qu'en fait personne n'est déjà intéressé, à mon avis.

Pour la question du mandatement, le plus gros point depuis le tout départ c'est : QUI mandate, et un peu comment, mais surtout qui.

Est-ce que c'est l'ensemble de la communauté ? Donc y compris n'importe qui qui peut s'inscrire et qui débarque ? Ou est-ce que c'est : les 25 personnes qui ont les clés du noyau et du site officiel ?

Je dis ça parce que le but du mandatement en amont pour tel ou tel chantier, c'est bien de dire : "oui c'est à vous de vous occuper de ce sujet, on va suivre l'avancement pour voir si tout se passer bien, mais à la fin on va ajouter votre résultat à la Dist, ou à tel site officiel". Du coup c'est un choix qui pour le moment revient aux 25 personnes qui ont ce droit là, par défaut.

Il faudrait déjà peut-être ajouter une mention sur la présentation du groupe SPIP général, pour prévenir de l'usage des groupes de travail, l'engagement qu'on prend quand on s'inscrit à l'un, et inviter à discuter de ça sur ce groupe dédié ?

Même si c'est en cours de discussion... ?

@chankalan pas compris ton message

@rastapopoulos
1. Ok sur ton premier point.
@tcharlss
ok également sur une seule étape

Effectivement la question de qui peut voter se pose, sous deux angles:
1. Le rapport communauté/noyau, comment on gère l'équilibre.
2. Qui fait partie de la communauté.

Concernant le point 1:
- A mon avis la priorité doit rester à la communauté. Le noyau pourrait avoir un droit de veto si un seuil de membres (1/3 ?) veut exercer ce veto. On pourrait définir ensuite un seuil, pas trop aux de membres de la communauté pour mandater le groupe. Par ex 10.

Concernant le point 2:
- Pour la communauté, on pourrait dire qu'est membre de la communauté toute personne qui remplit au moins l'un des critères suivants, il y a au moins un mois avant le début de la discussion sur la mandation du GT:
- Contribution sur la zone
- Contribution sur contrib
- Contribution à la documentation
- Contribution aux traductions
- Au moins x (2?) aides (y compris non fructueuses) aux utilisateur·trice·s sur les lieux d'échanges de SPIP:
- Listes diverses
- Forums
- IRC

Ceci permet de prendre en compte l'ensemble des apports à la communauté et ne pas limiter aux seul·e·s codeur·euse·s, tout en évitant que des boîtes, des admins, des gens qui font du SPIP dans leurs coins n'interfèrent dans les décisions collectives sans participer effectivement au "travail" commun.