Des équipes pour SPIP

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 :slight_smile:

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 :wink:

Le truc cool c’est qu’on va pouvoir se faire des beaux t-shirts d’équipe :slight_smile:

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.

Si tu a bien lu le fil, ça n’est pas qu’un changement de terme.

Un peu comme actuellement ou il n’y a que le core VS les autres ? Même si les personnes qui ont les droits de commit s’astreignent à passer par des PRs plutôt que d’envoyer direct dans une branche stable…

Est-ce que ça peut fonctionner pire ?

Gain de cause sur quoi ? Qui donc a participé à proposer des modifications au code de SPIP et corriger les bugs ces 5 dernières années par exemple sur le spip/* ? Tu as eu des PR refusées toi ? C’est quoi la peur ? que le logiciel évolue avec les gens qui y participent ? il faut qu’il reste avec ce code éternellement ?

Oui j’essaye de suivre et je n’arrive pas à voir de différence fondamentale avec ce qu’avait proposé @rastapopoulos à l’époque.

Bah là ça restreint assez fortement car la proposition est de ne garder que les commiteurs récents et non les auteurs, ce qui réduit encore plus l’équipe team/core.
Je ne suis peut être pas assez remonté dans le temps mais je compte 6 personnes qui ont commité soit en direct, soit via fusion. Dont 2 qui en toute logique auraient dû passer par fusion et donc être simple auteur. J’exclue les commits de traductions entre autre vu que le comitteur est un bot.

À la rigueur, sur ce point ça ne change pas grand chose sur l’existant mais cela ne présage rien sur la suite. Qu’est il prévu pour donner des accès à d’autres auteurs pour rélargir la base ? Ce qui semble être un des problèmes à la base de ces réflexions.

Et dans la propositions organisationnelle je ne vois toujours pas comment un arbitrage ente les différentes équipes pourra se faire.
Dire en substance on verra bien plus tard me gêne assez, je dois dire.

Je le répète je ne critique pas l’idée en soit, qui a ses avantages et ses inconvénients. Il me semble aussi inutile d’être en opposition car cela ne sera ni pertinent, ni utile.

Aucune idée. Et comme je l’ai déjà dit je ne remets pas en cause les questions initiales. C’est la suite qui me pose problème. Avec, entre autre, en substance : « bah on verra bien plus tard ».

Me concernant ? Probablement aucun refus car je n’en ai proposé aucune évolution du code. Mon périmètre contributif principal n’a jamais tourné autour du code du core.
Sur ce point il y a des personnes bien plus compétentes que moi et heureusement :slight_smile: Mon expertise, si je peux m’en targuer, s’est orientée sur d’autres aspects.

Et comme je l’ai dit à titre personnel, cela ne me changera pas grand chose. Je sais faire des PR et maintenir des forks au besoin si ça s’enlise.

Bien sûr il faut que le projet évolue, mais cela ne se résume pas à du code et du techno-centrisme. Et c’est ce point que je remets fortement en cause.
Il me semble que @erational l’a exprimé différemment en parlant de « dette éthique ».

Est-ce qu’il y a besoin que ça soit les mêmes personnes, celles qui veulent avancer sur du code & du techno, et celles qui veulent avancer sur d’autres sujets ? En quoi la proposition empêche d’avancer sur d’autres sujets ?

Ce que je pense lire en diagonale, c’est que la direction qu’on veut prendre sur le code (php essentiellement) (avec James notamment) fait peur, et que beaucoup de monde freine des quatre fers là dessus. Pourtant je crois que cette discipline qui a été amenée sur les commits / releases, et le découpage vers des modules Composer & Symfony est une bonne direction ; et ça va impliquer des changements d’habitudes encore certainement, qu’il va falloir accompagner. D’où aussi l’équipe «Architecture» pour parler de ça, discuter de ce qu’on a exploré, expérimenté déjà ces derniers mois.

Mais sauf à dire «il ne faut pas aller dans cette direction» et à ce moment là il va falloir l’argumenter fortement, surtout au vu de la faible participation des dernières années des personnes dans la maintenance du Core, je ne vois pas ce qui créerait de la dette éthique, empêcherait de l’entraide à côté, d’autres sujets…

Il faut surtout que des personnes portent et agissent sur ces autres sujets, donc y consacrent du temps… Si personne n’a de temps ou de motivation, merci de ne pas nous reprocher de vouloir prioriser les points qui nous motivent dans notre temps libre.

On cherche à voir qui est motivé·e et disponible à quoi… Ce n’est pas une question que de code quand même ; je ne crois vraiment pas que ça soit ce que l’on ait dit.

2 « J'aime »

Oui, voilà je rejoins totalement @marcimat. Je trouve cela d’ailleurs assez dingue qu’une proposition qui vise à créer explicitement des groupes qui font autre choses que du code, soit supposé être code-centrée (en intention ou en conséquence).

À ça, on peut aussi ajouter que la suspicion d’intentionnalité, si c’est une hypothèse comme une autre, pèse tout de même bien peu face à une autre hypothèse: c’est qu’on a parlé d’abord des choses qui avaient une existence un peu plus factuelle d’abord. La sécu, la maintenance, et donc les gens qui y participaient, le faisaient bon an, mal an, en équipe …

L’« équipe Archi », informellement, bah, avec @marcimat, ça fait tout de même quelques années qu’on propose des trucs techniques …

Donc, bon, voilà, la liste a été rédigée comme ça, en relecture, ça ne m’a pas choqué.

Maintenant, si on se prend un procès d’intention à chaque message, c’est pas bon pour notre moral. Si le mien vous importe peu, pensez à ceux de @marcimat et de @b_b qui ne méritent pas ça :wink:

En gouvernance partagée on a tendance à appeler ça des cercles, et chaque cercle est au même niveau. La cohérence d’ensemble est obtenue par des personnes pivots (c’est pas le terme exact mais je m’en rappelle plus) dans chaque cercle, chargée de communiquer du cercle vers l’extérieur (les autres cercles) et de l’extérieur vers le cercle lui même.

J’ai l’impression que cette proposition est surtout une formalisation de ce qui se passe de fait aujourd’hui : chacun n’intervient que peu ou prou sur les trucs qui lui tiennent à coeur et son domaine de prédilection et laisse le reste avancer.

Cette formalisation peut apporter l’avantage d’être moins impressionnante et de réduire le périmètre sur lequel les contributeurs se sentent de devoir s’investir, en évitant le sentiment de « il se passe trop de trucs, je peux pas suivre, et de toute façon j’ai qu’une toute petite pierre à apporter, ça servira à rien vu tout ce qu’il faut faire ». Alors que bon, chaque petite pierre à son utilité, et c’est sur cette pierre que… (RealET sort de ce corps !)

Aussi si quelqu’un le souhaite il peut tout à fait prendre part à l’ensemble des groupes/cercles pour garder un aperçu de tout ce qui se passe, et le travail de chaque cercle reste quelque chose d’ouvert au vu et au su de tous.

Donc je pense pas qu’il y ait vraiment de gros inconvénients à ce mode de fonctionnement, et en tout cas c’est pas du tout antinomique d’un fonctionnement collectif et partagé.

Et a contrario, si elle permet de fixer des périmètres et objectifs plus clairs pour chacun et que cela permet de redonner une dynamique de contribution, c’est tout bénefice, donc gogogo

5 « J'aime »

Ouf, j’étais un peu à l’étroit.

Dans certains cadres de gouvernance partagée (notamment sociocratie et holacratie), la personne chargée de communiquer vers l’extérieur est appelée « premier lien » et la personne chargée de recevoir les communications de l’extérieur est appelée « second lien » (évoqués par exemple dans ce gros PDF : https://www.reseautransition.be/wp-content/uploads/2015/03/Gouvernance-partagée-et-fonctionnement-en-Cercle.pdf, ou ici appliqué au byzness : L'Holacratie, comment ça marche ? - Agile, Lean et Compagnie )