>И вот в июле кто-нибудь бы подключил себе это, а в декабре - сюрприз! - не ясно, что изменилось и изменилось ли вообще

В инструкции к Issuer явно написано, что рекомендуется делать свой форк, и его уже прописывать:

>  # it is recommended to use an own fork

А если есть свой форк, то, что изменилось, определяется следующим образом: клонируется свой форк, клонируется апстрим, средствами гита делается дифф.

Также наличие форка защищает от ситуации как с одним из пакетов npm, когда пакет автор со злости удалил, и у многих сломалось.

>Простой жизненный пример: множество пакетов в Fedora сопровождаются ровно одним человеком.

Сопровождается 1м человеком ≠ есть код только от одного человека.

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

Я сам пользуюсь blame для отслеживания изменений в llvm. Но мои проекты - не llvm. Это обычно маленькие либы или инструменты, в которых может быстро и полностью разобраться 1 человек, прочитав весь их код. На данном этапе (1 разраб, 0 контрибьютеров, ~1 пользователей) не имеет смысла захламлять репозиторий, хотя бы потому, что после роста проекта этот хлам уже будет проблематично вычистить, не снискав тонны ненависти (но иногда лучше снискать тонны ненависти, чем оставить хлам, из-за которого проблемы постоянны (git - это не hg, чем больше коммитов - тем медленнее клонирование, а долгое клонирование очень неприятно, гораздо более неприятно, чем отсутствие истории), PRы на чужую историю легко перебазируются путём экспортирования в патчи, а потом git am).

>А это лишь характеризует тебя как не очень дисциплинированного разработчика. Взялся реализовывать фичу -- реализуй ее до конца и закоммить. Если фича крупная и занимает несколько дней -- коммить каждый чих в отдельной ветке, но в master все равно сливай в виде ровно одного коммита, затем переходи к следующей задумке в порядке очередности.

С момента разработки (проект разрабатывался специально для UniGrammar одновременно с ней, последнее изменение кода самой либы - июль) в него добавились только очень незначительные изменения: документация, тесты (да, я знаю, что я нарушил TDD, на начальном этапе у меня вместо тестов была UniGrammar, если она работала - значит ОК, как можно сообразить, эта либа была создана потому, что в UniGrammar вручную закодить и поддерживать весь зоопарк (а без зоопарка нельзя, UniGrammar создавалась изначально с целью объективного сравнения производительности различных генераторов парсеров с целью выбора и использования наилучшего (которым обычно является parsimonious (CoCo/py я не тестировал, ибо код для построения AST для него не написан), обгоняя даже ANTLR) ) было невыносимо), обновления шаблона (добавил CI через GitHub Actions). Захламлять этим историю не очень целесообразно на мой взгляд, особенно при 0 пользователях (с мая висит - и всем пофиг, потому что сложная штука для понимания, нужна только в редких случаях, вроде UG).