Salut,
Je n'ai pas beaucoup de temps à contribuer à ZdS en ce moment, mais une chose qui me semblerait une bonne idée et que je serais prêt à piloter c'est un défi ou un sprint "première contribution au code". L'idée serait d'encourager les gens qui savent déjà programmer à contribuer un patch, quelle que soit la taille, au dépôt git zestedesavoir/zds-site.
Je fais un peu de ce genre de choses dans d'autres cadres et ça se passe bien. Pour que ça marche, il faut:
-
Que le site soit facile à installer en local; j'ai testé récemment et les progrès depuis des débuts difficiles sont impressionnants, je n'ai eu aucun soucis à tout installer sur ma machine en suivant la documentation. Par contre je soupçonne que ça ne marche pas bien sous Windows, donc je pense prévenir au lancement que pour les gens sous Windows, ça risque d'être compliqué, et tester la procédure d'installation et la corriger si possible serait déjà une bonne contribution.
-
Une ou quelques personnes prête à encadrer, guider, donner des conseils. Je peux m'en occuper. Je ne connais rien ou presque au code du site, mais à la rigueur ce n'est pas plus mal: le rôle de l'encadrant c'est d'amener les gens à faire une "pull request" raisonnable, pas de se substituer aux développeurs/mainteneurs qui vont ensuite donner du feedback, faire du contrôle qualité, et décider d'accepter ou non le changement.
-
Un peu de documentation. Pour ça je compte utiliser le README du dépôt git, et les liens qu'il donne, comme seule référence. (Si vous voulez ajouter des informations, le mieux est de les ajouter au README avant le lancement du sprint).
-
Une liste de tâches très faciles pour des gens motivés. Je crois que victor a fait pas mal de bon boulot là-dessus, mais c'est un peu dispersé et ça manque de visibilité. Le premier endroit où chercher c'est les tickets avec le label "Facile". Une autre tâche que j'aimerais proposer, c'est d'écrire des tests pour augmenter la couverture de code, mais je n'ai pas trouvé de documentation sur comment lancer l'outil de couverture de code.
-
Que la testsuite passe avant qu'on lance le truc. Chez moi ça ne passe pas pour l'instant, j'essaie de corriger ça ou de mieux comprendre ce qui se passe avant de lancer quelque chose de définitif.
Tous les ingrédients ou presque sont réunis, il me semble – et le défi/sprint peut être une bonne occasion de nettoyer dans les coins. Mais si vous avez envie d'améliorer des choses sur un de ces aspects, n'hésitez pas à le faire avant qu'on lance le truc.
Ensuite, on a le choix entre deux format.
Le sprint c'est un événement délimité dans le temps, par exemple "le deuxième week-end de décembre", où tout le monde travaille ensemble. C'est convivial, motivant pour les participants, par contre l'organisation est un peu plus lourde, tout le monde ne peut pas s'engager sur la période (donc c'est moins inclusif), et ça fait un pic de boulot pour les développeurs/mainteneurs à la sortie (mais ça je pense que c'est gérable). Un autre point positif est que ça peut se recommencer régulièrement (et donc inciter les mêmes personnes à contribuer plusieurs fois). (On demanderait aux participants de tester l'installation en local avant le début du sprint pour éviter les frustrations.)
Le défi, c'est un topic sur le forum où les gens viennent quand ils veulent pour lire la proposition de défi (faire sa première pull request), poser des questions si besoin, et montrer leur belle réalisation quand ils ont réussi. C'est sur un temps plus long (indéterminé dans le temps), plus calme, donc accessible à plus de gens mais sans l'avantage de motivation lié à la synchronisation. Ça n'est pas facilement "recommençable", mais je ne m'inquiète pas sur le fait que les gens qui ont fait leur première contribution sachent recommencer par la suite si ça leur a plu, même hors d'un cadre les y encourageant particulièrement.
