[spip-dev] Amélioration de l'accueil des nouvelles personnes suite à git.spip.net

Dev
1

Glop,
l'arrivée de git.spip.net change assez profondément la manière dont on peut contribuer.

On est plusieurs à penser que l'accueil est trop compliqué, surtout qu'il y a maintenant plusieurs niveaux de contribution *dans une même plateforme*, ce qui n'était pas du tout le cas avant.

Avant :
- SVN, sans véritable forge user-friendly (juste pour de la lecture/recherche)
- aucun ticket de plugins
- le support se faisant uniquement par Contrib, dont les forums sont ouverts, y compris aux anonymes, donc facile de faire un retour
- pour y avoir accès, il fallait accepter la charte ET être inscrit à des listes, car il faut que l'email soit ok pour la liste des commits + il fallait pouvoir être contacté s'il y avait une engueulade, un truc à débattre à propos de commits

Maintenant :
- git.spip n'est pas juste une interface de lecture, quand on y a un compte avec les bons droits, ça donne le droit de contribuer, d'écrire (que ce soit code, tickets, ou wiki d'un projet)
- il y a maintenant des tickets par plugin, et faire des tickets *uniquement* est une manière de contribuer, même quand on n'y connait rien du tout au code et qu'on ne commitera jamais rien de sa vie
- avoir accès aux orgas "de contribution", pour l'instant c'est toujours les mêmes conditions : charte + listes SAUF QUE
  1) désormais il y a des tickets par plugins, dont la liste spip-dev est un peu moins obligatoire pour s'engueuler et commenter les modifs
  2) des gens non devs peuvent vouloir participer uniquement à faire des tickets et débattre des fonctionnalités SANS jamais coder de leur vie, donc sans obligation aucune d'être inscrit aux listes

La proposition serait de complexifier *légèrement* mais le moins possible, les droits de la forge, afin de couvrir tous les cas.
Et au passage de permettre une inscription semi-ouverte, au moins pour le début du processus.

