Как я должен внести свой вклад в (в основном) заброшенный проект GitHub?

Недавно я пытался начать сотрудничество с открытым исходным кодом в GitHub и столкнулся с ситуацией, для которой мне любопытно, какой предпочтительный способ продолжить.

Около месяца назад я нашел проект на GitHub для библиотеки, которую я уже использовал некоторое время и в которой я нашел (и исправил) несколько ошибок.

В качестве начального шага в совместной работе с GitHub я обнаружил репо, который, похоже, имел самый большой объем недавней активности, исправил одну ошибку, добавил модульные тесты, отправил в GitHub и сделал запрос на извлечение. В течение нескольких часов управляющий репо, который я раздобыл, принял PR и слил несколько других PR от других людей, которые тоже ждали.

Подстегнутый этим, я исправил еще три обнаруженные ошибки, каждая в отдельной ветке моего репо, и подал запрос на выдачу и получение каждой из них в отдельности.

Это было чуть более месяца назад, и запросы на извлечение с тех пор оставались нетронутыми. Пользователь, чье репо я развел, кажется, не очень активен: он сделал всего 7 вкладов на GitHub в прошлом году, и у этого репо не было никаких коммитов с того первого запроса на получение, который я сделал.

Итак, мой вопрос:

Как действовать в этой ситуации? В идеале я бы хотел избежать фрагментации библиотеки, отключив и сделав целую кучу изменений в моем собственном репо, которые не объединены с родительским репо. Тем не менее, я хотел бы продолжить исправление ошибок и добавление функций, но если я объединю все в свою основную ветку и внесу все новые исправления в эту ветку, то, если сопровождающий репо, который я разветвил, вернется, я выиграю невозможно разделить все изменения на отдельные запросы на извлечение для каждой функции / исправления ошибки (я читал, что запросы на извлечение обычно должны составлять один запрос на извлечение для каждой функции или исправления ошибки).

Должен ли я оставить одну ветку, которая идет в ногу с исходным репо, основать все мои новые ветви на этой, а затем оставить все коммиты объединенными в моей основной ветке? Кажется, что это оставило бы у меня целую тонну ветвей и все более обременительную задачу каждый раз, когда мне нужно объединить новые изменения в мою основную ветку.

Каков типичный подход к такой ситуации? Кажется довольно распространенным явлением, что проект просто заброшен, а первоначальные участники отсутствуют, чтобы рассмотреть новые запросы на извлечение. Это ситуация, когда кто-то должен просто взять руль и бежать с ним? Кажется, что это создаст фрагментацию, если первоначальные участники когда-нибудь вернутся и захотят снова поработать над проектом.

У меня еще не было такой ситуации, но я бы попробовал:

Попробуйте связаться с владельцем

Возможно, они действительно потеряли интерес, но готовы передать проект кому-то другому, в частности, тому, кто уже проявил серьезную приверженность.

Но, возможно, они просто заняты чем-то другим (работой, отпуском, болезнью, другими проектами) и не успели заняться вашим пиаром, а планируют сделать это позже.

Или, возможно, по какой-то причине они действительно прекратили работу над проектом навсегда.

Не спрашивая, вы не узнаете это.

Связаться с сообществом

Конечно, есть другие люди, которые внесли свой вклад или хотя бы использовали проект. Проверьте, кто подписал проект (даже если они не внесли никаких изменений, они все равно могут быть заинтересованы в том, чтобы этот проект процветал); проверьте, кто сообщал о проблемах или комментировал их. Может быть, есть и сообщество за пределами GitHub, например, список рассылки, форум или участники StackOverflow.

Я, в конце концов, вы действительно принимаете проект, возможно, вы захотите их поддержки. И им нужно знать, где находится новый главный репозиторий.

Продолжайте делать хорошие запросы тянуть

Это показывает владельцу и сообществу, что вы серьезно относитесь к этому, и давайте им оценивать ваш вклад.

Если владелец исходного репо нигде не найден и отсутствует в течение значительного периода времени, я бы опубликовал свой собственный репозиторий в качестве другой версии проекта.

При этом вы берете на себя руководство разработкой библиотеки и не оставляете ее умирать в углу, не обновляя ее никогда. Если первоначальный владелец закрывает репо, мир все еще может использовать раздвоенную версию.

Поскольку большинство небольших и средних бесплатных и открытых проектов в настоящее время размещаются на github, gitlab или аналогичных, можно было бы автоматизировать некоторые процессы с помощью их веб-API.

Предполагая, что исходное репо находится в https://github.com/someUserX/projectY/, процесс может выглядеть так:

1. («руководство») Связаться с оригинальным автором можно по-разному, по крайней мере, через его адрес электронной почты git committer и проблему (если она включена).

   В случае получения разрешения или отсутствия ответа в течение нескольких недель, можно запустить скрипт, который будет использовать веб-API хостеров для выполнения таких шагов:

2. создайте новую (GitHub) организацию с именем projectY, и в ней разветвите исходное хранилище ->https://github.com/projectY/projectY/

3. добавить оригинального автора и всех авторов запросов на включение (уже объединенных и открытых) в качестве администраторов организации
4. пересоздать все (открытые) pull-запросы из исходного репо в новом форке
5. сделать то же самое с (открытыми) проблемами
6. уведомляет всех администраторов о новом репо
7. Создайте последний запрос на извлечение для старого репо, добавив извещение «заброшенный» / «заархивированный» и ссылку на новый репо поверх README.