Découverte Table ronde : La contribution française dans tous ses états et votre minute contrib

Transcription

- Bonjour tout le monde.

On va traiter à plusieurs de la contribution française pour Drupal. Parce que la contribution ne se résume pas au code. Il y en a, c’est cool, on est là pour ça, mais pas que. On va voir ce qui peut être fait, et comme se place la communauté française par rapport à ça.

Je suis Fabien Clément, alias GoZ. Je suis contributeur Drupal depuis 2008. J’aime faire du e-commerce et du commerce métier. On verra par la suite avec les autres intervenants, j’ai commencé Drupal par ouï-dire, par quelqu’un qui était déjà dans le métier, quand j’étais étudiant, qui m’a donné envie de jeter un coup d’œil à Drupal. En tant qu’autodidacte, j’ai regardé tout ça, mais sans projet réel. J’ai directement commencé pour monter un blog, un diaporama, commencé par la contribution, regarder comment ça marche.

La contribution, ce n’est pas forcément la plus simple, ça fait quand même mal.

Autour de moi, il y a Théodore, Felipe, Kevin, et Cédric, et Guillaume en mode ghost.

- La photo est très ressemblante.

- Je n’ai pas trouvé de photo.

Drupal, on sait qu’il a un rayonnement international avec des contributeurs partout dans le monde.

C’est la communauté qui a permis    à Drupal de devenir ce qu’il est devenu. On arrive à avoir un outil plutôt bien abouti et reconnu.

Sur la contribution française, la France est vraiment représentée. On n’a pas à rougir de ce qu’on amène à la communauté.

On fait des choses intéressantes.

La contribution en soi, ça reste cyclique. Il ne faut pas se dire qu’on va travailler aujourd’hui et dans vingt ans, on y sera encore. On l’a vu sur beaucoup de personnes, des personnes qui s’investissent beaucoup, et à un moment, ils ont d’autres projets. Il y a des noms qu’on voit toujours, qui font référence, et c’est la vie, ils passent à autre chose. Donc il ne faut pas se stigmatiser là-dessus.

On peut se lancer, et on n’en voudra à personne parce qu’elle a arrêté.

On va parler de la communauté, la contribution, la traduction, la vulgarisation, l’envie, le pourquoi je ne le fais pas même si j’ai envie, et on pourra vous laisser la parole si vous avez des choses à dire, des choses dont vous êtes fiers que vous voudriez montrer.

En ce qui concerne la communauté, je ne sais pas qui veut prendre la parole en premier, et me dire :  qu’est-ce qui pour vous est une première étape de contribution  ? 

- Je dirais que la première étape, c’est déjà de venir aux meetups, aux rencontres, rencontrer la communauté. C’est déjà un geste que d’en faire partie.

- Il y a aussi les utilisateurs. Dès qu’on utilise Drupal, on fait partie de la communauté, même si on ne le sait pas et même si on ne veut pas.

- C’est intéressant ce que tu as dit, j’ai entendu meetup. Tu peux expliquer ce que c’est ? 

- C’est des rendez-vous locaux qui peuvent se passer dans des bars, ça peut être plus ou moins informel. Des fois, c’est des sociétés qui accueillent dans des salles, et on commande des pizzas. Des fois, il y a un sujet, des fois non, c’est juste pour parler.

C’est assez convivial. Ce n’est pas le nombre qui fait l’intérêt du meetup.    A 4 ou 5, on a bien le temps de se rencontrer, et c’est du business qui se fait.

Dans les meetups, on rencontre des personnes avant de rencontrer des collègues de travail, un partenaire de travail. On rencontre la personnalité avant, c’est ce qui fait la force de la communauté.

- D’autres exemples d’événements  ?  On a les meetups qui sont locaux. Il y en a d’autres ? 

- Il y a les Drupalcamps

- Le meetup, on est sur une ville. Drupalcamp, on est sur du national.

On est orienté tech aussi.

Et Drupalcon, là, c’est la foire, il y a plein de monde.

- C’est la grand-messe.

