Wie soll ich zu einem (meistens) aufgegebenen GitHub-Projekt beitragen?

Ich habe kürzlich versucht, in GitHub Open-Source-Zusammenarbeit zu starten, und bin auf eine Situation gestoßen, für die ich gespannt bin, wie ich am besten vorgehen soll.

Vor ungefähr einem Monat fand ich auf GitHub ein Projekt für eine Bibliothek, die ich bereits eine Weile benutzt hatte und in der ich einige Fehler gefunden (und behoben) hatte.

Als ersten Versuch für die Zusammenarbeit mit GitHub fand ich das Repo, das anscheinend das höchste Volumen der letzten Aktivitäten aufweist, behebte einen Fehler, fügte Unit-Tests hinzu, schob es zu GitHub hoch und stellte eine Pull-Anfrage. Innerhalb weniger Stunden hatte der Betreuer des von mir gespaltenen Repos die PR akzeptiert und einige andere PRs von anderen Personen, die ebenfalls gewartet hatten, zusammengeführt.

Aus diesem Grund habe ich drei weitere Fehler behoben, die ich gefunden hatte, und zwar jeweils in einer eigenen Filiale meines eigenen Repos. Außerdem habe ich für jeden Fehler eine Ausgabe und eine Pull-Anfrage eingereicht.

Das war vor etwas mehr als einem Monat, und die Pull-Requests sind seitdem unangetastet geblieben. Der Benutzer, dessen Repo ich gegabelt hatte, scheint nicht sehr aktiv zu sein, da er im letzten Jahr nur 7 Beiträge auf GitHub geleistet hat, und dieser Repo hat seit meiner ersten Pull-Anfrage keine Commits mehr erhalten.

Also meine Frage:

Wie geht man in dieser Situation vor? Idealerweise möchte ich vermeiden, dass die Bibliothek fragmentiert wird, indem ich eine ganze Reihe von Änderungen an meinem eigenen Repo vornehme, die nicht mit dem übergeordneten Repo zusammengeführt werden. Trotzdem würde ich gerne weiterhin Fehlerbehebungen vornehmen und Funktionen hinzufügen. Wenn ich jedoch alles in meinem Hauptzweig zusammenführe und alle neuen Korrekturen aus diesem Zweig herausarbeite, dann habe ich gewonnen, wenn der Betreuer des Repos, das ich je gabelte, zurückkommt kann nicht alle Änderungen in separate Pull-Anforderungen für jede Funktion / Fehlerbehebung aufteilen (ich habe gelesen, dass Pull-Anforderungen im Allgemeinen eine Pull-Anforderung pro Funktion oder Fehlerbehebung sein sollten).

Sollte ich einen Zweig behalten, der mit dem ursprünglichen Repository übereinstimmt, alle meine neuen Zweige von diesem Zweig trennen und dann alle Commits in meinem Hauptzweig zusammenfassen? Es sieht so aus, als würde mir jedes Mal, wenn ich neue Änderungen in meine Master-Filiale einbinden muss, eine ganze Tonne Filialen und eine zunehmend beschwerliche Aufgabe verbleiben.

Wie würde man sich einer solchen Situation normalerweise nähern? Es scheint ziemlich üblich zu sein, dass ein Projekt nur dann abgebrochen wird, wenn die ursprünglichen Mitwirkenden nicht da sind, um neue Pull-Anforderungen zu prüfen. Ist dies eine Situation, in der jemand einfach das Ruder übernehmen und damit rennen sollte? Es scheint, als würde es zu einer Fragmentierung kommen, wenn die ursprünglichen Mitwirkenden jemals zurückkehren und wieder an dem Projekt arbeiten möchten.

Ich hatte diese Situation noch nicht, aber das würde ich versuchen:

Versuchen Sie, den Eigentümer zu kontaktieren

Vielleicht haben sie wirklich das Interesse verloren, sind aber bereit, das Projekt auf jemanden zu übertragen, insbesondere auf jemanden, der bereits rücksichtsvolles Engagement gezeigt hat.

Aber vielleicht beschäftigen sie sich nur mit etwas anderem (Arbeit, Urlaub, Krankheit, andere Projekte) und hatten keine Zeit, sich um Ihre PR zu kümmern, planen dies aber später.

Oder sie haben die Arbeit an dem Projekt aus irgendeinem Grund endgültig eingestellt.

Ohne zu fragen, werden Sie es nicht herausfinden.

Nehmen Sie Kontakt mit der Community auf

Sicherlich gibt es andere Leute, die zu dem Projekt beigetragen oder es zumindest genutzt haben. Überprüfen Sie, wer das Projekt gespalten hat (auch wenn sie keine Änderungen vorgenommen haben, könnten sie dennoch daran interessiert sein, dass dieses Projekt floriert). Überprüfen Sie, wer Probleme gemeldet oder kommentiert hat. Möglicherweise gibt es auch eine Community außerhalb von GitHub, z. B. eine Mailingliste, ein Forum oder StackOverflow-Mitglieder.

Ich bin dir irgendwann wirklich überlassen, du möchtest vielleicht deren Unterstützung. Und sie müssen wissen, wo sich das neue Master-Repository befindet.

Machen Sie weiterhin gute Pull-Anfragen

Dies zeigt sowohl dem Eigentümer als auch der Community, dass Sie es ernst meinen, und lässt Sie Ihre Beiträge beurteilen.

Wenn der Besitzer des ursprünglichen Repos nirgends zu finden ist und für einen beträchtlichen Teil abwesend ist, würde ich mein eigenes Repository als andere Version des Projekts veröffentlichen.

Damit übernehmen Sie die Leitung der Entwicklung der Bibliothek und überlassen es nicht, dass sie in einer Ecke stirbt, ohne jemals wieder aktualisiert zu werden. Wenn der ursprüngliche Besitzer jemals das Repo schließt, kann die Welt immer noch die gegabelte Version verwenden.

Da die meisten kleinen bis mittelgroßen Free- und Open Source-Projekte heutzutage auf github, gitlab oder ähnlichem gehostet werden, wäre es möglich, einen Teil des Prozesses mithilfe ihrer Web-APIs zu automatisieren .

Unter der Annahme, dass sich das ursprüngliche Repo auf befindet https://github.com/someUserX/projectY/, könnte der Prozess folgendermaßen aussehen:

1. ("manual") Wenden Sie sich auf verschiedene Weise an den ursprünglichen Autor, zumindest über seine Git Committer-E-Mail und ein Problem (falls aktiviert).

   Falls innerhalb weniger Wochen eine Erlaubnis oder keine Antwort eingeht, kann ein Skript ausgeführt werden, das die Web-API des Hosters verwendet, um folgende Schritte auszuführen:

2. erstelle eine neue (GitHub) -Organisation mit dem Namen projectYund gabele darin das ursprüngliche Repo ->https://github.com/projectY/projectY/

3. Fügen Sie den ursprünglichen Autor und alle Autoren von Pull-Anforderungen (die bereits zusammengeführt und noch offen sind) als Organisationsadministratoren hinzu
4. Erstellen Sie alle (offenen) Pull-Requests aus dem ursprünglichen Repo in der neuen Abzweigung neu
5. Mach dasselbe mit den (offenen) Fragen
6. benachrichtigt alle Admins über das neue Repo
7. Erstellen Sie eine letzte Pull-Anforderung für das alte Repo. Fügen Sie dazu eine Meldung "Abgebrochen" / "Archiviert" hinzu und verknüpfen Sie das neue Repo über der README-Datei