L'aventure Ember Initiative 🐹❤️ Semaine 18

Semaine 18 – Concatenation de petites choses

#web #emberjs #open_source #github #help_wanted #good_first_issue #fork #contributing #ember_scroll_modifiers

L’Ember Initiative a besoin de plus de membres pour que nous puissions y consacrer plus de temps 🙏 Depuis ma réaffectation, j’ai pu passer un peu plus de 2 jours à travailler sur l’Initiative, et ce temps m’a permis de faire quelques premières choses pour la communauté. Mais pour organiser et aborder des sujets importants comme la nouvelle API du gestionnaire de routes, nous devons investir un temps que nous n’avons pas encore. Les nouveaux plans de Mainmatter facilitent l’adhésion des petites entreprises à l’Initiative.

Conseils open source pour les débutant·es #

Le travail open source est une part significative de l’Ember Initiative (bien que les membres puissent également bénéficier de sessions de pair programming pour leurs projets internes), mais j’ai l’impression de ne pas avoir beaucoup parlé des bases du développement open source. Puisque j’ai fait ma première contribution sur ember-scroll-modifiers cette semaine, c’est un bon moment pour y revenir.

Besoin d’aide ou envie d’aider : les labels courants #

Si vous vous intéressez à l’open source mais que vous débutez, une chose intéressante à savoir est la convention « universelle » sur GitHub. Sur GitHub, vous pouvez attribuer des labels aux Pull Requests et aux Issues. Lorsqu’un·e maintainer crée un nouveau projet, quelques labels sont déjà disponibles par défaut, et deux d’entre eux sont très importants pour communiquer avec les autres développeur·ses : « help wanted » et « good first issue ». Leur signification est assez explicite, mais développons tout de même :

• « help wanted » : le·a maintainer d’un dépôt doit utiliser ce label lorsqu’iel a besoin d’aide pour résoudre une issue ou finaliser une pull request, mais manque de temps ou de ressources. C’est un appel littéral à l’aide, mais la complexité de la PR dépend du contexte.

• « good first issue » : le·a maintainer doit utiliser ce label sur des issues qu’iel estime faciles à résoudre. C’est quelque chose qu’iel pourrait faire iel-même, mais s’iel n’a pas le temps ou a d’autres priorités, iel peut laisser cette issue à quiconque souhaiterait contribuer sans avoir beaucoup de connaissances sur le dépôt.

Comment contribuer : les bases, les vraies #

Il y a longtemps, j’étais une développeuse qui n’avait jamais contribué à un dépôt open source. Quand le moment est enfin arrivé, ma première action innocente a été de cloner le dépôt, d’écrire mes modifications et de pousser une branche. Mais je n’avais pas le droit de pousser cette branche… C’était un peu problématique. Comment contribuer à un dépôt qui ne vous appartient pas ? Si vous êtes maintainer d’un dépôt, je ne peux que vous encourager à expliquer le système de fork, ou à pointer vers des ressources qui l’expliquent.

En tant que contributeur·ice, en général, vous n’êtes pas autorisé·e à pousser des branches sur le dépôt de quelqu’un d’autre, sauf si vous avez été désigné·e comme contributeur·ice officiel·le. La méthode standard consiste à créer votre propre fork du dépôt. GitHub vous permet de le faire très facilement avec le bouton « Fork » lorsque vous visitez un dépôt. Par exemple, pour contribuer à ember-scroll-modifiers, qui appartient à @elwayman02, j’ai créé : https://github.com/BlueCutOfficial/ember-scroll-modifiers.

Les PR que j’ouvre dans BlueCutOfficial/ember-scroll-modifiers ne sont pas destinées à être mergées. Je les utilise pour lancer la CI sur mes modifications et m’assurer que mes PR sont prêtes avant de les ouvrir dans le dépôt de @elwayman02. Ce n’est pas quelque chose que je dois faire, c’est juste mon syndrome d’écrivain·e : je vous laisse lire le livre une fois qu’il est prêt à être lu, et il en va de même pour mes PR.

Lorsque vous commencez à créer des PR dans un dépôt forké, vous devez faire attention à la branche de base : la PR peut cibler la branche principale dans votre propre dépôt ou dans le dépôt original. À ma connaissance, si vous ouvrez la PR dans votre dépôt, vous ne pouvez pas modifier la branche de base plus tard pour qu’elle cible le dépôt original. Ce que vous devez faire, c’est créer une deuxième PR avec le bouton « New pull request » dans l’onglet des PR. Vous pouvez alors cibler la branche principale de l’original avec la branche personnalisée sur laquelle vous avez travaillé.

Enfin : n’ayez pas peur. Une PR est une requête, c’est dans le nom. Même si vous ouvrez quelque chose quelque part par erreur, le monde s’en remettra.

Maximiser mon impact sur l’Ember Initiative avec si peu de temps alloué est assez difficile, mais j’ai fait de mon mieux. J’ai retravaillé notre tableau de projet public pour qu’il soit plus aligné avec notre organisation en « amélioration continue » qui a remplacé les trimestres, et j’ai utilisé différents onglets pour communiquer les priorités. J’ai également ouvert quelques PR pour améliorer notre cher ember-vite-codemod, et j’ai commencé à m’impliquer dans la conversion de ember-scroll-modifiers à v2. Je devrais pouvoir avancer un peu la semaine prochaine également.

Intro, Grande pause, Semaine 19