- Un peu de décisionnel, il y a plein de sujets différents.

Donc ce sont les événements. Mais finalement, il faut aussi du monde pour faire tourner ces évènements. On a une première contribution qui est là :  il faut des gens. Tous ceux qui sont là en chemise rose, c’est grâce à eux. C’est la première étape, pas besoin de compétence spéciale pour donner un coup de main.

Il y a les speakers aussi.

Une deuxième partie, c’est la contribution au coeur de Drupal.

- La contribution, c’est très important. On contribue au code, mais pas forcément du code, ça peut être des reviews, du triage de budgets, de la maintenance, du sponsoring. Donc beaucoup de niveaux différents au niveau du code, et ce n’est pas forcément… On n’a pas besoin forcément d’être très technique pour contribuer. La documentation, il n’y a pas besoin d’être technique pour documenter.

Donc beaucoup d’opportunités. Ce qu’on fait bien, c’est la reconnaissance de toutes ces contributions à travers les crédits, pour montrer qu’on a contribué à autant de tickets dans tel et tel module, pour… C’est mettre en valeur le travail qu’on fait volontairement ou pas, bénévolement ou pas dans la communauté.

C’est appréciable.

- Sur la contribution que ce soit sur Drupalcore, ou des modules contrib sur drupal.org, c’est devenu plus accessible depuis ces dernières années. Avant, pour un néophyte, il utilisait le système CVS, pour sortir un patch, ce n’était pas simple. Moi, ma première correction, c’était genre l’ajout d’un point dans un commentaire. Maintenant, ça peut se faire en 2 mn via Gitlab. On peut faire notre merge request en 2 clics sans n’en avoir jamais fait. C’est devenu très facile.

- Si on a besoin de faire des choses plus évoluées, il y a des outils comme Drupal code, qui permet d’avoir directement le fork dans un environnement, dans le cloud pour exécuter les choses en local.

La documentation, c’est important. Il y a eu notamment une initiative    d’un guide, traduit en plusieurs langues, entre autres en français. C’est une contribution utile que de traduire. A un moment, c’était dans les missions de l’association d’avoir de la documentation dans d’autres langues. Si vous savez bien rédiger, vous comprenez bien l’anglais, c’est une compétence extrêmement utile. On a besoin de gens qui ne sont pas que des développeurs.

- Quand tu parlais de commencer avec juste un point, c’est intéressant, car en termes d’approche, c’est simple à faire. Par contre, là où c’était complexe de proposer un ticket, de résoudre, ça t’a appris à entrer dans le process.

Maintenant, l’accès est plus simple grâce aux outils qu’on a. Il n’y a plus ce frein de récupérer le code sur CVS etc.

Cela n’empêche que la contribution peut être là aussi sur des commentaires qui sont mal rédigés, sur une faute de frappe. Ça fait partie de la qualité de code qui va être produite derrière.

- Pour avoir traduit Drupal, c’est embêtant quand la chaîne de départ n’est pas bonne car tous les développeurs ne sont pas forcément anglophones.

Lorsqu’on traduit, on essaie de ne pas se focaliser sur exactement les mots de la chaîne d’origine, mais de faire quelque chose de compréhensible et utilisable.

- Qui a déjà contribué à Drupal ?  OK. Et au coeur de Drupal ?  C’est parce que ça vous a fait peur ? 

- C’était un manque d’opportunité. C’est dur de répondre.

- Théodore, quand tu vois un issue, le ticket va être créé, on va essayer de le résoudre, toi, tu mets ton tampon à la fin. Entre deux, il se passe beaucoup de choses. Il y a besoin de beaucoup de personnes. Quelles sont les choses nécessaires qui ne demandent pas toujours des compétences techniques poussées ? 

- Là, on parle de commentaires, de points, mais si vous voulez contribuer à faire du code, c’est possible aussi. Juste, n’y allez pas tout seul. Prenez quelqu’un qui a l’habitude pour vous aider. Car il y a beaucoup de process pour garantir la qualité du code de Drupal. Quand on crée le ticket, déjà, est-il créé avec les bonnes méta données ? 

