Bon, et puis ce point là en particulier, c’est un ajustement qui peut venir à l’usage, comme d’autres.
L’essentiel, je crois, c’est de se mettre d’accord sur une liste de groupes et leur matérialisation (à quel endroit dans Discuter).
Laissons nous encore une ou deux semaines de discussions.
Bonjour à tous,
Je commencerai par dire que je suis plus que ravi:
- et de suivre – du moins partiellement – les évolutions majeures tant sur le « dépoussiérage » du core que sur la mise en place d’outils « modernes » tels composer;
- et de voir cette démarche de renouvellement de l’animation globale du projet.
Mais je dois bien avouer que si j’écris aujourd’hui, ce n’est pas sans certaines appréhensions aussi, qui m’ont éloigné de certaines discussions précédentes: difficile en effet de se sentir légitime parfois, d’autant plus lorsque l’on touche à des sujets qui ont trait à l’historique et aux fondements de SPIP.
Souvent sont rappelées les valeurs de SPIP, la philosophie sous jacente, et, sans les connaître forcément toutes ou la maîtriser totalement, il me semble que l’important est qu’elles vivent à travers le projet et sa communauté. Ce que j’essaie de dire, maladroitement sans doute, c’est qu’à mes yeux, la fin poursuivie doit bien être la longue vie de l’outil SPIP et de sa communauté, un gage de pérennité pour tous ceux et toutes celles qui font le choix de SPIP.
Et que cette fin peut appeler une réflexion sur les moyens à mettre en œuvre sans pour autant perdre son âme: un ami, avec quelques kilomètres au compteur et son lot d’expériences, pose souvent la question « qui nettoie les chiottes ? »… Si ce sont toujours les mêmes, alors c’est qu’il y a un problème… Des règles communes, une structure… ne sont pas antithétiques d’une organisation anarchiste, au contraire.
Bien que fréquentant SPIP et sa communauté depuis de longues années, j’ai toujours perçu le core comme une entité peu visible, peu reconnaissable, hormis certains contributeurs. La proposition ici débattue me semble intéressante à plus d’un titre:
- solliciter les expertises et le temps des un•e•s et des autres plus finement, de manière plus focalisée, permettant de limiter leur charge;
- rendre plus visible les travaux qui peuvent être entrepris sur divers sujets ;
- puisqu’il est question de communication, rendre plus visible le vivier de la communauté : plus nous serons nombreux•ses, plus la confiance en la pérennité de l’outil sera renforcée et donc à même d’en faciliter le choix et de donner envie de s’investir dans la communauté ;
- permettre de s’engager progressivement, en fonction de ses compétences, de ses envies, et permettre aussi un apprentissage progressif de SPIP;
- …
Pour finir, je serai ravi de m’investir, du moins d’essayer, dans un ou deux groupes pour commencer ; je vais passer au vote 
Et désolé d’avoir été si long…
6 « J'aime »
Ce sont deux choses totalement différentes : les PR c’est un concept de la forge et qui se fait toujours sur le projet où on veut voir fusionner sa proposition MAIS une PR se fait depuis n’importe quelle branche de n’importe quel dépôt !
Pour générer cette PR il y’a donc deux possibilités :
- soit tu as les droits de commit sur le dépôt source et tu peux créer une branche dédiée en interne
- sinon forcément tu dois forker le projet et générer la PR à partir de ton fork (mais plutôt d’une branche dédiée au dév quand même)
A l’origine la galaxie SPIP n’avait pas d’hierarchie, tout état « plat » et accessicle à tous et toutes (j’insiste, car on compte toujours trop peu de femmes parmi nous).
Avec l’introduction d’une véritable hierarchie on risque deux problèmes :
- On se complique la vie (le maintien technique etc.) et on n’est jamais à 100% d’accord sur la signification de chaque èlément et niveau de l’hierarchie.
- On introduit, qu’on le veuille ou non, une couche supplémentaire dans les niveaux d’acceptation / de réputation et de gratification pour les nouveaux membres de la communauté.
Je suis pour la structure proposée car les listes SPIP me manquent, mais je pense qu’un maximum de transparence, l’égalité parmi les membres de la communauté et beaucoup de rencontres personnelles forment l’humus sur lequel le projet SPIP pousse le mieux.
:-)k++
Il faut pas confondre « structure » et « hiérarchie ». Ce serait pas faire un cadeau à SPIP que de la restreindre à un chaotique bordel instructuré.
Et croire que c’est un changement essentiel serait méconnaître le fait qu’il y a toujours eu dans SPIP des privilèges du côté des droits informatiques à faire ci ou ça. Souvent ça allait de paire avec la responsabilité de gérer et le devoir de corvée. Jusqu’à présent, les accès des uns ou des autres à telle ressource informatique sont dans un document à accès restreint et la liste même des personnes ayant accès ce document est non publique. C’est le genre de chose qui peut induire, potentiellement, des rapports pas cool voire une hiérarchie ou une appropriation du projet (à terme par un GAFAM lol).
Rendre visible la structure, la formaliser et la documenter, c’est très bien. Ça permet d’interagir, se positionner, s’inscrire dedans, et aussi voire les éventuelles trop grandes dépendances à une personne et les fragilités induites (maladie, décès, mauvaise humeur, égo affamé, épuisement, etc). Et équilibrer, compenser, limiter, aider, assister - selon.
Et puis dans un groupe horizontal, quand on définit des référents, on veille bien à indiquer « le référent est la personne à qui s’adresser. Elle s’assure du suivi d’une tâche, mais elle n’est pas responsable de la bonne réalisation de la tâche. C’est tout le monde qui l’est. »
Les groupes de travail doivent permettre à des personnes qui n’en font pas partie :
- de s’informer sur ce que l’équipe fait (CR réguliers : chaque trimestre ? dans chaque lettre SPIP ? ),
- de participer à la tâche : pour ça il faut facilement pouvoir s’informer sur les chantiers en cours, et documenter comment/à qui proposer de se charger d’un chantier, comment apporter un regard ou une contribution ponctuelle…
Ça me rassure qu’il y a des groupes de travail identifiés qui veillent à certains aspects de SPIP
Pour participer j’ai besoin de sentir que ces groupes sont sympa et inclusifs, et par exemple qu’on s’y fait pas dézinguer parce qu’on a pas respecté telle ou telle norme informatique ou socio-culturelle.
Et globalement je pense que le fonctionnement global serait plus dynamique si la large communauté SPIP est au courant de ce que font ces groupes et s’il est facile d’interagir et contribuer à ces groupes de travail même quand on en fait pas partie
#référents #groupedetravail #horizontalité #participation #visibilité #ouverture #lien #information #responsabilité #vision
5 « J'aime »
L’idée n’est pas d’introduire une hiérarchie, il n’y a pas d’équipe au dessus ou au dessous d’une autre.
Quand on a élaboré cette proposition d’équipes, le souhait était de permettre à des personnes qui ne se sentent pas légitimes (cf le post de @bricebou) de s’impliquer dans la communauté sur des tâches précises, et pour la durée qu’on souhaite. Ce qui peut être plus rassurant que de se retrouver embarqué à vie dans un truc qui s’appelle le core et qui doit « tout faire » (sans qu’on sache vraiment ce qu’est ce « tout »). Bref, je pense que ça peut faciliter (démystifier ?) l’engagement dans la communauté.
La mise en place de ces équipes permet aussi de dresser la liste des tâches de la communauté (pour leur donner de la visibilité), et de signaler là où on manque de forces vives afin de donner envie aux personnes volontaires de s’impliquer cf le post Mini CR d’une rencontre en juillet 2023.
J’ai beaucoup réfléchi à ça pendant les deux dernières années, je peux partager les réflexions qui ont fait germer cette idée d’équipes si ça intéresse des gens, faudrait juste que je trouve le temps de poser ça au propre…
1 « J'aime »
Merci
On parle bien d’équipes, pas de groupes de travail 
Pour aller dans le sens de @jluc et de @b_b, outre le fait qu’avoir des tâches précises permettra, je l’espère, à plus de gens de se sentir légitime, j’avoue que j’ai du mal à comprendre comment le fait de passe de « un petit groupe avec plein de privilège » à « plusieurs groupes avec chacun des rôles / missions différentes » peut être être percu comme « l’introduction d’une véritable hiérarchie »
2 « J'aime »
@rastapopoulos je t’invite à relire le poste de @JamesRezo qui explique à @nicod que le fait de préferer le forke à la création de branche au sein du même projet est
Parce que ça facilite la gestion du merge, entre autres…
Des équipes pour SPIP - #35 par JamesRezo
Et du coup la question de @nicod, que je rejoins sur ce point, est « en quoi cela facilite la gestion des merges d’avoir des forks plutot que des branches ».
Je crois que James à répondu à autre chose en fait… parce que oui, pouvoir avoir la branche de PR dans le projet cible directement ça facilite pour les mainteneurs du projet la gestion des rebases / merges…
Notamment quand les gens à l’origine de la PR n’ont pas écrit correctement les logs de commits, les changelog, etc… et qu’iels ne veulent pas le faire, ou rebaser… Mais il faut bien voir que du coup, c’est du temps qui est alors pris sur les mainteneurs (refaire une branche dans le projet, en réécrivant les commits, nouvelle PR…). Le mieux est tout de même que les gens se forment à utiliser Git et nos conventions ; tout le monde n’a pas à avoir un accès écriture sur « spip » juste pour pouvoir faire des PR, ça n’a pas trop de sens.
Je pense qu’il y a juste un quiproquo, je t’invite à relire la question de tout départ qui était « Pourquoi la doc… ».
La documentation s’adresse au grand public, pour leur expliquer comment proposer des PR. Ça n’évoque évidemment pas les quelques bien plus rares personnes qui ont les droits sur le dépôt source, et qui savent parfaitement déjà quoi faire, et qui elleux peuvent créer des branches internes au projet source.
Donc oui : la doc n’évoque QUE les forks, parce que tout simplement le grand public ne peut QUE faire des forks pour proposer des PR, tout simplement.
je crois que ces fils deviennent trop entremelés pour en discuter simplement ici, et je propose de laisser cette question de côté pour l’instat pour se concentrer sur la question des équipes. On verra ensuite les modalités pratiques de PR
1 « J'aime »
Je ne perçois pas le sens de ton intervention. Peux tu expliciter ce que tu veux dire = quelle différence vois tu ?
Ça n’est qu’un rappel sur le fait que je préfère qu’on utilise le terme équipes et pas groupes afin de différencier les équipes des groupes de travail, rien de plus
Parce qu’il y a des « groupes de travail » aussi ? Lesquels ?
Le truc cool c’est qu’on va pouvoir se faire des beaux t-shirts d’équipe
1 « J'aime »
+1 avec tout ça.
A une époque, certains (au sein de le team) parlaient de « tuer la team ».
Je crois que son heure est venue de rendre l’âme (à qui elle appartient).
+1
Ça aussi c’est une pratique qu’ont beaucoup de projets libres, et c’est une très bonne chose.
Par exemple pour savoir qui joindre pour discuter de tel ou tel problème.
Et surtout avec un appel à rejoindre, car des gens comme @bricebou ont absolument toute légitimité, et sans rougir.
Je pense aussi à d’autres personnes, mais je ne les nommerais pas, par pudeur.
Ce sera bien le cas : les discussions des équipes se feront dans des groupes ouverts et publics, ici, sur Discuter (sauf pour les aspects sécurité bien sûr).
Tu me fais bien rire jaune.
Toi aussi tu as de sacrés œillères.
Devant le fait accompli, je devais faire quoi ? Quand vous démontrez que ce n’était pas une discussion, montrez qu’au moment de l’annonce la migration était déjà faite à plus de 90%.
De plus quand il a été indiqué que c’était peut être un peu court en délai, cela n’a pas posé de problème à garder le service existant actif.
Vous avez voulu avancer au pas de charge, c’est votre choix. Pas de communication, pas d’accompagnement à la transition, soit.
Dans ce cas je n’avais aucune raison de chercher à maintenir l’eau du bébé. Et m’infliger une douleur supplémentaire. Le sparadrap on l’arrache une bonne fois pour toute.
Assumes, au moins vos décisions et la façon dont le tout s’est passé.
Edit:
Pour revenir au sujet, groupe de travail déjà testé ou équipe en pratique je ne vois pas du tout la différence. Je ne vois pas en quoi cela fonctionnerait mieux en changeant l’intitulé.
Et si de fait ça concentre la hiérarchie, car seules les personnes restreintes avec droit de commits auront gain de cause peu importe les décisions des équipes.