Voici la proposition :
- ajouter si besoin un niveau de droits "uniquement tickets / commentaires" sans possibilité de modifier le code (mais peut être que c'est déjà le cas par défaut)
- ouvrir les inscriptions libres sur la forge
- que l'inscription libre oblige à cocher une case "j'ai lu et j'accepte la charte" (lien vers la charte spip.net ouvert dans un autre onglet)
- que l'inscription libre ajoute les gens dans toutes les orgas de contrib *seulement avec des droits de tickets/commentaires*
- qu'une explication d'un ou deux paragraphes soit ajouté sur cette même page d'inscription pour expliquer comment ça marche : "En vous inscrivant, vous pourrez créer et commenter les tickets de tous les projets. Si vous désirez ensuite contribuer au code, abonnez-vous à la liste spip-dev (lien) et demandez à contribuer. Un⋅e admin augmentera vos droits sur git.spip pour vous donner l'accès complet."

Du coup :
- ça laisse en partie l'inscription ouverte, c'est moins fermé que maintenant
- ça fait moins de boulot aux admins, qui n'ont plus à créer de comptes, mais seulement augmenter les droits quand on leur demande (et ajouter à la liste spip commit)
- on ne donne quand même pas les droits complets auto sans contact humain, ya quand même un filtre où on doit se parler

1 « J'aime »
2

Que dire à part que j'approuve totalement cette idée de processus.

3

Ça semble pas mal, et en plus Gitea c'est du logiciel libre, et les templates sont sur git.spip.net : yapuka :slight_smile:

Juste un bémol : quand les inscriptions étaient ouvertes, ça spammait grave, il faut donc résoudre ça d'abord.

4

Oui je me souviens effectivement.

Mais du coup : pourquoi ? Je veux dire : pourquoi plus que sur nos autres sites (et que toutes les autres forges du monde qui ont toutes des inscriptions ouvertes) ? Si les autres forges y arrivent, on devrait pouvoir non ?

Au pire, même si on trouve mieux plus tard, mais pour avoir un truc qui marche plus vite : j'ai tendance à penser que c'est mieux un captcha ou ce genre de crotte, que pas d'inscription à cause des spams et donc rien du tout et des complications encore plus rebutantes pour les gens comme actuellement.

5

Hello,

Juste un bémol : quand les inscriptions étaient ouvertes, ça spammait grave, il faut donc résoudre ça d’abord.

Oui je me souviens effectivement.

Oui c’est clair.
On avait nettoyé ça avec Camille.
C’est dingue comme les Russes aimaient spip…
Franchement c’est pas super cool comme boulot de vérifier les usera après coup.

Mais du coup : pourquoi ? Je veux dire : pourquoi plus que sur nos autres sites (et que toutes les autres forges du monde qui ont toutes des inscriptions ouvertes) ? Si les autres forges y arrivent, on devrait pouvoir non ?

Au pire, même si on trouve mieux plus tard, mais pour avoir un truc qui marche plus vite : j’ai tendance à penser que c’est mieux un captcha ou ce genre de crotte, que pas d’inscription à cause des spams et donc rien du tout et des complications encore plus rebutantes pour les gens comme actuellement.

Oui ça pourrait être une façon.
Mais en quoi c’est rebutant aujourd’hui ?
On a des retours ?
Parce qu’en général on réagit assez vite pour l’ouverture du compte et il n’y a pas des tonnes de demandes.

En tout cas, sans protection en tout je ne suis pas vraiment favorable à une inscription ouverte.

6

Oui ça pourrait être une façon.
Mais en quoi c'est rebutant aujourd'hui ?
On a des retours ?
Parce qu'en général on réagit assez vite pour l'ouverture du compte et il n'y a pas des tonnes de demandes.

En tout cas, sans protection en tout je ne suis pas vraiment favorable à une inscription ouverte.

++
Eric

Bah en gros
1. C'est pas documenté (mais bon ca on pourrait résoudre)
2. Quand je contribue à un projet libre juste pour ouvrir des tickets (parce que je connais pas le language derrière, parce que j'ai pas envie de m'impliquer en codant), j'ai pas forcément envie de me taper tous les commits et les discussions de tout le monde sur les avancés : je veux juste ouvrir un ticket.

7

Yop,

8

Soit, mais je ne vois pas le rapport avec l'inscription ouverte.

effectivement c'est indépendant.

9

Pour peu qu'il y ait une solution pas trop contraignante à la fois pour les admins qui modèrent le spam et pour les gens qui s'inscrivent, entièrement d'accord avec la proposition.

10

Bah pour demander à des humains admin d'ajouter un compte, il faut les contacter, donc s'inscrire à la liste spip-dev ou ce genre. Dans tous les cas : des complications, des barrières à surmonter avant de trouver qui quoi comment arriver à avoir un compte, juste pour rapporter un bug dans un ticket d'un projet. C'est cent fois trop par rapport à tous les autres projets libres ailleurs, que ce soit ceux qui sont tout simplement sur github, ou ceux qui ont leur propre plateforme, où il n'y a aucune complication de ce genre pour commencer à intégrer la communauté (j'ai regardé sur WP, Drupal, et d'autres pour ceux qui ont leur inscription ailleurs que sur github : tout est en libre).

Faut évidemment pas penser qu'en mettant libre on va d'un coup avoir 5000 personnes en plus, mais c'est quand même dommage d'ajouter des barrières artificielles qui repoussent forcément l'accueil dans la communauté.

Par ailleurs dans la proposition, il y a aussi la distinction entre deux étapes : avoir un compte permettant juste de pouvoir participer aux tickets, sans avoir besoin d'être inscrits aux listes, et seulement pour celleux qui le demandent en plus, avoir vraiment accès à la contribution, donc droits supplémentaires + là oui inscriptions aux listes en plus.

11

Il y aurait un captcha en standard dans Gitea ?
https://github.com/go-gitea/gitea/pull/4044

https://github.com/go-gitea/gitea/blob/master/custom/conf/app.example.ini#L639

Camille ? ce serait activable ?

12

Hello,

Je reprends le mail sur l’accueil de Gitea et des contributions à SPIP.
Je vais dans un premier créer un formulaire sur Contrib pour demander un compte git et on pourra le développer pour ajouter d’autres inscriptions groupées et ainsi éviter aux utilisateurs d’aller partout pour contribuer.

J’ai regardé un peu Gitea qui utilise aussi Discourse et Discord que je vous conseille car ils répondent ce qui n’est pas le cas de leur doc qui est indigente.
Rasta proposait :

ajouter si besoin un niveau de droits « uniquement tickets / commentaires » sans possibilité de modifier le code (mais peut être que c’est déjà le cas par défaut)

En fait, cette possibilité n’existe pas au niveau de l’utilisateur (dans ses paramètres). Elle est distribuée dans chaque organisation, au travers des équipes et de leur configuration.
On peut dire pour une équipe qu’elle autorise à tous ses membres de modifier le code, faire des tickets, rédiger dans le wiki…
Donc avec un équipe on peut établir un ensemble d’autorisations applicables à une liste de users.
Cela reviendrait aujourd’hui à scinder les équipes actuelles en 2 : l’équipe des contributeurs (celle actuelle) et celle des « commentateurs ».

A partir du moment où on gèrerait les inscriptions à partir d’un formulaire intelligent, rien ne nous empêcherait d’utiliser plus de teams qu’aujourd’hui car cela deviendrait transparent.

Voilà ce que j’ai compris, Camille pourra confirmer ou pas.

++
Eric

13

Oui quand j’ai dit ça c’était avec des équipes bien sûr. Le problème des équipes (+ du fait qu’on a 12 orgas pour le même collectif de personnes) c’est qu’il faut les refaire dans chaque orga, c’est pas transversal. Mais bon c’est ce qu’on fait déjà pour toutes les orgas « contrib », on n’a pas le choix…

Je me pose par contre des questions :

  • spip-dev n’existe plus, maintenant c’est ici : est-ce que celleux qui veulent commiter on les inscrit au Discourse catégorie spip-dev en plus comme avant pour la liste ?
  • spip-zone-commit existe toujours, mais est-ce que les commiters ont toujours l’obligation d’y être inscrit ? c’est un hook git qui y poste non ? on peut pas faire en sorte que ça affiche le nom de la personne mais que ce soit toujours l’email du gitea, un truc dans ce genre ?
  • car dans ce cas s’il n’y a justement plus d’autres inscriptions à faire en parallèle, qui distingueraient les comptes commits des comptes juste tickets : on pourrait juste garder une unique inscription non ? et dans ce cas… il n’y a plus spécialement à se décarcasser… juste 1) à mettre un plugin captcha sur gitea + 2) à rajouter une case à cocher (qui enregistre rien mais obligatoire pour valider) « j’accepte la charte »

Que ce soit en terme de formulaire, et d’organisations des comptes ensuite : plus on restera simple, avec le moins de droits différents, mieux ce sera.

Donc tout dépend de ce à quoi on veut aboutir maintenant qu’il n’y a plus spip-dev, et que peut-être on peut simplifier pour la liste des commits.

14

Ya besoin de simplifier le process et de le rendre visible aussi car actuellement c’est non seulement lourd pour celleux qui s’en occupent, mais en plus c’est difficile de savoir ce qu’il faut faire. Double résultat avec Laeta récemment :

  • elle m’a contacté perso alors qu’elle voulait s’inscrire sur git.spip et ne savait pas comment faire
  • le process d’inscription, passé par de nombreuses étapes, a été laborieux (ou folklorique) et a paru souvent incertain : est-ce qu’elle attendrait et persévèrerait dans ses demandes jusqu’au bout ? est-ce la demande sera prise en compte par les admins et poussée à travers ses différentes étapes de validation et confirmation ?

Donc +1 / simplifier et sécuriser, clarifier et rendre visible.