Certains l’ont peut-être remarqué mais la page d’accueil de Contrib a été enrichie d’un bouton bleu « Commencer à contribuer » dans la zone navigation.
Ce bouton renvoie vers une page d’inscription qui aujourd’hui se limite à la forge SPIP (Gitea).
Le formulaire propose de remplir le username (qui sera le login) , l’adresse email et demande à approuver la charte.
Si tout est ok, la demande est stockée pour qu’un admin de Gitea fasse l’ouverture du compte.
Fonctionnement du formulaire
Quand quelqu’un saisit le username et l’email, le formulaire vérifie outre la syntaxe, deux choses:
que la demande n’existe pas déjà
que le compte n’existe pas déjà (soit le login, soit l’email).
Si c’est le cas, il refuse la demande et prévient la personne du pourquoi.
En particulier, les gens qui ont oublié qu’ils avaient un compte (ce qui s’est passé plusieurs fois ces derniers jours) le sauront.
Si la demande est acceptée je propose d’envoyer un mail sur spip-dev pour prévenir les admins avec comme émetteur un terme générique comme spip-contrib et un sujet « demande d’inscription ».
Fonctionnement interne
En interne, la liste des demandes est affichée dans un dashboard spécifique à Contrib.
Les admins autorisés peuvent alors accepter ou refuser la demande.
Si l’un d’eux accepte, le compte est automatiquement créé sur la forge avec la bonne liste d’organisations accessibles. La personne ayant fait la demande reçoit un mail de Gitea pour lui demander de changer son mot de passe (pas encore disponible).
Si un admin refuse, la personne reçoit un mail de refus mais je n’ai pas encore trouvé de raison pour un refus sauf le spam (pas encore disponible).
Pour aller plus loin
J’ai l’impression qu’on pourrait aller plus loin. Les idées:
ajouter un captcha dans le formulaire ou alors Nospam suffit (mais faut le configurer non ?)
regrouper d’autres inscriptions de type contribution dans ce formulaire comme Contrib ? D’ailleurs on pourrait aussi demander si la personne a un compte Contrib et si elle veut réutiliser les mêmes identifiants
quid de l’inscription à la liste spip-dev ?
autres ?
Rasta avait émis l’idée d’avoir deux niveaux d’autorisation dans Gitea : tickets/wiki ou global avec les commits. J’ai interrogé Gitea et c’est possible mais uniquement en définissant deux teams, la team ticket et celle globale.
Cela fait donc 2 teams par organisations, néanmoins, à partir du moment où on gère ça automatiquement par des workflows, ça n’est plus un problème. Ca permettrait aussi de ranger tous les comptes non encore utilisés dans la team ticket.
C’est une pièce à casser, je pense que le principe est vertueux mais il y a surement pleins d’améliorations de fonctionnement et de présentation à faire pour arriver à un système optimal.
J’attends donc vos retours.
je serais très opposé au captcha (si même nous on en a besoin, alors cela veut dire que nospam ne suffit pas !).
par contre peut être qu’on pourrait imaginer un double opt-in, avec une validation par email ?
Rasta avait émis l’idée d’avoir deux niveaux d’autorisation dans Gitea : tickets/wiki ou global avec les commits. J’ai interrogé Gitea et c’est possible mais uniquement en définissant deux teams, la team ticket et celle globale.
Cela fait donc 2 teams par organisations, néanmoins, à partir du moment où on gère ça automatiquement par des workflows, ça n’est plus un problème. Ca permettrait aussi de ranger tous les comptes non encore utilisés dans la team ticket.
la page ne contient pas d’explications, en particulier qu’on aura accès à un premier niveau (rapports de bug)
et si quelqu’un veut s’inscrire pour contribuer du code ?
et il n’y a pas de lien vers git.spip.net pour comprendre à quoi on s’inscrit
Donc, quelques suggestions :
Commencer à contribuer → S’inscrire sur la forge de développement (bug et code)
Un texte d’explication genre : Vous inscrire sur la Forge SPIP (lien vers git.spip.net) vous permettra de : soumettre des bugs et les discuter, et de contribuer au code des plugins et des squelettes (existants ou nouveaux)
2 cases à cocher pour choisir entre juste les tickets de bugs, ou ticket et code
Rasta avait émis l’idée d’avoir deux niveaux d’autorisation dans Gitea : tickets/wiki ou global avec les commits. J’ai interrogé Gitea et c’est possible mais uniquement en définissant deux teams, la team ticket et celle globale.
Cela fait donc 2 teams par organisations, néanmoins, à partir du moment où on gère ça automatiquement par des workflows, ça n’est plus un problème. Ca permettrait aussi de ranger tous les comptes non encore utilisés dans la team ticket.
Il faut aller vers cela, clairement.
Alors attention, pas forcément. Car depuis moult choses ont changé. Il n’y a plus de liste spip-dev par exemple.
En fait la question de la distinction vaut surtout à cause des inscriptions aux listes et notamment à la liste des commits de contrib. Or quelqu’un qui veut juste faire des tickets n’a pas envie de recevoir les emails de tous les commits. Est-ce qu’on ne pourrait pas plutôt trouver une solution à ce problème ?
Je vois deux possibilités :
que la liste des commits n’aient pas besoin des inscriptions des gens qui commit : celleux qui veulent recevoir peuvent être inscrits dessus, mais pour envoyer, les hooks Git devrait l’envoyer avec le même unique email, exactement comme ce que font les notifs internes du Gitea (et de Gitlab etc) : « Madame Machin via git.spip.net » adresseunique@git.spip.net
que les commits puissent être suivi autrement, que la forge ait un flux Atom public de tous les commits publics, et donc qu’on puisse supprimer cette vieille liste
Résolu ce point, alors il n’y aura à priori pas de raison de distinguer les ticketeureuses et commiteureuses, on peut être l’un puis l’autre, sans devoir demander des permissions bureaucratiques en plus.
On a toujours essayé de lisser au maximum les hiérarchies et qu’il y ait le moins de strates différentes, je pense qu’il faut continuer : c’est mieux si on arrive à garder qu’un seul niveau, plutôt qu’ajouter des équipes, droits différents, etc. KISS, et c’est plus pérenne de trouver une solution à cette liste de commits, que gérer sur le long terme des droits mille équipe en doublon.
Non pas vraiment car pour l’instant on ne s’inscrit pas à Contrib. C’est une idée que je propose et si on est d’accord alors on pourra supprimer le bouton s’inscrire.
mais pas en popup, ce qui est surprenant
Oui je trouve la popup d’inscription insupportable
et si quelqu’un veut s’inscrire pour contribuer du code ?
Ben c’est ça le but aujourd’hui, la distinction ticket / code n’est pas implémentée (relis le message).
Commencer à contribuer → S’inscrire sur la forge de développement (bug et code)
Non je préfère attendre qu’on décide les inscriptions intégrées au formulaire avant de préciser
2 cases à cocher pour choisir entre juste les tickets de bugs, ou ticket et code
Oui ça viendra si on décide de faire cette distinction.
On a toujours essayé de lisser au maximum les hiérarchies et qu’il y ait le moins de strates différentes, je pense qu’il faut continuer : c’est mieux si on arrive à garder qu’un seul niveau, plutôt qu’ajouter des équipes, droits différents, etc. KISS, et c’est plus pérenne de trouver une solution à cette liste de commits, que gérer sur le long terme des droits mille équipe en doublon.
J’ai du mal lire alors, il me semblait que c’était une demande…
De fait, ça simplifie pas mal les choses.
Mais je ne vois pas le rapport avec spip-dev ni l’inscription à Contrib.
que les commits puissent être suivi autrement, que la forge ait un flux Atom public de tous les commits publics, et donc qu’on puisse supprimer cette vieille liste
Il n’y a toujours pas de flux atom ni RSS et vu comment cette demande semble peu prioritaire je pense qu’il faut oublier. Par contre, l’API fonctionne très bien, on peut éventuellement l’utiliser pour reproduire un flux RSS à partir de cette API avec un cron non ?
Plugins SPIP utilise déjà cette API pour produire à nouveau la liste des derniers commits de chaque plugin. En plus, l’API permet de séparer les organisations pour le flux éventuellement si cela a un intérêt.
pour moi il semblait qu’il y avait une volonté de forcer une personne qui suit du code à suivre les commits, et donc à être inscrit à la liste. Je n’ai personnellement pas d’opinion sur le bien fondé de ce forcage ou pas.- Mais c’était ce qui justifiait le statut différent.
Le message de confirmation n’a pas encore de chaine de langue ?
Ça dit : inscription demande ok message
Sinon, je trouve moi aussi qu’il y a confusion entre « S’inscrire » et
« Commencer à contribuer ».
Il faudrait effectivement virer la modale de S’inscrire, et y mettre un
texte explicatif (genre « S’inscrire sur ce site pour rédiger la
documentation des plugins bla bla »).
Au vue de l’état actuel du cahier des charges, cela me parait bien.
J’ai juste deux suggestion de modif sur les textes
"toute participation " > « toute participation à la communauté » (vu qu’une personne aurait très bien le droit de refuser la charte, et de forker spip dans son coin, ou un plugin… je ne vise personne !)
« Vous pouvez vous inscrire afin de soumettre des rapports d’anomalies, des demandes d’évolution, de les discuter voire de contribuer au code des plugins et des squelettes. »
La phrase est trop longue. Il faut la scinder en deux. Proposition « … de soumettre des rapports d’anomalies ou des demandes d’évolution et de les discuter. Il est même possible de contribuer au code des plugins et squelettes. »
mais on peut aussi contribuer au code du core, faut juste faire des PR. Mais bon, je sais pas si on doit tout mettre dans ce message.
@maieul : en fait j’ai repris un extrait de la charte. Tu crois pas que c’est mieux de le garder ainsi ?
La phrase est trop longue
Ok, je l’améliore.
Il serait bon d’unifier, non ?
@RealET : en fait j’ai utilisé le même terme que celui qui est utilisé sur la forge. Je pense que c’est mieux ainsi car si tu édites ton profil sur la forge tu vas retrouver le même libellé.
Sinon, je me dis qu’une chose simple que l’on pourrait faire serait de réunir dans une même page les deux formulaires, celui de contrib et celui de la forge ensuite, page accessible par un unique bouton « Commencer à contribuer » ou « S’inscrire pour contribuer » non ?
en fait j’ai repris un extrait de la charte. Tu crois pas que c’est mieux de le garder ainsi ?
ah, si c’est le texte de la charte, alors oui(même si on pourrait discuter de modifier le texte de la charte !)
Sinon, je me dis qu’une chose simple que l’on pourrait faire serait de réunir dans une même page les deux formulaires, celui de contrib et celui de la forge ensuite, page accessible par un unique bouton « Commencer à contribuer » ou « S’inscrire pour contribuer » non ?
Sinon, je me dis qu’une chose simple que l’on pourrait faire serait de réunir dans une même page les deux formulaires, celui de contrib et celui de la forge ensuite, page accessible par un unique bouton « Commencer à contribuer » ou « S’inscrire pour contribuer » non ?
C’est une bonne idée ! Déjà ça simplifie la navigation, il n’y a alors plus d’interrogation avant d’y accéder (« quelle peut être la différence entre les deux »), et ensuite une fois qu’on y est, on comprend forcément la différence puisqu’on aura alors les deux formulaires sous les yeux à la fois. Je vote pour aussi !
Bon donc la page d’inscription combinant le site et la forge est mise en place.
Elle est accessible par un bouton qui est toujours présent (voir discussion plus loin) et qui a le libellé « S’inscrire pour contribuer ».
Si on est connecté en tant qu’auteur, le formulaire d’inscription au site est remplacé par une information qui le précise.
Si on est un utilisateur de la forge (reconnu par l’email de l’auteur) alors le formulaire d’inscription à la forge contient une notice qui prévient l’auteur. Inutile donc de s’inscrire à nouveau avec la même adresse (de toute façon cela sera refusé).
Ca comme a être sympa à mon avis mais il y a surement des améliorations.
Par exemple, on pourrait cacher le bouton d’inscription de la nav si l’auteur est connecté et est déjà un user de la forge.
Si vraiment il voulait une autre compte il n’aurait qu’à se déconnecter pour faire apparaitre le bouton car alors il ne sera plus reconnu.
Après, il faudrait reprendre le formulaire du site qui est pas dans le look de l’autre.
Et enfin, améliorer les textes voire la présentation des boites mais ça ce n’est pas de mon ressort ;-).
Aujourd’hui j’envoie un mail sur la liste spip-dev pour prévenir qu’une inscription à la forge a été demandée. Par contre, j’envoie avec l’émetteur par défaut de Contrib, à savoir, noreply@noreply@spip-contrib.net.
Comme cet adresse n’est pas connue de spip-dev je suppose que ça va partir en spam.
Il faudrait créer un membre de spip-dev comme salvatore je suppose non ?