10 points par GN⁺ 2024-02-15 | 6 commentaires | Partager sur WhatsApp

La contribution non code, clé du succès de l’open source

  • Sarah Rainsberger, professeure de mathématiques, n’avait pas l’intention de devenir contributrice open source de son plein gré, mais elle a commencé à apprendre JavaScript et le développement web en reconstruisant le site web de sa chorale.
  • En utilisant Astro, un framework frontend, elle a fini par contribuer au projet avec un petit morceau de code, un fichier de configuration, puis a pris un rôle de soutien aux nouveaux utilisateurs d’Astro en participant à la communauté.
  • Rainsberger fait aujourd’hui partie du groupe central des mainteneurs d’Astro, mais elle intervient peu sur la base de code et se consacre surtout à la documentation, tout en aidant les autres à apprendre Astro.

Les tâches non code essentielles dans les projets open source

  • Un projet open source a besoin, au-delà de l’écriture de code, de documentation, de localisation, de marketing, de design graphique, de tests, de gestion de communauté et de gestion des releases.
  • L’importance des contributions non code est considérable : plus un projet est complexe, plus il a besoin de documentation, de tutoriels et de support pour rendre son code réellement utile.
  • Le design graphique, le branding et l’outreach servent aussi de signaux sur la santé et le sérieux d’un projet, ce qui peut encourager d’autres projets ou entreprises à l’utiliser comme dépendance.

Pourquoi commencer par une contribution non code

  • Les contributions non code offrent l’occasion de construire un portfolio pour les personnes intéressées par des rôles sans programmation, comme la communication technique, le design graphique ou le design de l’expérience utilisateur.
  • Les programmeurs eux-mêmes y gagnent en affinant leurs compétences rédactionnelles et de communication, ce qui peut aussi les aider à évoluer vers des rôles comme les relations développeurs ou la gestion de produit.
  • Les projets open source offrent des occasions de participation à tous les niveaux de compétence, et il est difficile d’apporter une contribution de code vraiment utile sans compréhension approfondie du projet.

Trouver des contributeurs non code et leur témoigner de la reconnaissance

  • Pour les mainteneurs, le meilleur moyen de trouver des contributeurs est de demander des tâches précises ; il est aussi utile de bâtir une communauté et d’ouvrir des issues étiquetées "help wanted" et "good first issue".
  • Le mentorat est l’un des meilleurs moyens d’amener les contributeurs vers la réussite, et valoriser puis reconnaître les contributeurs non code aide à motiver les contributeurs actuels et à en attirer de nouveaux.

L’avis de GN⁺

  • Il est important de rappeler que le succès d’un projet open source repose sur bien plus que l’écriture de code. Ces différentes formes de contribution sont essentielles à sa pérennité et à sa croissance.
  • Les contributions non code offrent aussi aux personnes non techniques une porte d’entrée vers l’open source, tout en pouvant les aider à développer des compétences techniques.
  • Cet article peut inspirer celles et ceux qui s’intéressent à la communauté open source et les aider à trouver comment mettre leurs compétences au service de cette communauté.

6 commentaires

 
secret3056 2024-02-15

C’est un peu différent comme sujet, mais il y a quelque temps, quelqu’un a publié un tutoriel expliquant comment faire une PR sur le fichier README d’Express.js, ce qui a entraîné des centaines de PR sans aucune utilité.

Pull requests · expressjs/express

 
mdisprgm 2024-02-16

Une nuisance... snif

 
edunga1 2024-02-15

Il y a plus de 100 PR, quand même, wow

 
sagee 2024-02-15

J’ai eu un petit moment de confusion sur la façon de contribuer avec du « barcode ».. haha
Une documentation très détaillée peut aussi être, d’une certaine manière, une arme à double tranchant.
Il peut y avoir des cas où la documentation et les captures d’écran deviennent si détaillées que les développeurs n’ont plus confiance dans leur capacité à les mettre à jour, et finissent par renoncer à développer des améliorations..

 
cosine20 2024-02-16

