Comment devrais-je contribuer à un projet (principalement) abandonné de GitHub?


43

J'ai récemment essayé de m'engager dans la collaboration open source dans GitHub et j'ai rencontré une situation dans laquelle je suis curieux de savoir quelle est la meilleure façon de procéder.

Il y a environ un mois, j'ai trouvé un projet sur GitHub pour une bibliothèque que j'utilisais déjà depuis longtemps et dans laquelle j'avais trouvé (et corrigé) quelques bugs.

Comme première incursion dans la collaboration avec GitHub, j’ai trouvé le dépôt qui semblait contenir le plus grand volume d’activités récentes, corrigé un bogue, ajouté des tests unitaires, transmis à GitHub et envoyé une demande de tirage. En quelques heures, le responsable de la mise en pension que j’ai fourni avait accepté le PR et fusionné avec quelques autres PR qui attendaient également.

Poussé par ceci, j'ai corrigé trois autres bogues que j'avais trouvés, chacun dans une branche distincte de mon propre dépôt, et ai déposé un problème et extrait la demande pour chacun d'eux séparément.

C'était il y a un peu plus d'un mois et les demandes de tirage sont restées intactes depuis. L'utilisateur dont j'avais proposé le repo ne semble pas très actif, il n'a effectué que 7 contributions sur GitHub au cours de la dernière année et ce repo n'a pas eu d'engagement depuis la première demande d'extraction 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 procédant de nombreuses modifications dans mon propre référentiel qui ne sont pas fusionnées 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 base tous les nouveaux correctifs à partir de cette branche, alors si le mainteneur du repo que j'ai créé revient toujours, j'ai gagné Vous ne pouvez pas scinder toutes les modifications en demandes d'extraction distinctes pour chaque fonctionnalité / correction de bogue (j'ai lu que les demandes d'extraction devraient généralement correspondre à une demande d'extraction par fonctionnalité ou correction de bogue).

Devrais-je conserver une branche qui est en phase avec le référentiel d'origine, baser toutes mes nouvelles branches sur celle-ci, puis conserver tous les commits fusionnés 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 devrais fusionner de nouvelles modifications dans ma branche principale.

Quelle est la manière typique d’aborder une telle situation? Il semble assez courant qu'un projet soit abandonné sans l'aide des contributeurs d'origine pour examiner les nouvelles demandes d'attraction. Est-ce une situation où quelqu'un devrait simplement prendre la barre et courir avec elle? Il semble que cela créerait une fragmentation si les contributeurs d'origine revenaient jamais et voulaient travailler à nouveau sur le projet.


4
Lorsque vous trouverez cette question intéressante, vous serez peut-être également intéressé par la proposition d’un nouveau site open source stackexchange .
Philipp

Voulez-vous partager ce qui est sorti de la conversation par courrier électronique rien que pour nous, curieux? :)
clin d'oeil

@winkbrace Jusqu'à présent, rien. Je n'ai pas reçu de réponse, mais je ne l'ai envoyé que deux jours auparavant. Je vous ferai savoir tous si quelque chose se développe.
JLRishe

Réponses:


39

Je n'ai pas encore eu cette situation, mais c'est ce que j'essaierais:

Essayez de contacter le propriétaire

Ils ont peut-être vraiment perdu tout intérêt, mais sont disposés à 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 ne s’occupent-ils que de quelque chose d’autre (travail, vacances, maladie, autres projets) et n’ont pas le temps de gérer vos relations publiques mais prévoient de le faire plus tard.

Ou peut-être ont-ils vraiment cessé de travailler sur le projet de manière permanente pour une raison quelconque.

Sans demander, vous ne le saurez pas.

Entrez en contact avec la communauté

Il y a sûrement d'autres personnes qui ont contribué ou au moins utilisé le projet. Vérifiez qui a lancé 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é. Peut-être existe-t-il également une communauté en dehors de GitHub, par exemple une liste de diffusion, un forum ou des membres StackOverflow.

Je suis que vous finissez vraiment par prendre en charge le projet, vous pourriez avoir besoin de leur soutien. Et ils doivent savoir où se trouve le nouveau référentiel maître.

