On peut effectivement élargir ce débat aux autres groupes historiques spip-contrib-themes et spip-contrib-squelettes … c’est le même constat, les mêmes pratiques et j’imagine, le même argument « politique » …
Avec, ceci-dit, moins de projets git et pas exactement le même nombre de personnes historiquement membres. Allez savoir pourquoi.
Hello
Comme l’indique @rastapopoulos, en effet avec gitea on affectait systématiquement les nouvelles personnes au groupe « spip-contrib » qui avait des droits d’éditions élargis sans être pour autant de type propriétaire. Ainsi les droits étaient identiques car on travaillait au niveau du groupe et non du compte.
Et on a fait évoluer les droits du groupe en fonction des contraintes identifiées au fil de l’eau.
L’approche horizontale était acceptée/voulue à l’époque de SVN, puis défendue lors de la bascule à Git/gitea. Cette horizontalité est un choix assumé lors de la bascule vers git et faisait partie du cahier des charges lors de la migration. (ce pourquoi certaines forges git ont été exclues)
Sur l’organisation actuelle avec gitlab , il semble que l’approche est autre et ce qui a été décidé en petit comité est une approche verticale. Et cela inclus, à mon sens le concept de groupe tel que mis en place.
@JamesRezo git ne coince pas en l’état. C’est un choix « politique » lors de la migration à Gitlab de passer sur ce mode de fonctionnement.
Ce qui est au passage était une des alertes remontée lors du gros coup de balai de début d’année.
Donc exposer ceci maintenant de cette façon me semble assez étrange.
Est-ce qu’un⋅e maintenaire peut faire des trucs irrécupérablement irréversibles ?
Je disais plus haut :
Plus précisément pour les repos Permissions and roles | GitLab
On peut y lire pour qu’une personne maintainer peut « Delete protected branches ».
Je vous laisse lire tout ça en détail, j’arrête là mon TLDR 
Hello
Les profils de type mainteneur, propriétaire ont des droits assez (trop ?) élargis. Il est préférable d’éviter de les attribuer sans garde fou.
L’avantage de git c’est qu’on peut (quasi) toujours reprendre/restaurer/réparer un dépôt mais pas forcément sur les parties MR/PR/tickets qui sont propres au fonctionnement même de chaque forge et donc de leur système de sauvegarde et maintenance.
Du coup un ‹ administrateur › peut faire des actions irrévocables ce qui peut être problématique selon les cas.
Je vois qu’il y a déjà des groupes qui ont été créés.
Quand on demande à temporiser cette façon de faire parce que, pour certains, ça ne va pas, autant pisser dans un violon.
Et donc, le plugin centre_image a été déplacé dans le groupe 23Forward https://git.spip.net/23forward et on ne le trouve plus par une recherche.
Déjà, pour chercher (en théorie) dans tous les groupes, il faut penser à aller, à gauche, sur projets, et pas dans spip-contrib-extensions.
Mais de toute façon, cette recherche globale ne remonte rien :
https://git.spip.net/dashboard/projects?name=centre
Il faut donc savoir dans quel groupe le plugin est rangé.
Ce qui n’est pas non plus évident parce que la page principale des groupes (https://git.spip.net/dashboard/groups) ne les montre pas.
Là encore, il faut aller à droite cette fois sur « Explorer les groupes ».
Alors c’est peut être (j’espère) juste un problème de config / visibilité du groupe, mais ça confirme ce que je pense (du mal) de cette balkanisation, où chacun fait son truc dans son coin avec sa visibilité et ses règles.
Franchement, autant se le faire sur github son groupe hein, pour bénéficier de l’effet réseau social…
Et pourtant, le groupe 23forward est bien public :
Et même punition pour le groupe Seenthis aucun résultat lors d’une recherche globale sur un de ses plugins, microcache :
https://git.spip.net/dashboard/projects?name=microcache
Au temps pour moi, je ne suis pas sûr que ce groupe ait été créé récemment (?) mais je n’arrive pas à voir la date.
J’ai souvent peiné à trouver ce que je voulais sur git.spip.net, indépendamment des nouveaux rangements.
Par exemple, en partant de la page d’accueil https://git.spip.net, la grande zone de saisie de la recherche n’est pas la bonne (elle ne cherche que dans mes espaces), il faut utiliser la petite zone de recherche dans la colonne gauche.
spip_loader il trouve tout de suitespip/forum apparaît en dernière position.statistique, centre_image au passage et pour plein de noms de repo de la dist.Ce serait bien de booster le référencement de la dist.
Et dans quoi cherche t il donc spontanément, si ce n’est dans « tout gitlab » ?
Comme le dit @JLuc depuis https://git.spip.net/ à gauche dans "Search or go to… "
Taper « centre » et valider renvoie bien vers centre · Rechercher · GitLab qui affiche bien le repo en question.
On peut donc se passer de lire cette pointe inutile 
Exactement, ça ne cherche que dans « tes espaces » et c’est bien indiqué dans le haut de la page :
On peut changer la page affichée par défaut pour les gens connectées, reste à voir s’il y en a une plus utile que celle en place à ce jour. Toutes les propositions réalisables sont les bienvenues
Je n’avais jamais vu cette boite de recherche, qui ressemble plus à un bouton qu’à une zone de saisie, et je dois pas être le seul.
Et une première recherche ne donne rien, il faut cliquer sur « Tout Gitlab ».
Vachement ergonomique tout ça.
Et oui, je suis de mauvais poil, pour changer,.
Malheureusement non.
Depuis Connexion · GitLab la liste déroulante de choix de la page d’accueil n’a pas « Tous les projets ».
Alors, il y a « Projets favoris », mais ça ne permet pas d’avoir automatiquement les éventuels nouveaux projets.
Et dans Connexion · GitLab, je fais partie de 5 groupes :
Mais groupes et projets, ça n’est pas la même chose.
Bref, je ne trouve pas comment avoir tous les projets en page d’accueil.
Je ne sais pas à quel message tu réponds, mais personne n’a parlé de " Tous les projets" dans le fil.
Je sais pas… arrêter d’individualiser à tout va, et ne faire des dépôts séparés dans un autre groupe que « extensions » seulement hyper ponctuellement pour des raisons précises et argumentées, par ex de sécurité (plugin Banque, etc), mais pas juste pour des histoires de chacun chez soi ou de ptit plaisir personnel ?
Comme on le voit, la proposition « c’est possible, tous ceux qui veulent peuvent le faire », a ouvert la boite de Pandore, et paf ça commence vraiment.
Que l’interface de la forge soit ergonomique ou pas (ce n’est déjà pas trop le cas), ne change rien au principe de base : ya aucune raison pour que 99,9% des plugins fonctionnels soient ailleurs que dans « spip-extensions », en commun.
Là par ex pour centre_image, qui fait partie des plugins pas mal utilisé, si ya qu’une unique personne qui peut relire, valider, et intégrer les PR… comparé à ces dernières années ou plusieurs personnes ont corrigé régulièrement des choses dessus…
Tout ça est vraiment un retour en arrière, ou une fuite en avant peut-être. Le Progrès (de l’individualisme). Pour moi c’est vraiment copier « l’ambiance » de github, versus les choix collectifs et au plus possible égalitaires (modulo rares exceptions) qui ont toujours prévalu (pour de bonnes raisons).
Toujours les même qui râlent (je me mets dedans hein).
J’ai mis un moment à trouver la configuration de la page d’accueil sur les préférences, j’ai dû m’y reprendre à plusieurs fois en regardant la capture écran.
Et pas trouvé non plus comment avoir « Tous les projets ». Ça ne semble pas prévu.
Et donc, dans quoi cherche t il donc spontanément, si ce n’est dans « tout gitlab » ?
C’est pas si souvent mais voici un exemple de difficulté : je ne sais où est l’écran de sécurité et la recherche n’est d’aucune aide avec « ecran_securite » ou « ecran » : la recherche de la colonne gauche ne renvoie rien, et même la poursuite de « ecran » dans « all gitlab » ne trouve rien.
Finalement je trouve en cherchant « secu » : car le dossier s’appelle « securite ».
https://discuter.spip.net/t/correspondance-des-noms-des-plugins-dist-avec-le-nom-de-leur-depot-git étant fermé, je poste ici :
faudrait il pas faire correspondre le repo « securite » avec le nom de son fichier php unique « ecran_securite » ?