(« non ») du code)

 
GN⁺ 2024-02-15
Avis Hacker News
  • En tant qu’auteur/mainteneur de petites bibliothèques, je peux confirmer que sans contributions externes, les manuels ne seraient pas aussi bons qu’aujourd’hui. Les manuels contribuent fortement à l’utilisabilité d’un projet.

    • En tant que nouvel utilisateur de libcurl, les tutoriels et la documentation API m’ont permis d’implémenter rapidement un envoi FTP et de l’adapter à un cas d’usage spécifique.
    • Grâce à la documentation, j’ai pu prendre conscience du manque de sécurité des threads dans les anciennes versions et avertir mon équipe de faire une mise à jour.
    • La documentation est aussi importante que le code et la suite de tests.
  • Souhaits pour les projets open source :

    • beaucoup de captures d’écran
    • un README.md très long et détaillé
    • des tutoriels, une documentation de référence, des documents de conception et des diagrammes d’architecture
    • un document de modèle mental expliquant la manière de penser de l’auteur
  • Dans l’open source, la documentation, les ressources, etc. sont importantes, mais cela peut aussi donner du pouvoir à des non-développeurs et finir par ruiner un projet.

    • Cela peut nuire à la stabilité, aux fonctionnalités et à l’adoption, par exemple en refaisant l’UX à chaque release.
    • Cela attire des personnes très portées sur la politique, et il est facile que du "bikeshedding" se produise dans des domaines que tout le monde pense pouvoir traiter.
  • Il est utile d’utiliser des plateformes de chat comme Discord, Gitter et Slack pour construire une communauté.

    • Cela permet aux gens de ne pas hésiter à poser des questions dans le dépôt.
    • Poser une question sur GitHub ou créer une pull request qui résout un problème donne souvent l’impression d’avoir inutilement beaucoup de conséquences.
    • Parmi les créateurs de projets GitHub, l’attitude consistant à dire « j’ai publié le code, je ne vous dois rien de plus » est très répandue.
  • Sur la base d’une expérience dans la communauté WordPress, on pense que la documentation initiale et la solide documentation du Codex ont fortement contribué à la croissance de WordPress.

    • À l’époque où Joomla, Drupal et WordPress avaient des bases installées comparables, WordPress était plus facile à prendre en main grâce à l’abondance de sa documentation.
  • Le plus grand souhait pour un projet open source est que les gens l’utilisent et laissent une trace, sous une forme ou une autre, de ce qu’ils en ont fait.

    • Laisser un message sur le canal Discord du projet, un tweet, un court message, une capture d’écran, un gist, un dépôt GitHub public, une vidéo YouTube ou TikTok : tout cela constitue une contribution très précieuse au projet.
  • Je ne sais pas si les contributions non liées au code sont le secret du succès d’un projet, mais je suis d’accord sur le fait qu’elles sont très importantes.

    • Par exemple, l’Eclipse Foundation rappelle aussi aux utilisateurs que les rapports de bug sont des contributions précieuses.
  • Lorsqu’on lance un projet open source, on peut s’attendre à ce qu’il y ait dix fois plus d’ingénieurs qui utiliseront le logiciel que d’ingénieurs qui écriront réellement du code.

    • Les utilisateurs doivent pouvoir contribuer en améliorant la documentation.
    • Lorsqu’on génère de la documentation (manuel utilisateur) avec un générateur de site statique comme Hugo, il faut un moyen pour que les utilisateurs puissent soumettre des corrections/mises à jour de la documentation sans devoir créer une issue GitHub.
  • Si des personnes non techniques comprennent le projet et y trouvent de la valeur, c’est un bon indicateur de réussite.

  • La documentation devient importante lorsqu’un produit passe d’un stade où il est utilisé par des fans malgré son manque de notoriété à un stade où il cherche à toucher davantage d’utilisateurs.

    • Sans bonne documentation, il est difficile de franchir cette étape.
    • Cela rappelle qu’il faut rédiger un guide utilisateur pour Neural Amp Modeller.