（ほとんど）放棄されたGitHubプロジェクトに貢献するにはどうすればよいですか？

私は最近、GitHubでオープンソースのコラボレーションに取り組もうとしていますが、どのような方法で進めるのが好奇心situation盛かという状況に陥りました。

約1か月前、GitHubで、しばらく使用していて、いくつかのバグを見つけた（修正した）ライブラリのプロジェクトを見つけました。

GitHubコラボレーションへの最初の進出として、最近のアクティビティが最も多いと思われるレポを見つけ、1つのバグを修正し、ユニットテストを追加し、GitHubにプッシュし、プルリクエストを行いました。数時間以内に、私がフォークしたレポジトリのメンテナーは、PRを受け入れ、同様に待っていた他の人々からのいくつかの他のPRにマージしました。

これに拍車をかけ、発見したバグをさらに3つ修正しました。それぞれが自分のリポジトリの別々のブランチにあり、それぞれに問題とプルリクエストを提出しました。

それはほんの1か月前のことで、それ以降プル要求はそのままで、そのままになっています。リポジトリをフォークしたユーザーはあまりアクティブではないようです。過去1年間にGitHubで合計7回の投稿を行っただけで、最初のプルリクエスト以降、そのリポジトリにはコミットがありません。

だから私の質問：

この状況でどのように進みますか？理想的には、親リポジトリにマージされていない自分のリポジトリに変更を加えて、ライブラリの断片化を回避したいと思います。それにもかかわらず、バグ修正と機能の追加を続けたいと思いますが、すべてをマスターブランチにマージし、そのブランチからすべての新しい修正をベースにした場合、フォークしたレポのメンテナーが戻ってきたら、勝ちました「すべての変更を機能/バグ修正ごとに個別のプル要求に分割することはできません（プル要求は通常、機能またはバグ修正ごとに1つのプル要求である必要があると読みました）。

元のレポと一致する1つのブランチを保持し、そのブランチの新しいブランチをすべてベースにしてから、すべてのコミットをマスターブランチにマージしたままにする必要がありますか？そのため、新しい変更をマスターブランチにマージする必要があるたびに、膨大な数のブランチとますます面倒なタスクが残ります。

このような状況にアプローチする典型的な方法は何ですか？プロジェクトは、新しいプルリクエストをレビューするためではなく、元の貢献者によって放棄されることになるのはかなり一般的なようです。これは、誰かが舵を取るだけでそれで走るべき状況ですか？元の貢献者が戻ってきて、再びプロジェクトに取り組みたいと思うと、断片化を引き起こすようです。

私はまだこのような状況にはありませんでしたが、私はそれを試してみました：

所有者に連絡してみてください

たぶん彼らは本当に興味を失ったかもしれませんが、プロジェクトを他の誰か、特にすでに思いやりのあるコミットメントを示した誰かに移したいと思っています。

しかし、おそらく彼らは何か他のもの（仕事、休暇、病気、他のプロジェクト）に専念していて、あなたのPRを処理する時間がありませんでしたが、後でそれを行う予定です。

または、何らかの理由でプロジェクトの作業を永久に停止している可能性があります。

尋ねることなく、あなたはそれを見つけられません。

コミュニティと連絡を取る

確かにプロジェクトに貢献した、または少なくともプロジェクトを使用した他の人々がいます。誰がプロジェクトを分岐したかを確認します（変更を加えていない場合でも、このプロジェクトが成功するのを見ることに興味があるかもしれません）。誰が問題を報告したか、それらにコメントしたかを確認してください。メーリングリスト、フォーラム、StackOverflowメンバーなど、GitHubの外部にもコミュニティがあるかもしれません。

私は最終的にプロジェクトを本当に引き継ぎます、あなたは彼らのサポートが欲しいかもしれません。そして、新しいマスターリポジトリがどこにあるかを知る必要があります。

引き続き適切なプルリクエストを行う

これは、所有者とコミュニティの両方にあなたがそれについて真剣であることを示し、彼らにあなたの貢献を判断させましょう。

元のリポジトリの所有者がどこにも見つからず、かなりの期間欠席している場合は、自分のリポジトリをプロジェクトの別のバージョンとして公開します。

これにより、ライブラリの開発のリーダーを引き継ぎ、二度と更新されることなくコーナーで死んでしまうことはありません。元の所有者がレポジトリを閉じた場合でも、世界はフォークされたバージョンを使用できます。

現在、ほとんどの小規模から中規模のフリーおよびオープンソースプロジェクトはgithub、gitlabなどでホストされているため、Web APIを使用してプロセスの一部を自動化することができます。

元のリポジトリがにあると仮定すると、https://github.com/someUserX/projectY/プロセスは次のようになります。

1. （「マニュアル」）少なくとも彼のgitコミッターの電子メールと問題（有効な場合）を通じて、さまざまな方法で元の作者に連絡してください。

   数週間以内に許可を受け取った場合、または応答がなかった場合、ホストWeb APIを使用して次のような手順を実行するスクリプトを実行できます。

2. という新しい（GitHub）組織を作成し、projectYその中に元のリポジトリをフォークします->https://github.com/projectY/projectY/

3. 元の作成者とプルリクエストのすべての作成者（既にマージされ、まだ開いている）を組織管理者として追加する
4. 新しいフォークの元のリポジトリからすべての（オープン）プルリクエストを再作成します
5. （未解決の）問題についても同じことをする
6. すべての管理者に新しいレポを通知します
7. 古いリポジトリに最後のプルリクエストを作成し、「放棄された」/「アーカイブされた」通知を追加し、READMEの上部にある新しいリポジトリにリンクします。