prefix : prefix du plugin et lien vers le dépôt git
spip_compatibility : bornes trouvées dans le fichier paquet.xml de la branche par défaut (master le plus souvent, a priori la branche la plus « à jour »)
sites : le nombre de sites qui utilisent ce plugin, pas nécessairement dans sa dernière version, parmis les sites vérifiés
spip: versions spip des sites utilisateurs si sites>0
last_commit : date du dernier commit dans le dépôt
Petit conseil : si vous êtes un·e des mainteneureuses de l’un de ces plugins (c’est pour toi @Fa_b ^^), faites un petit commit dedans … trois fois rien, créez/éditez un fichier README.md/CHANGELOG.md/paquet.xml … ou dites-le ici en commentaire
Merci pour ce nouvel état des lieux, et pour tous les autres
Alors, je vois dans la liste curriculum: je doute que ce plugin soit utilisé, j’avais produit ça il y a un petit moment, surtout par curiosité… Je crois que je m’en vais le faire disparaître…
si tu préfères le supprimer, pas de soucis, je te laisse faire.
il peut être archiver, par tes soins ou :
sans modification dessus, je l’archive avec une moulinette pour un traitement de masse, avec les autres plugins qui seront dans le même état … j’ai pas de date, je peux ne pas le faire, … j’attends d’autres retours.
Mais un petit commit dans les jours qui viennent, ne serait-ce qu’une checkbox « passer en 4.* » dans la partie TODO du README, ce serait super (ça me permet, au mininum, de mettre à jour le tableau en local que j’actualise tous les jours)
alors la solution « on peut passer maintener les developper` qui en expriment le besoin » m’irait assez bien…
Autre alternative (mais je ne sais pas si c’est possible de configurer Gitlab pour que ça fonctionne ainsi) : tout developper qui initie un nouveau repo devient maintener comme ça il pourra gérer
ça ne me semble pas une charge « d’occupation » insurmontable : on parle de peut être 2 ou 3 demandes par mois grand maximum non ?
Alors lorsque quelqu’un le demande sur IRC/Discord ou via Discuter ce n’est ni compliqué ni long à faire
(à priori ça prendra moins de temps que la suppression des requêtes des bots qui postent des demandes de comptes sur le Gitlab !)
Moins que ça à ce jour, sauf si ça se popularise. On verra …
Il y a aussi tous les autres groupes spip-contrib-*, des groupes déjà constitués (seenthis, giseh, spip-league, spip, bien sûr, et d’autres à venir, peut-être, comme spip-edu, par exemple)
Il y a aussi les demandes d’accès via l’interface web
Si quelqu’un te demande de créer un groupe git, tu le fais ?
Si une personne ne sait pas que c’est un pb de rôle qui l’empêche de faire ce qu’il souhaite, tu lui suggères ?
Y a un peu tout ça à démocratiser, faire de la comm’ dessus, quelque soit la/les solutions jugée(s) acceptable(s)… faudra que des gens s’en occupe
(Je dis « tu », mais ce sont des questions/remarques valables pour tout le monde )
