On peut continuer à en discuter encore un peu ici, sur des questions de forme, oui.
De réglages quoi.
Mais j’ai l’impression que sur le fond il y a déjà un consensus qui s’est exprimé (on arrive déjà à la vingtaine de votants et pas un seul avis contre), et très rapidement, et que les équipes proposées se remplissent, c’est plutôt positif ça non ?
Un fork facilite le merge ? Par rapport à une PR sur le dépôt source ? Tu m’expliques ?
Pour moi ce sont deux sujets différents.
Autant je pense que séparer [UX + accessibilité] et [UI], comme je l’envisageais à un moment, serait contre productif, au début au moins, autant je pense que [Animation] et [Communication] (ou [Visibilité] pour éviter un gros mot ^^) mériteraient d’être bien séparées.
D’ailleus, dans [Animation] est ce que Gérer l’éditorial de Spip Contrib ne serait pas mieux atrribué dans [Documentation] ?
Probablement pour contrib ; y a de la latitude… même «Formation» déjà c’est pas si évident, mais ça va bien avec organiser des rencontres…
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:
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:
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…
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 :
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 :
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 :
Ç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
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…
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 »
@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
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 ?
On en causait déjà ici Mini CR d’une rencontre en juillet 2023 - #8 par rastapopoulos