Arno* souhaiterait libérer le contenu de l’orga 23Forward qui réunit ses contributions et les soumet à un régime très strict de participation.
Voici extrait-copie de son mail : « Je l’ai déjà indiqué …: je suis vraiment pour déplacer mes plugins dans le pot commun. Ce n’est pas moi qui les ai mis dans un truc 23Forward à part. Je crois me souvenir qu’ils ont fait ça parce que les modes d’ emploi sont sur mon site plutôt que sur spip-contrib. »
Serait il donc possible de déplacer les plugins de l’orga dans le pot commun et fermer l’orga truc-23Forward-à-part ?
On peut ajouter le groupe spip-contrib-extensions comme developpeurs/mainteneurs du groupe 23forward. Mais je persiste à trouver que c’est mieux qu’ils restent dans une orga distincte.
si tout le groupe contrib peut les modifier, quel fichu intérêt de les déclarer comme propriétés (beurk) d’une organisation/personne séparée ? no argument for the moment
à force de modifications successives, certains plugins peuvent finir par avoir autant ou plus de modifs par d’autres personnes que celle qui a créé au départ, donc oui c’est un projet collectif
j’imagine si à l’époque j’avais mis un ldd/formidable ou mukt/formidable, alors que Maïeul a fait mille modifs ensuite, ça n’aurait aucun sens, c’est conçu dès l’origine pour être un plugin collectif, central et générique, que tout le monde peut améliorer ensuite, sans pousser les gens à faire des forks dans leur coin ou à créer des plugins différents pour le même besoin (comme chez WP où ya 50 plugins par même besoin).
Là on a par ex UN plugin dans la communauté pour définir le focus des images (centre image), il est collectif et unique, et c’est très bien, que ce soit Arno* ou Tartempion qui l’ait inventé au départ (ça reste bien mentionné dans les auteurs et crédits, aucun soucis pour ça). Du coup pareil pour les autres plugins.
Pour rappel, on avait dit que ça avait surtout un intérêt ponctuel quand pour des cas très précis, notamment par sécurité plus forte, on doit restreindre qui participe (typiquement : nursit/bank)
Pas d’objection à ce que tout ou partie de 23forward revienne dans spip-contrib-extensions.
Cependant, je rappelle quand même qu’aucune documentation de ces plugins là ne vit sur contrib.spip.net (donc les contributeurices ne peuvent mettre à jour cette doc, autre que Arno*) et leur Readme ont été ajoutés par James dans les dépots. Le côté communautaire est au moins partiellement discutable. Ça ne me gène pas outre-mesure mais sachons le quand même.
à partir du moment où le code redevient collectif, fatalement : le XML aussi, donc le lien vers la doc, qui peut donc changer pour un article de contrib (en plus des readmes qui peuvent être complétés)
il faut vraiment que je répète ce que tu sais déjà ?
Arno* te l’a dit, marcimat l’a rappelé ici : Ces plugins ont leur particularité, leur doc est hébergée sur un site perso. Ça justifie une orga spécifique. Orga qui n’est pas propriétaire, n’est-ce pas … faire des PR pour toustes est possible depuis le début, personne n’a jamais pris l’initiative de produire de la doc dans un espace « licite » pour ces plugins : Les inepties habituelles pour droitiser les initiatives qui n’entrent pas dans le cadre bien délimité de la pensée d’un seul, j’espère que plus personne n’est dupe.
Au pire, faites de 23forward une sous-orga de spip-contrib-extensions, why not. Tous les membres du « groupe » spip-contrib-extensions, très inorganisé, ne communiquant plus entre eux, sont déjà considérés comme « developpeurices » de 23forward.
Je vous recommande à toustes d’étudier tout ce qu’on peut faire avec une plate-forme git plutôt que de continuer à faire semblant qu’on est toujours sous subversion.
il n’y a rigoureusement aucune raison de copier la doc ailleurs tant que justement le code est pas encore commun, donc mille fois logique que personne ne l’ait fait… Une fois mis en commun et donc lien de doc changé seulement après, l’argument ne tient donc plus.
on sait à peu près tous parfaitement utiliser Git, cette condescendance… on l’utilise pour beaucoup en contexte pro de manière très cadré avec des PR relue, des CI, etc : sauf qu’il n’y a aucun rapport entre avoir une discipline commune de pas commiter dans master et faire des PR, et être propriétaire d’un dépôt officiel (protip : c’est 90% ce que font déjà tous les plugins malgré les droits pour tous depuis un moment déjà), càd
avoir le droit de créer des branches de dev dans le même dépôt,
et donc avoir le droit de compléter/améliorer les branches de devs des autres sans devoir créer d’autres branches de devs forkant des branches de devs…,
et avoir le droit de fusionner quand plusieurs ont relu (ou quand il n’y a pas de réponse pendant X semaines).
Bref : on sait globalement parfaitement faire des PR à relire par nos pairs sans être bourrins même quand on a tous les mêmes droits (#infantilisation), merci bien du conseil. Mais aucun rapport avec les droits communs donc.
Yop, « ce qu’on peut faire avec une plate-forme git » != « ce qu’on peut faire avec git »
il n’y a rigoureusement aucune raison de copier la doc ailleurs tant que justement le code est pas encore commun, donc mille fois logique que personne ne l’ait fait
Sur ce point : le code était commun depuis des années, la migration des plugins en questions vers l’orga spécifique est plutôt récent, donc il n’y a pas à argumenter là dessus.
Tu es très assertif mais selon quelle logique est-ce que « ça justifie » ? Car ranger dans une « orga » n’est pas juste décoratif comme coller un postit ou ajouter un motclé : il y a des conséquences opérationnelles puisque ça restreint les droits des autres inscrits sur gitlab.
Alors peux tu expliquer ton cheminement entre le factuel « Leur doc est hébergée sur un site perso. » et la justification d’autorisations différentes pour l’accès au code et à ses modifications ?
Ya d’autres passages de ton post dont je ne comprend rien du tout ou pas grand chose, ou qui semblent aller dans le sens de ma demande. Par exemple tu dénonces « le cadre délimité de la pensée d’un seul » mais n’est ce pas l’initiative d’un seul, justement (et pas Arno*), qui a amené la création d’une orga 23Forward ?
Par contre je suis d’accord quand tu parles de l’orga des orgas et sous-orgas et du fait que c’est mal connu et ça n’aide certainement pas au bon fonctionnement. Ceci dit, le « très inorganisé, ne communiquant plus entre eux » ne sera pas magiquement guéri par des fonctionnalités technoïdes.
J’ai des PR en attente de validation sur d’autres plugins : elles ne trouvent pas d’écho, mais ce n’est pas à cause des qualités ou défauts de gitlab et de la bonne ou mauvaise connaissance de ses fonctionnalités avancées.
Concernant 23Forward, bien que n’intervenant pas dans les discussions, Arno* a tout de suite validé mes 2 PR. J’en ai d’autres prévues sur centre-image alors peut être continuera-t-il à répondre promptement (merci !) mais je trouve dommage et pesant de dépendre de son emploi du temps comme ça.
Les contributeurs ne peuvent pas altérer la doc sur le site en question, ça limite les évolutions possible, et peut-être à dessein.
En plusieurs années d’existence, personne n’a pris l’initiative de produire une doc alternative sur contrib pour ce lot de plugins, contrairement à tous les plugins communautaires historiques.
De fait, cela teinte les plugins 23foward d’une certaine spécificité, qui était totalement invisible lorsqu’ils étaient dans l’autre orga.
C’est d’ailleurs explicite ici 23forward · GitLab et comme tout groupe (on le fait pour spip et spip-league) on pourrait l’agrémenter d’un README commun.
Il n’y a pas de différences : les membres de l’orga spip-contrib-extensions sont « developpeurices » de l’orga « 23forward ». Aucune différence. Sauf concernant la doc.
Je dis qu’il est regrettable d’appliquer une stratégie de développement obsolète, fondée sur des outils centralisateurs (svn, redmine) qu’on n’utilise plus, et surtout que des propositions de tirer profit de ce que permet gitlab (décentralisation, délégation des responsabilités, fonctionnalités plus pratiques, etc.) soient systématiquement rejetées par des arguments dogmatiques et assertifs, eux aussi.
Je préfère
à
Il est évident qu’en qualifiant, avant toute question, les choses de manière péjorative, comme des bizarreries, ou en les politisant comme des « trucs de droite » comme d’autres peuvent le faire, ça devient difficile de discuter.
Toutefois, merci à toi de faire preuve d’un peu de curiosité.
@Glop semble avoir compris instinctivement qu’il y avait une logique
Comme quoi hein.
Du coup, pour ses autres PR (et les quelques plugins que j’avais déjà configuré pour ça), je proposerais bien une nouvelle orga pour les plugins composerisés, avec outils de QA etc. genre spip-contrib tout court, mêmes règles d’accès que pour 23forward, etc., de la ci…
Petit témoignage/retour d’expérience qui montre que ça n’est pas forcément bien d’avoir 538 personnes avec le rôle « Developer » sur un plugin de spip-contrib-extensions.
On nous a remonté deux failles de sécurité sur le plugin GIS il y a 4 semaines (corrigées depuis). Les tickets concernés sur le repo de GIS étaient en mode « Confidential » qui indique « Only project members with at least the Planner role can view or be notified about this issue. ». Ce qui veut dire que depuis 4 semaines, 538 personnes avaient accès au descriptif des failles et auraient pu au choix les faire fuiter ou les exploiter.
En gros, tu voudrais une orga avec moins de dev et de mainteneurs pour gérer une collection de plugins « thématiques » ou avec des règles communes ? avec des personnes en tête pour constituer une équipe ?
Ou bien est-ce que c’est la config du Gitlab qui n’est pas la bonne ? J’ai l’impression que c’est une limitation de la forge utilisée : on dirait qu’ils n’ont pas prévu de permettre de personnaliser qui (= la liste des rôles) qui ont accès aux « confidential », et qu’ils ont mis une liste en dur dans le code que tout le monde doit accepter.
Alors qu’on aurait parfaitement pu vouloir et dire que les devs ont le droit de coder (faire des branches internes etc), mais que pour la sécu les tickets explicitement « confidential » seraient uniquement pour les « owners » et « maintainers ».
Car il n’y a aucune raison obligatoire à bloquer totalement les droits (et ne plus pouvoir faire que des PR) uniquement pour bloquer les « confidentials » qui sont un total autre sujet.
Si si j’ai testé : on hérite par défaut du rôle qu’on nous a donné dans l’organisation parente. Mais ensuite projet par projet dans cette même orga, on peut parfaitement définir un rôle supérieur à celui par défaut dans l’orga.
Donc
si je suis « juste dev » dans l’orga, je peux être « mainteneur » ou « propriétaire » d’un dépôt précis
si je suis « mainteneur » dans l’orga, je peux toujours être « propriétaire » d’un dépôt précis
Donc au niveau des droits assignés à chaque personne une par une : on peut bien être fin et dire que pour tel plugin, telles personnes (ça peut être plusieurs) sont « mainteneuses » ou « propriétaires »… sans pour autant bloquer les devs, donc très bien. Ce n’est pas un soucis.
Le seul problème, c’est cette connerie de Gitlab qui ont hard-codé spécifiquement les droits des tickets « confidential », alors que plein d’autres fonctionnalités on peut personnaliser qui peut y accéder. Un peu nulos…