Une fois qu’il y a des gens qui viennent sur le ticket pour aider à résoudre le problème, il y a différents niveaux de qualité sur le code à passer, la syntaxe, les tests automatiques qui vérifient que le changement opéré ne casse pas le code qui existe déjà. Une fois que tout ça, c’est bon, on peut dire que la communauté a fait la revue de code, c’est à ce moment-là que les core commiters vont garder le ticket. C’est souvent là qu’on va découvrir le ticket. Nous, on refait une revue de code pour savoir si le ticket et le code correspondent bien.

Souvent, il manque des tests.

Souvent, ça ralentit pas mal la contribution car les tests, c’est un peu compliqué    à écrire. Ça ne fait pas peur, une fois qu’on en fait un ou deux, ça va beaucoup mieux.

- C’est plus le manque d’envie, d’ailleurs, d’écrire des tests. Le patch, il marche, mais il faut écrire les tests… ! 

- Il ne marche pas tout le temps.

Donc il se passe plein de choses avant. Une fois que c’est bon, on fait les commit, on envoie sur le dépôt, et on fait l’assignation des crédits.

On dit :  ces personnes-là vont avoir un crédit sur le ticket, ça va s’afficher dans le profil de leur société, s’ils ont été sponsorisés par cette société.

C’est assez long, c’est un peu contraignant. C’est ce qu’on utilise pour garantir la qualité du code. Ce n’est pas insurmontable. Si vous avez des questions là-dessus, des tickets en cours à faire avancer, je peux certainement vous aider à commencer.    Je suis dispo cet après-midi, pas demain.

- Le simple fait d’avoir des avis constructifs dans le fil de discussion d’un ticket, d’une mission, ça peut donner des crédits. Ça a un vrai intérêt. Tu parlais de la qualité du code, pour moi, Drupal, c’est un vrai modèle de démocratie, il y a de la bienveillance dans les discussions qui se passent, et qui donne la place à chacun. Le produit avance peut-être un peu doucement, il y a des tickets qui durent des années, mais à la fin, on arrive à satisfaire le plus grand nombre.

Tous vos avis constructifs sont les bienvenus.

- Ça peut être ajouter des captures d’écran pour bien mettre en avant le problème.

- La première étape, on l’a créée. On peut ajouter des informations, qu’on a eu le même problème, donner des captures d’écran, donner des exemples précis, faire du avant/après. Quand tu parlais de revue de code, il y avait la revue du ticket, ne serait-ce que le tester, dire si ça marche ou pas, ça, ça ne demande pas de compétences.

Ça, finalement, c’est assez simple d’accès. Et ça permet de valider après que ça fonctionne. Après, il y a encore l’écriture des tests etc., mais ce sont des étapes assez simples.

Comment es-tu arrivé sur Drupal Théodore ? 

- A la fac. J’étais dans une asso de théâtre, l’asso avait un vieux site. Je voulais voir comment l’améliorer un peu.

Il fallait quelque chose qui gère bien les dates et les calendriers. Je suis allé voir Drupal.

Après, j’ai commencé à travailler dans la tech dans une boîte de la région dont on a des représentants ici. C’est Drupal que j’ai aidé à faire introduire dans cette société. C’est en faisant des sites que je me suis rendu compte qu’il y a des bugs dans les modules que j’utilise.

J’ai remarqué que le module prenait son modèle de code du corps.

Si je veux réguler tous les modules en une fois, il faut régler le problème dans le corps. C’est comme ça que je suis passé de la contribution au corps, pour factoriser les efforts pour que ça se propage dans la contribution.

- Tu as commencé par utiliser Drupal, puis par contribuer via la contrib de modules.

- Je suis devenu meilleur grâce à la contribution.

- quel serait ton plus gros problème dans la contribution, et ta plus grosse satisfaction ? 

- Souvent, on fait du code, et personne n’est là pour faire de review. Dans le coeur, on a besoin de gens différents. Donc ça traîne un peu. C’est un gros problème.

