Que signifie être un mainteneur?
Si vous gérez un projet Open Source que beaucoup de personnes utilisent, vous avez peut-être remarqué que vous codez moins et que vous répondez à d’autres problèmes.
Au début d’un projet, vous expérimentez de nouvelles idées et prenez des décisions en fonction de ce que vous voulez. Au fur et à mesure que votre projet gagne en popularité, vous travaillerez de plus en plus avec vos utilisateurs et vos contributeurs.
Maintenir un projet nécessite plus que du code. Ces tâches sont souvent inattendues, mais elles sont tout aussi importantes pour un projet en croissance. Nous avons rassemblé quelques moyens pour vous faciliter la vie, de la documentation des processus à l’exploitation de votre communauté.
Documenter vos processus
Écrire des documentations est l’une des choses les plus importantes que vous pouvez faire en tant que mainteneur.
La documentation clarifie non seulement votre propre pensée, mais elle aide les autres à comprendre ce dont vous avez besoin ou ce que vous attendez, avant même de le demander.
la Rédaction des documentations rend plus facile de dire non, quand quelque chose ne rentre pas dans votre champ d’application. Cela facilite également la tâche des gens. Vous ne savez jamais qui pourrait lire ou utiliser votre projet.
Même si vous n’utilisez pas de paragraphes entiers, mieux vaut ne pas écrire du tout.
N’oubliez pas de garder votre documentation à jour. Si vous n’êtes pas en mesure de toujours le faire, supprimez votre documentation obsolète ou indiquez qu’elle est obsolète afin que les contributeurs sachent que les mises à jour sont les bienvenues.
Ecrivez la vision de votre projet
Commencez par écrire les objectifs de votre projet. Ajoutez-les à votre fichier README ou créez un fichier distinct appelé VISION. S’il y a d’autres artefacts qui pourraient aider, comme une feuille de route de projet, faites-les aussi publics.
Avoir une vision claire et documentée vous permet de rester concentré et vous aide à éviter le «fluage portée» des contributions des autres.
Par exemple, @lord a découvert que le fait d’avoir une vision de projet l’aidait à déterminer les demandes pour lesquelles il devait passer du temps. En tant que nouveau responsable, il a regretté ne pas s’en tenir à la portée de son projet quand il a eu sa première demande de Slate.
Communiquez vos attentes
Les règles peuvent être angoissantes à écrire. Parfois, vous pourriez avoir l’impression de surveiller le comportement des autres ou de tuer tout le plaisir.
Écrit et appliqué équitablement, cependant, de bonnes règles habilitent les mainteneurs. Ils vous empêchent d’être entraînés à faire des choses que vous ne voulez pas faire.
La plupart des personnes qui rencontrent votre projet ne savent rien de vous ou de votre situation. Ils peuvent supposer que vous êtes payé pour travailler dessus, surtout si c’est quelque chose qu’ils utilisent régulièrement et dont ils dépendent. Peut-être qu’à un moment donné, vous avez consacré beaucoup de temps à votre projet, mais maintenant vous êtes occupé avec un nouvel emploi ou un membre de votre famille.
Tout cela est parfaitement correct! Assurez-vous simplement que les autres personnes le savent.
Si le maintien de votre projet est à temps partiel ou purement volontaire, soyez honnête quant au temps dont vous disposez. Ce n’est pas la même chose que le temps que vous estimez nécessaire au projet ou combien de temps les autres vous demandent.
Voici quelques règles qui méritent d’être notées:
- Comment une contribution est examinée et acceptée (Ont-ils besoin de tests? Un modèle de problème?)
- Les types de contributions que vous accepterez (Voulez-vous seulement de l’aide pour une certaine partie de votre code?)
- Quand est-il approprié de faire un suivi (par exemple, “Vous pouvez vous attendre à une réponse d’un responsable dans les 7 jours, si vous n’avez encore rien entendu, n’hésitez pas à envoyer une requête ping au fil.”)
- Combien de temps consacrez-vous au projet (_par exemple, “Nous ne consacrons que 5 heures par semaine à ce projet” _)
Jekyll, CocoaPods, et Homebrew sont plusieurs exemples de projets avec des règles de base pour les mainteneurs et les contributeurs.
Gardez la communication publique
N’oubliez pas de documenter vos interactions, aussi. Partout où vous pouvez, gardez la communication sur votre projet public. Si quelqu’un tente de vous contacter en privé pour discuter d’une demande de fonctionnalité ou d’un besoin de support, dirigez-les poliment vers un canal de communication public, tel qu’une liste de diffusion ou un outil de suivi des problèmes.
Si vous rencontrez d’autres responsables, ou prenez une décision importante en privé, documentez ces conversations en public, même si cela ne concerne que la publication de vos notes.
De cette façon, toute personne qui se joint à votre communauté aura accès à la même information que quelqu’un qui est là depuis des années.
Apprendre à dire non
Vous avez écrit des choses. Idéalement, tout le monde lirait votre documentation, mais en réalité, vous devrez rappeler aux autres que cette connaissance existe.
Cependant, tout noter contribue à dépersonnaliser les situations lorsque vous devez appliquer vos règles.
Dire non n’est pas amusant, mais “Votre contribution ne correspond pas aux critères de ce projet” se sent moins personnelle que “Je n’aime pas votre contribution”.
Dire non s’applique à de nombreuses situations que vous rencontrerez en tant que responsable: des demandes de fonctionnalités qui ne correspondent pas à la portée, quelqu’un qui déraille une discussion, qui fait un travail inutile pour les autres.
Gardez la conversation amicale
L’un des endroits les plus importants que vous entraînez en disant non est sur votre problème et tire la file d’attente des demandes. En tant que responsable du projet, vous recevrez inévitablement des suggestions que vous ne souhaitez pas accepter.
Peut-être que la contribution modifie la portée de votre projet ou ne correspond pas à votre vision. Peut-être que l’idée est bonne, mais la mise en œuvre est mauvaise.
Peu importe la raison, il est possible de gérer avec tact les contributions qui ne répondent pas aux normes de votre projet.
Si vous recevez une contribution que vous ne voulez pas accepter, votre première réaction pourrait être de l’ignorer ou de prétendre que vous ne l’avez pas vue. Cela pourrait nuire aux sentiments de l’autre et même démotiver d’autres contributeurs potentiels dans votre communauté.
Ne laissez pas une contribution indésirable ouverte parce que vous vous sentez coupable ou que vous voulez être gentil. Au fil du temps, vos problèmes sans réponse et les relations publiques rendront le travail sur votre projet beaucoup plus stressant et intimidant.
Il est préférable de fermer immédiatement les contributions que vous ne voulez pas accepter. Si votre projet souffre déjà d’un important retard, @steveklabnik a des suggestions pour comment trier efficacement les problèmes.
Deuxièmement, ignorer les contributions envoie un signal négatif à votre communauté. Contribuer à un projet peut être intimidant, surtout s’il s’agit de la première fois. Même si vous n’acceptez pas leur contribution, remerciez la personne derrière et remerciez-les de leur intérêt. C’est un gros compliment!
Si vous ne voulez pas accepter une contribution:
- remercier les pour leur contribution
- Expliquez pourquoi cela ne rentre pas dans la portée du projet, et offrir des suggestions claires pour l’amélioration, si vous êtes capable. Soyez gentil, mais ferme.
- Lien vers la documentation pertinente, si tu l’as. Si vous remarquez des demandes répétées pour des choses que vous ne voulez pas accepter, ajoutez-les dans votre documentation pour éviter de vous répéter.
- Fermez la demande Vous ne devriez pas avoir besoin de plus de 1-2 phrases pour répondre. Par exemple, lorsqu’un utilisateur de céleri a signalé une erreur liée à Windows, @berkerpeksag répondu avec:
Si la pensée de dire non vous terrifie, vous n’êtes pas seul. Comme @jessfraz put it:
J’ai parlé à des responsables de plusieurs projets open source différents, Mesos, Kubernetes, Chromium, et ils sont tous d’accord que l’un des aspects les plus difficiles d’un mainteneur est de dire “Non” aux correctifs que vous ne voulez pas.
Ne vous sentez pas coupable de ne pas vouloir accepter la contribution de quelqu’un. La première règle de l’open source, d’apres @shykes: “Non est temporaire, oui est pour toujours.” Tandis que l’empathie avec l’enthousiasme d’une autre personne est une bonne chose, rejeter une contribution n’est pas la même chose que rejeter la personne derrière elle.
En fin de compte, si une contribution n’est pas suffisante, vous n’êtes pas obligé de l’accepter. Soyez gentil et réactif lorsque les gens contribuent à votre projet, mais n’acceptez que les changements qui, selon vous, amélioreront votre projet. Le plus souvent vous pratiquez en disant non, plus cela devient facile. Promettre.
Etre pro-actif
Pour réduire le volume des contributions non désirées, expliquez le processus de soumission et d’acceptation des contributions de votre projet dans votre guide.
Si vous recevez trop de contributions de faible qualité, demandez aux contributeurs de faire un peu de travail à l’avance, par exemple:
- Remplir un problème ou un modèle de PR / liste de contrôle
- Ouvrir un problème avant de soumettre un RP
S’ils ne respectent pas vos règles, fermez immédiatement le problème et pointez vers votre documentation.
Bien que cette approche puisse sembler méchante au début, être proactif est réellement bon pour les deux parties. Cela réduit le risque que quelqu’un consacre beaucoup d’heures de travail perdues à une demande de retrait que vous n’allez pas accepter. Et cela rend votre charge de travail plus facile à gérer.
Parfois, quand vous dites non, votre contributeur potentiel peut se fâcher ou critiquer votre décision. Si leur comportement devient hostile, prendre des mesures pour désamorcer la situation ou même les retirer de votre communauté, s’ils ne veulent pas collaborer de manière constructive.
Embrasser le mentorat
Peut-être que quelqu’un dans votre communauté soumet régulièrement des contributions qui ne répondent pas aux normes de votre projet. Il peut être frustrant pour les deux parties de passer à plusieurs reprises par des rejets.
Si vous voyez que quelqu’un est enthousiaste à propos de votre projet, mais qu’il a besoin d’un peu de poli, soyez patient. Expliquer clairement dans chaque situation pourquoi leurs contributions ne répondent pas aux attentes du projet. Essayez de les diriger vers une tâche plus facile ou moins ambiguë, comme un problème marqué «bon premier bug», pour se mouiller les pieds. Si vous avez le temps, envisagez de les encadrer à travers leur première contribution, ou de trouver quelqu’un d’autre dans votre communauté qui pourrait être disposé à les encadrer..
Tirer parti de votre communauté
Vous n’avez pas à tout faire vous-même. La communauté de votre projet existe pour une raison! Même si vous n’avez pas encore de communauté de contributeurs actifs, si vous avez beaucoup d’utilisateurs, mettez-les au travail..
Partagez la charge de travail
Si vous cherchez d’autres personnes, commencez par demander.
Lorsque vous voyez de nouveaux contributeurs faire des contributions répétées, reconnaissez leur travail en offrant plus de responsabilités. Documentez comment les autres peuvent devenir des leaders s’ils le souhaitent.
Encourager les autres à partager la propriété du projet peut grandement réduire votre charge de travail, comme @lmccart l’a découvert sur son projet, p5.js.
Si vous avez besoin de quitter votre projet, que ce soit en pause ou en permanence, il n’y a pas de honte à demander à quelqu’un d’autre de vous remplacer.
Si d’autres personnes sont enthousiastes à l’égard de sa direction, donnez-leur l’autorisation de s’engager ou remettez officiellement le contrôle à quelqu’un d’autre. Si quelqu’un a bifurqué votre projet et le maintient activement ailleurs, envisagez de créer un lien vers la fourche de votre projet d’origine. C’est génial que tant de gens veulent que votre projet continue à vivre!
@progrium trouvé ceci documenter la vision de son projet, Dokku, aidé à atteindre ces objectifs même après s’être retiré du projet:
J’ai écrit une page wiki décrivant ce que je voulais et pourquoi je le voulais. Pour une raison ou une autre, j’ai été surpris de constater que les responsables ont commencé à faire avancer le projet dans cette direction! Est-ce arrivé exactement comment je le ferais? Pas toujours. Mais cela rapprochait encore le projet de ce que j’avais écrit.
Laissez les autres construire les solutions dont ils ont besoin
Si un contributeur potentiel a une opinion différente sur ce que votre projet devrait faire, vous pouvez les encourager doucement à travailler sur leur propre fourchette.
Forking un projet ne doit pas être une mauvaise chose. Etre capable de copier et de modifier des projets est l’une des meilleures choses à propos de l’open source. Encourager les membres de votre communauté à travailler sur leur propre branche peut fournir le débouché créatif dont ils ont besoin, sans entrer en conflit avec la vision de votre projet.
La même chose s’applique à un utilisateur qui veut vraiment une solution que vous n’avez tout simplement pas le temps à construire. L’offre d’API et de hooks de personnalisation peut aider les autres à répondre à leurs propres besoins, sans avoir à modifier directement la source. @orta trouvé ceci des plugins encourageants pour CocoaPods ont conduit à “quelques-unes des idées les plus intéressantes”:
Il est presque inévitable qu’une fois qu’un projet prend de l’ampleur, les mainteneurs doivent être beaucoup plus conservateurs quant à la façon dont ils introduisent un nouveau code. Vous devenez bon à dire «non», mais beaucoup de gens ont des besoins légitimes. Ainsi, vous finissez par convertir votre outil en plate-forme.
Apportez les robots
Tout comme il existe des tâches que d’autres personnes peuvent vous aider, il y a aussi des tâches que personne ne devrait jamais avoir à faire. Les robots sont votre ami. Utilisez-les pour rendre votre vie de mainteneur plus facile.
Exiger des tests et d’autres vérifications pour améliorer la qualité de votre code
L’un des moyens les plus importants pour automatiser votre projet consiste à ajouter des tests.
Les tests aident les contributeurs à croire qu’ils ne briseront rien. Ils facilitent également la consultation et l’acceptation des contributions rapidement. Plus vous êtes réactif, plus votre communauté peut être engagée.
Configurez des tests automatiques qui s’exécuteront sur toutes les contributions entrantes, et assurez-vous que vos tests peuvent être facilement exécutés localement par les contributeurs. Exiger que toutes les contributions de code passent vos tests avant de pouvoir être soumis. Vous aiderez à définir une norme de qualité minimale pour toutes les soumissions. Vérifications d’état requises sur GitHub, vous pouvez vous assurer qu’aucun changement ne sera effectué sans que vos tests ne passent.
Si vous ajoutez des tests, assurez-vous d’expliquer comment ils fonctionnent dans votre fichier CONTRIBUTING.
Utiliser des outils pour automatiser les tâches de maintenance de base
Les bonnes nouvelles à propos du maintien d’un projet populaire sont que d’autres responsables ont probablement fait face à des problèmes similaires et ont construit une solution pour cela.
Il ya un variété d’outils disponibles pour aider à automatiser certains aspects du travail de maintenance. Quelques exemples:
- semantic-release automatise vos versions
- mention-bot mentionne les évaluateurs potentiels pour les demandes d’extraction
- Danger aide à automatiser l’examen du code
Pour les rapports de bugs et autres contributions communes, GitHub a Modèles de problèmes et modèles de demande de tirage, que vous pouvez créer pour rationaliser la communication que vous recevez. @TalAter a fait un Choisissez votre guide d’aventure pour vous aider à écrire votre problème et vos modèles de relations publiques.
Pour gérer vos notifications par e-mail, vous pouvez configurer filtres d’email organiser par priorité.
Si vous souhaitez être un peu plus avancé, les guides de style et les linters peuvent standardiser les contributions de projet et les rendre plus faciles à consulter et à accepter.
Cependant, si vos normes sont trop compliquées, elles peuvent augmenter les obstacles à la contribution. Assurez-vous d’ajouter suffisamment de règles pour faciliter la vie de tous.
Si vous n’êtes pas sûr des outils à utiliser, regardez ce que font les autres projets populaires, en particulier ceux de votre écosystème. Par exemple, à quoi ressemble le processus de contribution pour les autres modules Node? L’utilisation d’outils et d’approches similaires rendra votre processus plus familier à vos contributeurs cibles.
C’est bon de prende une pause
Le travail open source vous a déjà apporté de la joie. Peut-être que maintenant ça commence à vous faire sentir évitante ou coupable.
Peut-être vous sentez-vous débordé ou un sentiment croissant d’effroi quand vous pensez à vos projets. Et pendant ce temps, les problèmes et les demandes d’extraction s’accumulent.
le Burnout est un problème réel et omniprésent dans le travail open source, en particulier chez les mainteneurs. En tant que mainteneur, votre bonheur est une exigence non négociable pour la survie de tout projet open source.
Bien que cela devrait aller de soi, faites une pause! Vous ne devriez pas avoir à attendre jusqu’à ce que vous vous sentiez brûlé pour prendre des vacances. @brettcannon, un développeur de noyau Python, a décidé de prendre des vacances d’un mois après 14 années de travail bénévole à l’OSS.
Tout comme n’importe quel autre type de travail, prendre des pauses régulières vous gardera rafraîchi, heureux et excité par votre travail.
Parfois, il peut être difficile de faire une pause dans le travail open source quand on a l’impression que tout le monde a besoin de vous. Les gens peuvent même essayer de vous faire sentir coupable d’avoir abandonné.
Faites de votre mieux pour trouver du support pour vos utilisateurs et votre communauté pendant votre absence d’un projet. Si vous ne trouvez pas le soutien dont vous avez besoin, faites une pause de toute façon. Assurez-vous de communiquer lorsque vous n’êtes pas disponible, afin que les gens ne soient pas perturbés par votre manque de réactivité.
Prendre des pauses s’applique à plus que de simples vacances, aussi. Si vous ne voulez pas faire du travail open source le week-end, ou pendant les heures de travail, communiquez ces attentes aux autres, afin qu’ils sachent ne pas vous déranger.
Prenez soin de vous en premier!
Maintenir un projet populaire nécessite des compétences différentes des étapes précédentes de la croissance, mais ce n’est pas moins gratifiant. En tant que responsable, vous pratiquerez le leadership et les compétences personnelles à un niveau que peu de gens connaissent. Bien que ce ne soit pas toujours facile à gérer, définir des limites claires et ne prendre que ce qui vous convient vous aidera à rester heureux, régénéré et productif.
