Introduction
En août dernier je suis devenu le mainteneur principal du SDK Java Microsoft Graph.
L’équipe avait dû déprioriser ce SDK en faveur d’autres langages à cause d’un manque de personnel. Il y avait environ 100+ problèmes, ainsi que 15 pull requests provenant de la communauté. Les dépendances et outils n’étaient pas à jour, le développement Android n’était pas clair, il n’y avait pas eu d’innovation depuis longtemps, le repository avait l’air abandonné et causait beaucoup de frustration…
L’objectif de ce billet de blog est de partager des astuces sur comment nous avons amélioré la situation et multiplié l’utilisation du SDK par 6. Si vous vous trouvez dans une situation similaire en tant que mainteneur, j’espère que cet article vous sera bénéfique.
Priorité à ce qui est à portée de main
La plupart des correctifs de bugs ne demandent pas beaucoup d’effort et résolvent le problème d’un utilisateur du SDK. Ces correctifs représentent aussi une bonne façon de « mettre les mains dans le code » et d’envoyer un signal à la communauté que les choses s’améliorent.
Cette reconnexion avec la communauté nous a aussi permis d’identifier quels correctifs ou améliorations nécessiteraient plus de travail et/ou l’introduction d’un changement incompatible avec les applications existantes.
Nous avons approché cette situation en adressant 80% des problèmes le plus rapidement possible afin de dégager plus de temps pour les problèmes restants.
Récompensez les personnes qui contribuent
Je me souviens toujours du sentiment d’accomplissement procuré par ma première contribution sur GitHub : « J’ai passé du temps afin d’améliorer un article de documentation et cette contribution a été acceptée afin que tout le monde puisse en bénéficier ». En tant que mainteneur, vous devez faire tout ce qui est en votre pouvoir afin que les contributions provenant de la communauté soient intégrées le plus vite possible. Les contributrices vont se sentir reconnues et cela va les encourager à contribuer davantage.
Une fois que les pull requests et problèmes sont en mouvement, vous allez remarquer et certaines personnes contribuent à de multiples occasions. Assurez vous de leur répondre en priorité, cela va participer à bâtir des relations. Ces relations vont permettre des collaborations avancées sur des problèmes plus complexes. Par exemple, la correction d’un problème de connexion distribué sur plusieurs couches et la réduction de l’utilisation mémoire par un facteur de 3. Sans ces relations, il aurait été impossible de corriger ces problèmes en si peu de temps.
Investissez dans de bons outils
Parce que le repo devient plus actif, il se peut que vous vous retrouviez un peu débordé par certaines tâches répétitives. Vous devriez prendre le temps d’automatiser ce genre de tâches et les contributeurs externes devraient avoir la capacité d’utiliser de telles automatisations.
L’intégrations continue (CI) et le déploiement continu (CD) de notre équipe fut bâti en utilisant Azure DevOps (ADO). Cela pose une difficulté pour les contributeurs externes car expérimenter ou mettre à jour la définition du flux de travail requiert qu’ils créent leur propre environnement…
GitHub actions est plus facile à utiliser par des contributrices externes qui n’auront pas besoin d’un compte/environnement supplémentaire. Elles obtiendront automatiquement une copie des flux de travail lors de la copie du repo.
Le flux de travail qui vérifie le niveau d’API Android utilisé par le SDK est un bon exemple d’une tâche répétitive et qui était manuelle auparavant. Android est une « version » de Java et cet environnement ne supporte pas toutes les fonctionnalités de Java. Si un développeur ne teste pas son application sur toutes les versions d’Android qu’elle cible, l’application pourrait planter lors de l’exécution. Grâce à GitHub actions, nous avons automatisé la validation du fait que le SDK n’utilise pas une fonctionnalité qui n’est pas supportée.
Soyez réactif et transparent
Alors que j’étais en train d’explorer les problèmes, j’ai relevé un certain nombre de pratique qui créaient de la frustration pour la communauté :
Manque de réponses ou de suivit
Un manque de réponse va forcer la communauté à demander un suivit et créer de la frustration. Les gens seront compréhensifs vis-à-vis du fait d’avoir d’autres priorités si elles sont communiquées clairement. Assurez-vous de répondre aux discussions et de fournir des mises à jour sur le progrès.
Allers-retours pour plus d’informations
Vous devriez utiliser un modèle de problèmes afin d’encourager les gens à fournir tous les détails dont vous avez besoin durant la création du problème. Vous pouvez aussi étiqueter les problèmes afin d’améliorer leur visibilité. (ex. « besoin de plus d’information », « requiert de l’attention », « requiert triage », « bug »…)
Ne pas tenir ses promesses
Suivre et tenir des dates de livraison sur chaque fonctionnalité/correctif de manière individuelle est difficile. Pour cette raison, évitez de fournir une date de résolution pour chaque élément, vous vous engagez sur une pente glissante. A la place, utilisez des jalons qui communiqueront les informations suivantes :
- La date provisionnelle de livraison.
- Le contenu de cette livraison : la liste de problèmes qu’elle contient.
- La priorité relative de ces problèmes : in problème dans un jalon à échéance plus courte est plus urgent qu’un autre dans un jalon à échéance plus longue.
Les jalons demandent peu d’efforts à tenir à jour et sont faciles à comprendre pour quelqu’un qui n’est pas habitué à ce repo en particulier. Puisque le contenu ET la date peuvent changer, cela vous donne plus de flexibilité pour ajuster vos plans au besoin. Vous devirez toujours fournir une explication lorsque vous changez vos plans : « nous avons découvert des que des changements additionnels sont requis en travaillant sur ça »…
Maintien d’un environnement sain
« Sans respect, aucune confiance ne peut naître » Code moral du Judo.
Les auteurs de problèmes n’ont bien souvent pas l’intention d’être irrespectueux lorsqu’ils utilisent un langage familier. Il faut prendre en considération les différences culturelles et le contexte de lecture lorsque l’on évalue une discussion. Dans 99% des cas le fait de donner un avertissement pour une erreur bégnine suffit à résoudre la situation. Lorsque l’intention était de causer des dégâts, je verrouille la discussion et la rapporte à GitHub.
Évitez le burn-out
Grâce à tous vous efforts, l’activité du repo va augmenter et peut devenir débordante. Vous ne récupérerez qu’en protégeant vos moments personnels. J’ai désactivé les notifications par courriel de GitHub pour me reposer uniquement sur la page de notifications. Je vous recommande aussi de configurer en détails vos abonnements et de configurer les heures calmes sur l’application mobile.
Conclusion
J’espère que le partage de mon expérience avec le SDK Java Microsoft Graph vous aidera à tirer le meilleur parti de votre expérience open-source. Si vous avez d’autres astuces que je n’ai pas mentionnées ici, laissez les dans les commentaires!