1) Написать автору проекта на почту, готов ли он добавить вас к разработчикам (collaborators) проекта чтобы вы продолжили его дело, иногда они очень даже не против
2) Если нет ответа/против - делаете форк, мержите сами пул реквесты в свой форк (и уведомляете об этом авторов пул реквестов, они могут быть заинтересованы)
Во втором случае может появиться желание отделиться от основного проекта и стать самостоятельным проектом - об этом можно написать в поддержку GitHub, они сделают что ваш проект не будет отображаться как форк другого проекта, а как самостоятельный проект.
Если есть какие-то нерешённые issue в исходном проекте, которые вы исправляете у себя - пишите в соответствующих issue, народ будет рад перейти на форк где этих проблем нет, таким образом у вас сразу будет некоторое количество весьма лояльно настроенных пользователей.
GNU coreutils git.savannah.gnu.org/cgit/coreutils.git/tree
Это те самые ls, chown, uniq, с которыми люди сталкиваются каждый день работая в консоли. Множество маленьких "проектиков", обильно прокомментированных и уже хорошо оттестированных "на кроликах". Каждая конкретная утилитка выполняет маленькую понятную задачку, но в реальном коде вскрываются множество тонкостей, о которых в базовых учебниках не пишут, а знать надо.
грубо говоря это сторонние зависимости, они должны быть исключены из гита.
что бы можно было потом быстро развернуть именно те пакеты которые нужны, можно воспользоваться командой pip freeze, который сгенерит файлик с зависимостями, который уже нужно хранить в git-е.
Приоритет операций нужно учитывать, видимо: 1 in (1, 2, 3) == True
даст False, поскольку сначала выполнится (1, 2, 3) == True, что вернёт False, и затем получится проверка 1 in False, что есть False.
А вот так правильно: (1 in (1, 2, 3)) == True
даст True.
А вот так ещё правильнее:
