Comment dois-je contribuer à un projet GitHub (principalement) abandonné?
J'ai récemment essayé de me lancer dans une collaboration open source dans GitHub et j'ai rencontré une situation pour laquelle je suis curieux de savoir quelle est la meilleure façon de procéder.
Il y a environ un mois, j'ai trouvé sur GitHub un projet pour une bibliothèque que j'utilisais déjà depuis un moment et dans laquelle j'avais trouvé (et corrigé) quelques bugs.
Comme première incursion dans la collaboration GitHub, j'ai trouvé le dépôt qui semblait avoir le plus haut volume d'activité récente, corrigé un bogue, ajouté des tests unitaires, poussé vers GitHub et fait une demande de pull. En quelques heures, le responsable du dépôt que j'ai bifurqué avait accepté le PR et avait fusionné avec quelques autres PR d'autres personnes qui attendaient également.
Stimulé par cela, j'ai corrigé trois autres bogues que j'avais trouvés, chacun dans une branche distincte de mon propre référentiel, et déposé un problème et une demande de tirage pour chacun séparément.
C'était il y a un peu plus d'un mois, et les demandes de retrait sont restées inchangées depuis. L'utilisateur dont le repo j'avais fourchu ne semble pas être très actif, n'ayant fait que 7 contributions totales sur GitHub au cours de la dernière année, et ce repo n'a eu aucun engagement depuis la première demande de pull que j'ai faite.
Donc ma question:
Comment procède-t-on dans cette situation? Idéalement, je voudrais éviter de créer une fragmentation de la bibliothèque en partant et en faisant tout un tas de changements dans mon propre référentiel qui ne sont pas fusionnés dans le référentiel parent. Néanmoins, je voudrais continuer à faire des corrections de bugs et à ajouter des fonctionnalités, mais si je fusionne tout dans ma branche principale et que je base toutes les nouvelles corrections hors de cette branche, alors si le mainteneur du dépôt que j'ai bifurqué revient, je gagne Je ne peux pas diviser toutes les modifications en demandes de tirage distinctes pour chaque correction de fonctionnalité/bogue (j'ai lu que les demandes de tirage devraient généralement être une demande de tirage par fonction ou correction de bogue).
Dois-je conserver une branche en phase avec le référentiel d'origine, baser toutes mes nouvelles branches sur celle-ci, puis conserver toutes les validations fusionnées dans ma branche principale? Il semble que cela me laisserait une tonne de branches et une tâche de plus en plus lourde à chaque fois que je dois fusionner de nouveaux changements dans ma branche principale.
Quelle est la façon typique dont on aborderait une situation comme celle-ci? Il semble assez courant qu'un projet soit simplement abandonné, les contributeurs d'origine n'étant pas là pour examiner les nouvelles demandes d'extraction. Est-ce une situation où quelqu'un devrait simplement prendre la barre et courir avec? Il semble que cela créerait une fragmentation si les contributeurs d'origine revenaient un jour et souhaitaient travailler à nouveau sur le projet.
Je n'ai pas encore eu cette situation, mais c'est ce que j'essaierais:
Essayez de contacter le propriétaire
Peut-être ont-ils vraiment perdu tout intérêt, mais sont prêts à transférer le projet à quelqu'un d'autre, en particulier à quelqu'un qui a déjà fait preuve d'un engagement prévenant.
Mais peut-être qu'ils sont simplement occupés par autre chose (travail, vacances, maladie, autres projets) et n'ont pas eu le temps de gérer vos relations publiques, mais prévoyez de le faire plus tard.
Ou peut-être ont-ils vraiment arrêté définitivement de travailler sur le projet pour une raison quelconque.
Sans demander, vous ne le découvrirez pas.
Entrez en contact avec la communauté
Il y a sûrement d'autres personnes qui ont contribué ou du moins utilisé le projet. Vérifiez qui a bifurqué le projet (même s'ils n'ont apporté aucun changement, ils pourraient toujours être intéressés à voir ce projet prospérer); Vérifiez qui a signalé des problèmes ou commenté ces derniers. Peut-être qu'il y a aussi une communauté en dehors de GitHub, par exemple une liste de diffusion, un forum ou des membres StackOverflow.
Je suis finalement vous reprenez vraiment le projet, vous voudrez peut-être leur soutien. Et ils doivent savoir où se trouve le nouveau référentiel maître.
Continuez à faire de bonnes demandes de tirage
Cela montre à la fois au propriétaire et à la communauté que vous êtes sérieux à ce sujet, et laissez-les juger vos contributions.
Si le propriétaire du dépôt d'origine n'est trouvé nulle part et absent pour une durée considérable, je publierais mon propre référentiel en tant que version différente du projet.
Avec cela, vous prenez la tête du développement de la bibliothèque et ne la laissez pas mourir dans un coin sans être mise à jour plus jamais. Si le propriétaire d'origine ferme le dépôt, le monde peut toujours utiliser la version fourchue.
Comme la plupart des projets libres et open source de petite à moyenne taille sont aujourd'hui hébergés sur github, gitlab ou similaire, il serait possible de automatiser une partie du processus, en utilisant leurs API Web.
En supposant que le dépôt d'origine est à https://github.com/someUserX/projectY/, le processus pourrait ressembler à ceci:
("manuel") Contactez l'auteur d'origine de différentes manières, au moins via son e-mail de commitateur git et un problème (si activé).
En cas d'autorisation reçue ou de non-réponse dans quelques semaines, on pourrait exécuter un script qui utiliserait l'API Web des hébergeurs pour effectuer des étapes comme celles-ci:
créer une nouvelle organisation (GitHub) appelée
projectY, et y fork le dépôt d'origine ->https://github.com/projectY/projectY/- ajouter l'auteur d'origine et tous les auteurs des demandes d'extraction (déjà fusionnés et toujours ouverts) en tant qu'administrateurs de l'organisation
- recréer toutes les demandes d'extraction (ouvertes) à partir du dépôt d'origine dans la nouvelle fourchette
- faire de même avec les problèmes (ouverts)
- informe tous les administrateurs du nouveau repo
- créer une dernière demande d'extraction à l'ancien référentiel, en ajoutant un avis "abandonné"/"archivé" et un lien vers le nouveau référentiel au-dessus du fichier README