J’ai découvert sur ssb que zeromq ont publié leurs specs de contribution. Elles ont pour objectif principal
number one goal is size and health of the community–not technical quality, not profits, not performance, not market share. The goal is simply the number of people who contribute to the project. The science here is simple: the larger the community, the more accurate the results."
Il me semble que ce sont des specs dont on pourrait s’inspirer. Ca implique des choix forts du type :
s’appuyer sur une plateforme
spécialiser les rôles des membres de l’équipe (un développeur n’est pas un mainteneur)
accepter des patchs imparfaits a être mergés (optimistic review)
travailler avec une seule branche master sur le repo principal et que des forks personnels
interdiction meme pour les anciens de commit directement sur la master
It tells new contributors, “guilty until proven innocent,”
Dans l’idée ça me fait penser un peu à ce que Tim Berners Lee explique au sujet de la genèse de Wikipédia : avant de choisir le wiki, il avait opté pour un système avec des peer reviews, et même lui n’arrivait pas à écrire un article, tellement la procrastination du perfectionniste l’empêchait d’appuyer sur le bouton publier.
Je pense qu’effectivement, être accueillant et donner envie de contribuer est crucial au succès d’un projet.
Contribuer doit être au moins facile, et idéalement à la limite du ludique.
Malheureusement, par expérience, si c’est facile et ludique, c’est que quelqu’un à travaillé dur pour cela (quelqu’un qui s’est fadé le difficile et pas drôle pour les autres), et qui travaille continuellement à convertir des contributions funs sales et indépendantes en code intégré, et testé.
Dur, dur… ça dépend de quoi on parle. Comme pour tout, il y a des actions qui ont beaucoup d’impact alors qu’elles demandent très peu d’effort.
Je suis sûr et certain qu’il y a 2-3 trucs ici et là qu’on pourrait faire pour rendre certaines contributions faciles, ludiques et conviviales.
Déjà peut-être commencer par arrêter d’utiliser des mots comme “sale” et des smileys " " pour qualifier le travail effectué bénévolement par d’autres.
Ensuite ne pas obliger les utilisateurs de GitLab à posséder un compte GitHub.
Regarder s’il n’y a pas un plugin qui existe pour que GitLab détecte automatiquement la langue du visiteur et affiche l’interface dans la langue idoine. C’est absurde d’avoir une interface en anglais par défaut alors que 99% des contributeurs sont francophones.
Je viens de commencer à lire le chapitre 1 là, mais déjà je me dis que si on passe Duniter au crible de la toolbox, on n’obtiendra pas de bons score sur beaucoup de points.
" pour qualifier le travail effectué bénévolement par d’autres.