我最近一直在尝试在GitHub中进行开源协作，并且遇到了一种情况，我对此感到好奇，这是首选的处理方式。
大约一个月前，我在GitHub上找到了一个项目库，该项目已经使用了一段时间，并且在其中找到（并修复了）一些错误。
作为与GitHub合作的最初尝试，我发现该回购似乎是最近活动量最大，修复了一个错误，添加了单元测试，推送到GitHub并发出请求的仓库。在几个小时内，我分叉的仓库的维护者接受了PR，并合并了其他也在等待中的PR。
受此刺激，我修复了另外三个bug，分别在我自己的repo的单独分支中，并分别提交了问题和请求请求。
那是一个多月前的事，从那以后，请求就一直没有动过。我分叉的存储库的用户似乎并不活跃，在过去的一年中，他在GitHub上总共贡献了7次，并且自从我提出第一个请求请求以来，该存储库就没有任何提交。
所以我的问题是：
在这种情况下如何进行？理想情况下，我想避免关闭库并在我自己的存储库中进行一堆未合并到父存储库中的更改来避免造成数据库碎片。尽管如此，我仍想继续进行错误修复并添加功能，但是如果我将所有内容合并到我的master分支中，并基于该分支建立所有新的修复程序，那么如果我分叉的仓库的维护者回来了，我就赢了。无法针对每个功能/错误修复将所有更改拆分为单独的拉取请求（我已经阅读到，拉取请求通常应该是每个功能或错误修复的一个拉取请求）。
我应该保留一个与原始存储库保持一致的分支，将所有新分支作为该分支的基础，然后将所有提交合并到我的主分支中吗？每次我需要将新更改合并到我的主分支中时，这似乎将给我留下大量的分支和越来越繁重的任务。
应对这种情况的典型方式是什么？在原始贡献者不在的情况下，一个项目将被放弃而无法审查新的请求请求，这似乎很普遍。是在这种情况下，有人应该承担起并掌舵吗？如果原始贡献者再次回来并希望再次从事该项目，则似乎会造成碎片。