Continuer à faire de bonnes demandes de tirage

Cela montre à la fois au propriétaire et à la communauté que vous êtes sérieux, et leur permet de juger de vos contributions.


1
Merci. Après un peu plus de recherches, il semble que ce conseil soit similaire aux instructions disponibles pour ce type de situation avec les packages npm . Je viens juste d'envoyer un e-mail au propriétaire et je verrai ce qu'il / elle répond.
JLRishe

Il est très difficile de trouver une personne habilitée à approuver des relations publiques pour un dépôt particulier lorsque le "propriétaire" du dépôt est en réalité une organisation comptant des dizaines d'utilisateurs.
cowlinator

15

Si le propriétaire du référentiel d'origine n'est trouvé nulle part et absent pendant un temps considérable, je publierais mon propre référentiel en tant que version différente du projet.

Avec cela, vous prenez en charge le développement de la bibliothèque, et ne la laissez pas mourir dans un coin sans être mise à jour. Si le propriétaire d'origine ferme le référentiel, le monde peut toujours utiliser la version forkée.


1
Oui, simplement dans forkle projet et dans le README.md, laissez une référence et "merci" au propriétaire original.
Jared Burrows

Merci pour votre réponse (+1). Vous faites certainement de bons points. J'aurai peut-être recours à cela, mais pour l'instant, je suivrai le conseil de oefe et verrai si je pouvais contacter le propriétaire du dépôt par courrier électronique.
JLRishe

Bien sûr, ne laissez pas le dépôt tomber dans l'oubli. Beaucoup de bons codes doivent être cachés quelque part au fond de Github car les propriétaires originaux ne sont plus.
Cllamach

Je suis dans une situation similaire et j'ai peut-être besoin de prendre cette option: le propriétaire initial d'un projet n'a pas répondu aux tentatives de contact répétées. Est-il kasher de garder le nom du projet et de continuer à incrémenter le numéro de version à partir de la dernière version officielle? Je crains que si je change le nom, il sera plus difficile pour les utilisateurs existants du projet de trouver.
pericynthion

1
Je suis peut-être aussi dans cette situation. Mais le projet original est déjà enregistré auprès de Bower. Conserver le nom impliquerait de demander à l'auteur original de le désenregistrer, ou de contacter les responsables de la maintenance de Bower pour leur demander d'intervenir. Je ne me soucie pas beaucoup de faire ce dernier, cependant. Renommer pourrait être la meilleure option.
Lawrence I. Siden

0

Comme la plupart des projets Open Source et Open Source de petite à moyenne taille sont actuellement hébergés sur github, gitlab ou similaire, il serait possible d' automatiser une partie du processus à l' aide de leurs API Web.

En supposant que le dépôt initial soit à https://github.com/someUserX/projectY/, le processus pourrait ressembler à ceci:

  1. ("manual") Contactez l'auteur original de différentes manières, au moins par le biais de son email git committer et d'un problème (si activé).

    En cas d'autorisation ou d'absence de réponse dans quelques semaines, il est possible d'exécuter un script utilisant l'API Web de l'hôte pour effectuer les opérations suivantes:

  2. créer une nouvelle organisation (GitHub) appelée projectY, et y fourcher le dépôt initial ->https://github.com/projectY/projectY/

  3. ajouter l'auteur original et tous les auteurs des demandes d'extraction (déjà fusionnées et toujours ouvertes) en tant qu'administrateurs d'organisation
  4. recréer toutes les demandes d'extraction (ouvertes) à partir du référentiel d'origine dans le nouveau fork
  5. faire la même chose avec les problèmes (ouverts)
  6. notifie tous les administrateurs de la nouvelle prise en pension
  7. créer une dernière requête d'extraction vers 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

Le principal problème que je vois avec cette approche est que certains "mauvais" contributeurs pourraient obtenir un accès administrateur, mais comme l' explique Pieter Hintjens, évangéliste du logiciel libre (par exemple dans cet exposé) , les mauvaises commissions peuvent simplement être annulées et ne constituent aucun fil conducteur. un projet qui est en vie et qui pourrait aider le mauvais committer à devenir un bon projet avec le temps.
Hoijui
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.