Par rapport à ça, j’ai sorti des stats, surtout ma femme qui a fait ça, car elle fait des data sciences, le temps effectif passé sur les tickets, en général, c’est une dizaine de jours de travail, même s’il est ouvert pendant six mois ou dix ans.

C’est juste pour cadrer un peu l’effort. Car on voit des tickets qui datent de 2010, ça fait peur, mais au final, ce n’est pas tant de temps que ça qui est passé dessus.

- Ça correspond à des événements comme les Drupalcon ou autres ? 

- Drupalcon, ça génère des tickets. Il y a beaucoup de revues qui sont faites, mais ce n’est pas significatif dans la résolution et la fermeture.

Et la plus grande satisfaction :  j’aime bien quand ça aide les gens, les patches que je fais. Régler un problème sur une interaction, j’aime bien, car les gens qui utilisent ça, ils n’ont plus le problème. Ça fait plaisir.

- Il y a un point important :  on est Français, finalement, la première contribution française qu’on peut faire, c’est la traduction pour que nos clients aient un outil qu’ils puissent utiliser, les anglophones également.

Felipe, tu es le plus à même pour prendre la parole.

- Oui. On a même un outil qui nous aide à traduire. Ça fait très longtemps… Drupal est multilingues. On est une équipe    assez réduite, c’est un peu notre problème. On a des gens qui assistent aux ateliers. Je vous invite à y assister demain. On aurait besoin de gens qui puissent traduire de manière plus permanente tout au long de l’année. Pour faire de la traduction, on a quelques règles. On est un peu tatillon, on demande à utiliser l’infinitif, et pas la deuxième personne du pluriel. C’est important à suivre car des fois, on ne peut pas valider une chaîne pour une pétouille. De base, vous allez pouvoir intégrer l’équipe de traduction en français, ou une autre langue, le breton par exemple, et pouvoir soumettre des suggestions qui seront validées par des modérateurs. En ce moment, les modérateurs, on n’est pas assez nombreux, on a besoin de gens qui puissent contribuer à ça. Penser que tous les francophones dans le monde entier, s’ils installent Drupal, c’est grâce à cet effort de traduction.

- Quand tu es arrivé sur Drupal, comment tu as commencé à contribuer ? 

- Je suis arrivé vers la fin de Drupal 6. Je me demandais ce que je pouvais faire comme boulot après mes études. J’ai commencé là-dessus, et je n’ai jamais arrêté.

Dans mon cas, ça a été assez long pour contribuer. Ce n’est pas tellement la marche qui était haute, mais je ne suis pas entré de suite dessus…

Peut-être que j’avais besoin de trouver un autre moyen de m’exprimer, de contribuer à Drupal.

Ce que j’ai fait pas mal, c’était d’aider à organiser des meetups. Ça a été à Montpellier à un moment, ça a été très régulier. A un moment, on était même vingt personnes, ce qui pour une ville comme Montpellier, est pas mal.

- Donc on reste sous la forme de contribution communautaire, qui est le plus simple ? 

- Oui. C’est un bon moyen d’entrer dedans. Ça permet de mettre le pied à l’étrier et de rencontrer les gens.

- Ton plus gros problème que tu aurais rencontré ? 

- Dans la communauté Drupal, il y a des choses qui mettent beaucoup de temps à se faire. Je ne sais pas comment aborder ce problème-là. Ça dépend aussi des mainteneurs. Des fois, je soumets un truc, et quelques heures plus tard, il accepte mon patch. Mais ils n’ont pas que ça à faire.

J’aimerais qu’on arrive à être plus nombreux à contribuer. On enfonce le clou sans arrêt, c’est vrai. Je parlais de la traduction, on n’est pas assez nombreux pour traduire. Idéalement, dans une association ou dans une communauté comme Drupal, ce serait bien que tout le monde puisse mettre la main à la pâte.

Il faut aller dans les événements comme les Drupalcon, et voir comment faire avancer les choses, juste en allant parler avec le voisin d’à côté.

