（ほとんど）放棄されたGitHubプロジェクトにどのように貢献すべきですか？
私は最近、GitHubでオープンソースのコラボレーションを開始しようと試みており、どの方法が先に進むのが望ましいか知りたい状況に遭遇しました。
約1か月前に、GitHubで、しばらく使用していて、いくつかのバグを発見（および修正）したライブラリのプロジェクトを見つけました。
GitHubコラボレーションへの最初の進出として、最近のアクティビティが最も多いと思われるリポジトリを見つけ、1つのバグを修正し、単体テストを追加して、GitHubにプッシュし、プルリクエストを行いました。数時間以内に、私がフォークしたレポのメンテナーがPRを受け入れ、同様に待っていた他の人々からの他のいくつかのPRにマージしました。
これに拍車をかけ、発見した3つのバグをそれぞれ自分のリポジトリの別のブランチで修正し、それぞれに問題とプルリクエストを提出しました。
それはほんの1か月前のことで、プルリクエストはそのまま、そこにそのまま残っています。私がフォークしたレポのユーザーはあまり活発ではないようで、過去1年間でGitHubに合計7回の貢献しかありませんでした。また、最初のプルリクエスト以降、そのレポにはコミットがありません。
だから私の質問：
この状況でどのように進めますか？理想的には、オフにして、親リポジトリにマージされていない自分のリポジトリに一連の変更を加えることによって、ライブラリの断片化を作成しないようにしたいと思います。それでも、バグ修正と機能の追加を続けたいと思いますが、すべてをマスターブランチにマージし、そのブランチからすべての新しい修正をベースにすると、私がフォークしたリポジトリのメンテナーが戻ってきた場合、私は勝ちますすべての変更を機能/バグ修正ごとに個別のプルリクエストに分割することはできません（プルリクエストは通常、機能またはバグ修正ごとに1つのプルリクエストである必要があることを読みました）。
元のレポと同調している1つのブランチを保持し、そのブランチからすべての新しいブランチをベースにしてから、すべてのコミットをマスターブランチにマージして保持する必要がありますか？新しい変更をマスターブランチにマージする必要があるたびに、それは私にたくさんのブランチを残し、ますます厄介なタスクを残すようです。
このような状況にアプローチする典型的な方法は何ですか？新しいプルリクエストをレビューするために、プロジェクトが元の寄稿者と共に放棄されるだけであることはかなり一般的です。これは誰かが舵を取ってそれを実行する必要がある状況ですか？元の貢献者が戻ってきてプロジェクトに再び取り組みたい場合、断片化が生じるようです。
私はまだこの状況に遭遇していませんが、それを試してみます。
所有者に連絡してみてください
多分、彼らは本当に興味を失ったかもしれませんが、プロジェクトを他の誰か、特にすでに思いやりのあるコミットメントを示している誰かに移すことをいとわないでしょう。
しかし、おそらく彼らは他の何か（仕事、休暇、病気、その他のプロジェクト）に専念していて、PRを処理する時間はなかったが、後でそうする予定です。
あるいは、何らかの理由でプロジェクトの作業を完全に停止したのかもしれません。
質問しなければ、それを見つけることはできません。
コミュニティに連絡する
確かに、プロジェクトに貢献したか、少なくともプロジェクトを使用した他の人々がいます。誰がプロジェクトをフォークしたかを確認します（変更を加えていない場合でも、このプロジェクトが成功するのを見ることに興味があるかもしれません）。誰が問題を報告したか、またはそれらにコメントしたかを確認してください。たぶん、GitHub以外にもコミュニティがあります。たとえば、メーリングリスト、フォーラム、StackOverflowメンバーなどです。
私はあなたが最終的にプロジェクトを引き継ぐのです。あなたは彼らのサポートを求めているかもしれません。また、新しいマスターリポジトリの場所を知る必要があります。
良いプルリクエストを続けます
これは、オーナーとコミュニティの両方があなたがそれを真剣に考えていることを示しています。
元のリポジトリの所有者がどこにも見つからず、かなりの期間欠けている場合は、自分のリポジトリを別のバージョンのプロジェクトとして公開します。
これで、あなたはライブラリの開発の主導権を握り、二度と更新されずにコーナーで死ぬことを放置しないでください。元の所有者がリポジトリを閉じても、世界はフォークバージョンを引き続き使用できます。
今日のほとんどの小規模から中規模のフリーおよびオープンソースプロジェクトはgithub、gitlabなどでホストされているため、Web APIを使用してプロセスの一部を自動化することが可能です。
元のリポジトリがhttps://github.com/someUserX/projectY/にあるとすると、プロセスは次のようになります。
（「手動」）少なくともgitコミッターのメールと問題（有効になっている場合）を通じて、元の作者にさまざまな方法で連絡します。
許可を受け取った場合、または数週間以内に応答がない場合は、ホスティング業者のWeb APIを使用して次のような手順を実行するスクリプトを実行できます。
projectYという新しい（GitHub）組織を作成し、その中に元のリポジトリをフォークします->https://github.com/projectY/projectY/- 元の作成者とプルリクエストのすべての作成者（すでにマージされ、まだ開いている）を組織管理者として追加する
- 新しいフォークの元のリポジトリからすべての（オープン）プルリクエストを再作成します
- （未解決の）問題についても同じことを行う
- すべての管理者に新しいリポジトリを通知します
- 古いリポジトリへの最後のプルリクエストを作成し、「破棄」/「アーカイブ」通知を追加して、READMEの上に新しいリポジトリへのリンクを追加します