Devenez un Millionnaire de l'Open Source*

En 3 Étapes Simples...

En seulement 3 étapes simples, je vais vous montrer comment transformer votre récent travail de codage en PR significatives !

• Tout dégoulinant de donations ? 💰
• Roulant dans les repos ? 🏎️
• Rebasant Robb Report ? 🤯

Allons-y !!!!!

La Réalité

Nous avons tous entendu à quel point il est bénéfique de contribuer à l’Open Source. Mais, il n’est pas toujours facile de commencer.

Au fil de ma carrière, j’ai écrit de nombreuses PR pour des dizaines de repositories de 10 000 étoiles. Mes modestes contributions ont atterri dans Node.js, Docker, Lodash, Bluebird, Gatsby, Rancher, Angular, React Router, Minio, MDN (Mozilla Developer Network) et bien d’autres.

Je vais partager mon secret pour des contributions faciles, mais nous devons d’abord discuter des problèmes avec les conseils conventionnels.

Ce n’est (Pas) Comme Ça Qu’on Fait

Pourquoi est-il difficile de contribuer à l’Open Source ?

Le conseil le plus courant se situe quelque part entre l’inutile et le terrible : Trouvez une issue GFI (label Good First Issue) et résolvez-la. Ou, contribuez à un projet par pur amour.

C’est bien intentionné, mais en pratique les labels GFI sont hautement subjectifs, et impliquent souvent une quantité de travail surprenante.

Et si je vous disais que le meilleur endroit pour chercher est les solutions que vous avez déjà trouvées ?

Une Meilleure Façon de Faire

✅ Parcourez les fichiers de dépendances de votre projet. Quelles bibliothèques provoquent votre rage ? Qu’est-ce qui a mené à une deadline manquée ? Comment avez-vous surmonté cela ?

💪 En commençant par quelque chose que vous avez déjà résolu, pas besoin de vous demander si vous en êtes capable. Vous êtes déjà fluide et familier avec le contexte !

Puisque vous avez déjà résolu le problème, la plus grande partie du travail est faite. Ensuite, vous devez déterminer comment aider les autres à éviter complètement votre galère.

Peut-être qu’un Tweet ou une réponse Stack Overflow suffira, mais si vous voulez avoir un impact durable, contribuez au projet lui-même.

Le Brainstorm

De préférence alors que l’expérience est encore assez fraîche, réfléchissez à la façon dont votre cerveau de dumb dumb s’est autant perdu en premier lieu.

Qu’avez-vous essayé en premier ? Et pourquoi ? Qu’avez-vous supposé ? Ou mal compris ?

💪 Vous n’avez pas besoin de trouver une solution parfaite, souvent de simples mises à jour du readme ou de la documentation peuvent sauver les autres d’innombrables heures de galère.

• Un README dépassé ? Des exemples manquants ou mauvais ? Des étapes de configuration omises ? Correction simple, incluez toute information manquante !
• La documentation de l’API n’apparaît pas dans vos résultats Google. Ajustez ou traduisez un langage trop technique.
• Peut-être est-ce un oversight technique, et le site de documentation manque les balises <meta/> nécessaires. Corrigez-le si vous savez comment, ou rédigez un ticket avec vos conclusions.
• Si c’est un problème de compétences… Travaillez ces compétences !

Ces types de problèmes sont faciles à manquer pour les mainteneurs ! Et peuvent avoir un impact étonnamment important sur le projet et ses utilisateurs.

La prochaine fois que vous conquérez un challenge, ne rebasez pas vos hacks désespérés ! Réfléchissez plutôt à votre galère et partagez votre solution publiquement !

Bon, les Petits Caractères

Suivez toujours les directives du projet, et ne soyez jamais un connard. ✨

Tout est public. Alors, soyez gracieux, génial, et reconnaissant.

Si vous avez besoin de plus de persuasion : contribuez pour apprendre ! Nouveaux processus, langages, frameworks, automatisation !

🚀

Si vous avez trouvé cela utile, partagez vos contributions dans les commentaires ou postez-les sur Twitter et taguez-moi @justsml.