
Partager:
Lorna est une ingénieure en informatique qui a la manie incurable de bloguer. Elle tente d'apprivoiser les mots et le code à parts égales.
Survivre à la Hacktoberfest : Un guide pour les mainteneurs
Temps de lecture : 5 minutes
Joyeuse Hacktoberfest à tous et à toutes ! Contributeurs, j'espère que vous passez un excellent moment à acquérir de nouvelles compétences et à découvrir des projets dans lesquels vous pouvez faire la différence. Mainteneurs, le billet d'aujourd'hui est juste pour vous. J'espère que les changements de règles se traduiront par une meilleure qualité des demandes d'extraction pour vos projets, mais cela peut encore être beaucoup à gérer. Je suis un mainteneur de longue date, et aujourd'hui j'aimerais partager quelques conseils qui, je l'espère, vous aideront.
Vonage est ravi d'être un partenaire du Hacktoberfest 2020. Nous ne sommes pas pas étrangers à l'open sourceavec nos bibliothèques, nos extraits de code et nos démonstrations sur GitHub. Pour vous immerger totalement dans les festivités, n'oubliez pas de consulter notre page Hacktoberfest pour en savoir plus sur tout ce que nous avons prévu !
Parlons priorités
Les mainteneurs de projets open source effectuent la plupart du temps ce travail pendant leur temps "libre", et c'est beaucoup. Ce n'est pas seulement pour Hacktober, et une grande partie du travail peut passer inaperçue. En cette Hacktoberfest, et surtout avec les événements mondiaux qui nous entourent, il est important de réfléchir à vos priorités et de ne pas les perdre de vue !
Je dirais que vous, votre projet, et ensuite ses contributeurs, dans cet ordre, est un bon ordre de priorité. Un projet n'est rien sans les mainteneurs, et beaucoup sont des équipes d'un seul. Les objectifs et le but du projet sont une priorité importante ; il n'y a pas de pression pour étendre la portée ou faire pivoter le projet parce qu'une pull request est arrivée pour le faire. La joie de l'open source est que les gens peuvent utiliser leurs propres forks comme base d'un nouveau projet s'ils n'aiment pas la façon dont vous gérez les choses ! Et enfin les contributeurs ; Hacktoberfest a beaucoup de nouveaux contributeurs, mais nous voulons les élever pour qu'ils deviennent des contributeurs, pas des enfants gâtés. Donc s'ils ont besoin de lire les directives du projet avant de contribuer, dites-le plutôt que de faire beaucoup de travail de reprise vous-même.
Gérer la fatigue liée aux notifications
Le Hacktoberfest est désormais ouvert à tous, mais si vous en faites partie, il est facile de se sentir débordé, en particulier dans le cadre d'un projet de grande envergure ou déjà très chargé. La clé pour s'en sortir est de gérer ses notifications. Et non, une règle d'email pour classer ou supprimer tout ce qui contient le nom de votre projet n'est pas la solution !
Add a filter to file all incoming mail with the word GitHub in
Prenez le temps de configurer vos notifications GitHub pour vous assurer que vous êtes notifié quand vous le souhaitez et que vous ne recevez pas trop de notifications non pertinentes. Vous pouvez également acheminer différentes notifications pour différentes organisations vers différentes adresses électroniques, ce qui peut s'avérer très utile.
Configurer et acheminer les courriels
GitHub dispose d'une excellente documentation d'aide, je ne vais donc pas répéter leur contenu ici, mais je vais vous diriger vers les endroits que je trouve les plus utiles !
Tout d'abord, vous pouvez lier plusieurs adresses électroniques à un seul compte GitHub, ce qui est utile si vous réalisez certains projets professionnels avec votre compte GitHub, ou si vous utilisez une adresse électronique différente pour un projet open source particulier. Jetez un coup d'œil à la documentation sur la vérification d'adresses électroniques supplémentaires sur GitHub.
Ensuite, il faut que les bonnes notifications soient envoyées à la bonne adresse électronique. C'est sous "custom routing" dans la configuration des notifications, et bien sûr, il y a une excellente documentation sur le routage des emails sur GitHub. une excellente documentation sur le routage des courriels sur GitHub.
Regarder et ne pas regarder
La possibilité de "surveiller" un repo est très utile. S'il y a un projet pour lequel vous voulez recevoir toutes les notifications, cliquez sur le bouton "Watch" en haut et choisissez "Watching". C'est utile si vous souhaitez suivre l'activité d'un repo en particulier.

Ce qui est peut-être encore plus précieux, c'est la possibilité de "débloquer" un projet ! Comme je m'occupe d'une partie de la maintenance de GitHub au travail, j'ai accès à de nombreux dépôts, et par défaut, si vous y avez accès, vous êtes abonné aux notifications ! Cela peut être assez bruyant comme vous pouvez l'imaginer, donc le même bouton "Watch" nous donne d'autres options - la valeur par défaut est "Not Watching", donc vous recevrez des notifications sur vos propres problèmes/PRs ou si vous êtes mentionné. Vous pouvez également le régler sur "Ignorer" si vous vous impliquez alors que vous ne le souhaitez pas.
S'abonner et se désabonner
Au niveau de chaque dépôt, vous pouvez également recevoir des notifications sans avoir à commenter la discussion pour vous rendre "participant". Cherchez le bouton "Subscribe" (s'abonner) sur le côté droit, sous "Notifications". Là encore, il existe une option opposée ! Supposons que vous ayez commenté quelque chose pour lequel vous ne souhaitez plus recevoir de notifications. Dans ce cas, vous pouvez vous "désabonner" d'un seul problème ou d'une seule demande d'extraction sans avoir à vous désabonner de l'ensemble du dépôt.
Agir rapidement
Si une demande d'extraction n'est pas utile ou ne répond pas aux objectifs du projet, n'ayez pas peur de la rejeter. La FAQ FAQ Hacktoberfest est votre ami ici. Soyez toujours aimable - mais les réponses rapides sont précieuses si vous avez la disponibilité pour suivre les choses tous les quelques jours. Si une pull request peut être rendue acceptable, par exemple, parce qu'elle fait échouer le build mais peut être corrigée, offrez un feedback à votre nouveau contributeur en expliquant ce qui rendrait la pull request prête à être fusionnée. S'il s'agit d'un changement que vous ne voulez pas (l'emoji pour décorer votre README semble être une contribution populaire), dites-le et fermez la demande.
L'open source n'est pas toujours un lieu accueillant, et nous opérons en public, de sorte que les passants se font une bonne impression de nos projets par la manière dont nous interagissons avec les gens. Prenez le temps de remercier les gens pour leur contribution ! Même si la pull request ne vaut pas le temps que vous avez mis à la lire, un simple "Ceci ne semble pas utile au projet, pourquoi ne pas consulter la liste des problèmes pour des idées ?" est beaucoup plus accueillant que de fermer sans autre communication ou explication.
Merci de votre attention.
Sur cette note de remerciement aux contributeurs, j'aimerais terminer en vous remerciant, vous, le mainteneur. On croit souvent à tort que les projets open source sont maintenus par une figure étonnante, lointaine et héroïque. En fait, ceux d'entre nous qui donnent de leur temps et de leur énergie de cette manière sont de vraies personnes avec de vraies vies.
Merci pour tout ce que vous faites, l'open source change le monde, et à votre manière, vous y contribuez.