- Merci.

On va traiter la vulgarisation :  comment transmettre l’information via la documentation, mais pas que, ça peut être par le blog, expliquer telle et telle chose.

- Quand j’ai attaqué Drupal au début de Drupal 7, j’ai heurté un mur comme beaucoup d’entre vous ici, quand on est passé à Drupal 8, que j’ai testé lors des premières alphas. Pour comprendre comment ça marchait, il n’y avait pas de doc sur Internet, très peu. Il fallait regarder comment le corps était foutu. C’est là que j’ai commencé, c’était le début pour moi, un type d’entité pour ajouter un champ, c’était ce bout de code-là.

Petit à petit, j’ai continué à faire ça. Mine de rien, ça me sert beaucoup, et ça sert à certains et certaines d’entre vous qui sont ici, qui m’ont payé beaucoup trop de verres hier pour me remercier. C’est ma plus grande satisfaction.

-    De boire gratuitement ? 

- Non, les gens qui me remercient.

Le souci, aujourd’hui, c’est que prendre mon bout de code, le mettre sur mon site, ça me prend 5 mn, le temps d’enlever le nom du client. Ça, n’importe qui peut le faire. Vous avez tous des morceaux de code que vous avez faits, qui pourraient servir à d’autres.

Ça, il faut le publier. Il faut se déculpabiliser de ne pas écrire 10 000 signes pour le contexte. Vous balancez votre bout de code, et ça suffit. Ne pas le publier sur des plateformes tierces, genre LinkedIn, car ce n’est pas indexable, ce n’est pas requêtable par Google. Faites vous un skyblog.

Ça servira à vous et à d’autres personnes.

- C’est vrai que c’est pratique.

- Ça m’est arrivé de vouloir faire quelque chose, et d’aller sur le blog datant d’il y a deux ans.

Donc l’envie :  j’aimerais bien, mais j’ai poney  ! 

- Là, c’est ma partie. Je représente quelques personnes. On a envie, mais on ne trouve pas le temps. Je suis free-lance. J’ai développé un thème que j’ai voulu contribuer, j’ai fait une sandbox, sans aboutir à quelque chose de stable.

Côté backend, il y a toujours des choses qu’on fait pour des clients, ça n’est pas évident de le rendre générique et de trouver le budget pour ça. Ce qui fait que je n’ai jamais eu un module à moi, déposé sur drupal.org.

La vraie raison, c’est la responsabilité    d’avoir quelque chose à maintenir.

J’ai rencontré le mainteneur des dev, en gros, il n’a jamais eu peur. Il a été tout seul pendant un moment. Il n’a jamais eu peur, car il s’est dit :  si ça attire du monde, j’aurais de l’aide. Sinon, ça ne gêne personne si je m’essouffle. Donc il ne faut pas avoir peur. Un de ces quatre, je réussirais à sortir un module.

- C’est ce que j’ai fait. Je n’y touche plus. Ce sont d’autres gens qui l’utilisent, et qui l’améliorent. Il y a mon nom dessus, mais ça fait des années que je ne suis pas allé dans le modules.

- Ça m’est arrivé sur un petit module auquel j’ai contribué. Ça faisait deux fois que je le faisais pour deux clients différents. Je l’ai packagé.

Après, plus le temps, je voyais de temps en temps des notifs de tickets qui arrivaient. Au bout d’un moment, un mec s’est proposé de devenir mainteneur du module, je lui ai dit OK pour que mon bébé vive sa vie.

- Tu pensais que la partie code, mais finalement, tu as déjà contribué via la communauté ? 

- Oui. J’ai fait des meetups.

- Tu as aidé à les monter. Tu ne fais pas de surfcamp ? 

- Non, pas jusque-là.

- Il y a encore quelque chose à travailler.

- J’ai organisé des meetups en Corse.

