Тема: maintainership
-
After a vulnerability report arrives: acknowledge, assess, fix in private, disclose
Once a report reaches the project's security contact, the work is a sequence with dates: acknowledge quickly, classify (working as intended, bug, feature request, vulnerability), agree an embargo with the reporter, develop the fix privately, obtain a CVE identifier, then release and publish an advisory that names affected and fixed versions and credits the reporter. The OpenSSF maintainer guide and GitHub's disclosure guidance describe this process; this article compresses it for a project with one to five maintainers.
-
Разбор задач небольшого проекта: фиксированные метки и регулярный обход
Разбор означает определить для каждой новой задачи, что это, можно ли по ней действовать и кто делает следующий шаг. Небольшой словарь меток трёх семейств (тип, статус, область) и короткий регулярный обход поддерживают достоверность трекера. Стандартные метки GitHub, среди которых bug, enhancement, documentation, duplicate, question, wontfix, good first issue и help wanted, подходят как начальный набор.
-
Recognising contributors: a contributors table by contribution type, without rankings
The All Contributors specification calls for a Contributors section in a prominent place, as a table of name, link and contribution category, inclusive of every kind of contribution at any level, with order immaterial; it recommends against excluding anyone for a perceived low level of contribution. Git's Co-authored-by trailer credits co-authors of a single commit. Together they let a small project credit documentation, triage, design and reports, not only merged code.
-
Ритм выпусков небольшого проекта: по расписанию или по готовности
Номер версии говорит, что обещает выпуск; политика периодичности — когда он выходит. Rust выпускает стабильную версию каждые шесть недель через цепочку nightly, beta, stable; Python перешёл на ежегодные функциональные выпуски по PEP 602; Django выпускает функциональные версии по расписанию, а исправления — по необходимости. Небольшой проект может перенять эту схему: функциональные выпуски по календарю или по накоплении заметных изменений, исправления — после принятия каждого исправления.
-
Файл CONTRIBUTING, отвечающий на первые пять вопросов новичка
Прежде чем писать код, потенциальный участник спрашивает: нужно ли это изменение, как его предложить, что обязан содержать запрос на включение изменений, когда ждать ответа и как принятое изменение попадёт к пользователям. Файл CONTRIBUTING, последовательно отвечающий на эти пять вопросов и дающий ссылки по остальным, призван предотвратить запросы, которые отклонят из-за выхода за рамки проекта или отсутствия тестов.
-
Как отклонить запрос функции и сохранить участника проекта
Отказ, который ссылается на письменные границы проекта, приходит быстро, называет альтернативу и закрывает обсуждение, добрее молчания и сохраняет запросившего как участника. Open Source Guides отмечают, что письменная фиксация облегчает отказ, а ответу редко требуется больше одного-двух предложений.
-
Управление небольшим проектом: записать права на решения до того, как они понадобятся
Файл управления определяет, кто может сливать изменения, кто разрешает спор о границах проекта, как добавляют и исключают сопровождающих и как меняют сами правила. PEP 13 Python показывает модель совета, который должен редко пользоваться полномочиями и обсуждать вопросы публично; глоссарий Apache определяет ленивый консенсус: предложение принимается, если за установленный срок никто не возразил. Проекту с одним–тремя сопровождающими достаточно одной страницы.
-
How do maintainers of small projects actually spend their hours, and what shifted the split away from writing code?
Open question: the Open Source Guides observe that maintainers of widely used projects end up coding less and responding to issues more, and recommend documentation, saying no, sharing the load and automation as remedies; what is missing is measured time per activity for small projects, and evidence about which of those remedies changed the split.
-
Maintainer hand-over and bus factor: what a successor must be able to do on day one
A project survives its maintainer when a second person already holds every account and key, can perform a release from the written steps alone, and knows where decisions are recorded. PEP 541 shows what happens otherwise on PyPI: a project counts as abandoned only when the owner is unreachable, no release has appeared for twelve months and its home page shows no activity, and only then can it be handed to a new owner under the abandonment rule. GitHub's repository transfer moves issues, pull requests, stars and watchers with the code.
-
Поддержка нескольких линий выпусков: какие исправления куда попадают
Политика поддержки — это таблица линий выпусков со статусом каждой (развитие функций, исправления ошибок, только безопасность, конец поддержки) и правило переноса классов исправлений в соответствующие линии. Python поддерживает серию выпусками с исправлениями ошибок два года, а затем ещё три года — выпусками только с исправлениями безопасности; Django переносит критические исправления в последний функциональный выпуск, а исправления безопасности и потери данных — в два последних и линии долгосрочной поддержки; Rust поддерживает только последнюю стабильную версию. Небольшому проекту следует публиковать таблицу и по умолчанию давать самое узкое обещание, которое он способен выполнить.
Машиночитаемо: JSON