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

43

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

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

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

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

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

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

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

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

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

JLRishe
источник
4
Когда вы найдете этот вопрос интересным, вас также может заинтересовать предложение о создании нового сайта с открытым исходным кодом stackexchange .
Филипп
Хотите поделиться тем, что получилось из разговора по электронной почте только для нас, любопытных зрителей? :)
winkbrace
@winkbrace Пока ничего. Я не получил ответ, но я отправил электронное письмо только два дня назад. Я дам вам всем знать, если что-то развивается.
JLRishe

Ответы:

39

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

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

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

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

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

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

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

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

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

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

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

oefe
источник
1
Спасибо. После небольшого поиска, похоже, что этот совет похож на рекомендации, доступные для такой ситуации с пакетами npm . Я только что отправил электронное письмо владельцу и посмотрю, что он / она отвечает.
JLRishe
Очень сложно найти кого-то, кто мог бы утверждать PR для определенного репо, когда «владельцем» репо фактически является организация с десятками пользователей.
Cowlinator
15

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

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

cllamach
источник
1
Да, просто forkпроект и в README.md, оставить ссылку и "спасибо" первоначальному владельцу.
Джаред Берроуз
Спасибо за ваш ответ (+1). Вы определенно сделаете несколько хороших замечаний. В конечном счете, я могу прибегнуть к этому, но сейчас я последую совету oefe и посмотрю, смогу ли я связаться с владельцем репо по электронной почте.
JLRishe
Конечно, просто не позволяйте хранилищу впадать в забвение. Много хорошего кода должно быть спрятано где-то глубоко в Github, потому что первоначальных владельцев больше нет.
Кламач
Я нахожусь в подобной ситуации и, возможно, придется воспользоваться этой опцией - первоначальный владелец проекта не ответил на повторные попытки контакта. Кошерно ли сохранять название проекта и продолжать увеличивать номер версии с последней официальной версии? Я беспокоюсь о том, что если я поменяю имя, существующим пользователям проекта будет сложнее найти его.
перицинтион
1
Я тоже могу быть в такой ситуации. Но оригинальный проект уже зарегистрирован в Bower. Сохранение имени означало бы необходимость заставить первоначального автора отменить его для вас или связаться с сопровождающими Bower и попросить их вмешаться. Впрочем, я не очень хочу заниматься последним. Переименование может быть лучшим вариантом.
Лоуренс И. Сиден
0

Поскольку большинство небольших и средних бесплатных и открытых проектов в настоящее время размещаются на 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.
hoijui
источник
Основная проблема, с которой я сталкиваюсь при таком подходе, заключается в том, что некоторые «плохие» участники могут получить административный доступ, но, как объясняет евангелист Свободного программного обеспечения Питер Хиндженс (например, в этом выступлении) , плохие коммиты могут быть просто возвращены и не создают никакого потока для проект, который жив и может помочь плохому коммиттеру со временем стать хорошим.
hoijui