Une petite satisfaction que j’ai eue :  à Amsterdam, j’ai eu une idée, je suis allé voir les mainteneurs pour leur proposer de l’aide sur la partie Frontend du *. Ils étaient ravis, car j’ai revu toutes les issues. C’était juste lire les commentaires et faire une synthèse à la fin. J’ai eu trois, quatre crédits sur quatre issues, ça fait classe.

- J’ai eu du mal à entrer dans la contribution, déjà, je suis free-lance, je n’ai pas forcément de temps.

Quand on arrive à maintenir quelque chose, quand on se spécialise, idéalement, vous arriverez à faire de façon permanente au cours du temps.

Il ne faut pas imaginer qu’individuellement, tout doit être au top. Globalement, il faut faire avancer les choses. C’est l’idéal.

- Ce serait comment faire participer son client ou son projet à la contribution ? 

L’objectif, c’est que quand vous avez quelque chose à faire pour un client, et que ça pêche dans Drupal par exemple, c’est de le pousser pour que ce soit suffisamment générique, que vous puissiez créer un module là-dessus. Et après, c’est l’engouement des gens qui vont continuer et améliorer le système.

C’est le client qui finance au début, et après, d’autres vont venir ajouter leur pierre.

Et si vous n’avez plus le temps, d’autres vont prendre le relais.

Et on se passe le projet comme ça de personne à personne.

Merci à vous quatre.

Il reste très peu de temps. Quelqu’un veut mettre en lumière un module contribution dont il serait fier ? 

- Je ne vais pas répondre à ta question.    Un truc qui manque pour moi, c’est le salon Slack qui est un super moyen de répondre à des questions et aider des gens. C’est super satisfaisant. Ça donne l’impression d’être avec du monde, de faire partie d’une communauté d’échange. J’ai un souci, j’ai une réponse de quelqu’un d’expert sur le sujet. J’invite tout le monde à venir sur le Slack et à échanger sur les salons.

- Au-delà de la partie code technique où on pourra    trouver des réponses dans la doc ou quoi, sur Slack, on peut discuter de la partie fonctionnelle. Merci pour ce rappel. Pas de volontaires ? 

- J’avais une question sur la partie contribution patch je crois qu’elle va être tournée vers des merge requests maintenant ?  Comment les attacher dans nos projets ?  Quel est l’enjeu ? 

- Là-dessus, pour le coeur, déjà les patches    ce n’est plus utilisé par les tests avec Gitlab CI ils tournent en dix minutes, avec les patches, c’est en 1h. On a le temps de se faire un café, de voir si c’est bon et de corriger En même temps. C’est pour réduire les coûts aussi. Il y a toute l’infra des tests qui a été désactivée. Je pense qu’on ne peut même plus les lances. Les merge requests, c’est ça qu’on veut mettre en avant déjà pour la rapidité des tests, la convivialité de Gitlab par rapport à des patches. C’est surtout des problèmes, toutes les issues à un moment elles vont passer sur Gitlab aussi, on ne va pas faire de patch sur Gitlab. C’est pour enlever les mauvaises habitudes. Pour tout ce qui est composer ça va être compliqué.

- On peut ajouter une merge request dans Gitlab. Maintenant ça va le faire.

- Dans composer tu veux dire ? 

- Tu peux mais le patch va changer avec la merge request.

- Ça mérite d’être documenté.

- Documentation encore une fois ! 

- Une autre contribution assez proche des événements mais qui a été un peu omise ce sont les associations qui organisent    tout ça. L’association Drupal monde, il y a aussi l’association Drupal France. Il n’y a pas besoin de savoir coder. Participer à l’association, aider à avoir des idées, participer à la construction des événements en avance, ce sont des choses qui sont nécessaires. Il y a eu l’AG juste avant le Drupal Camp avec un renouvellement du bureau. Venir participer à tout ça c’est aussi une forme de contribution. Aucune connaissance technique n’est nécessaire.

- Sauf si tu es à la compta.

- Il y a aussi besoin de gens qui ont des compétences techniques pour gérer les serveurs, les sites Internet et autres.

- Je crois que c’est l’heure. Merci à vous.