Тема: open-source
-
Запланированный день документации привлекает больше новых контрибьюторов, чем постоянно висящий призыв помочь с документацией
Гипотеза: проект, который назначает один день с отобранным списком небольших задач по документации, доступными в этот день для ревью мейнтейнерами и меткой good-first-issue на каждой задаче, получает больше принятых изменений документации от людей, которые раньше никогда не контрибьютили, чем тот же список задач, весь год провисевший открытым; предлагается сравнение на истории одного и того же проекта.
-
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 отмечают, что письменная фиксация облегчает отказ, а ответу редко требуется больше одного-двух предложений.
-
Deprecating a function in a library: warn, document the replacement, remove on schedule
A library deprecation has four parts: a replacement that exists first, a runtime warning plus a documentation note naming the version and the replacement, a changelog entry, and a removal release fixed in advance by policy. PEP 387 requires a deprecation period of at least two years under Python's annual cadence and describes a documentation-only soft deprecation; Django removes shims no earlier than two feature releases after the warning.
-
Repositories whose setup runs as one verified command receive more first-time contributions than repositories with a manual setup list
Hypothesis: GitHub's scripts-to-rule-them-all README claims that lowering setup friction is key to faster and happier contributions; the proposal restates this measurably, predicting that repositories with a single self-checking setup command show more first-time contributor pull requests, more of them green on first push, and fewer setup issues than matched repositories with manual README steps.
-
Управление небольшим проектом: записать права на решения до того, как они понадобятся
Файл управления определяет, кто может сливать изменения, кто разрешает спор о границах проекта, как добавляют и исключают сопровождающих и как меняют сами правила. 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 поддерживает только последнюю стабильную версию. Небольшому проекту следует публиковать таблицу и по умолчанию давать самое узкое обещание, которое он способен выполнить.
-
Открытое ПО на IBM i: yum, bash как оболочка по умолчанию и запуск демона SSH
Поддерживаемый IBM стек открытого ПО для IBM i (Node.js, Python, git, bash и другие инструменты) устанавливается в виде RPM-пакетов в /QOpenSys/pkgs через yum, включает bash как рекомендуемую интерактивную оболочку и требует явного запуска демона SSH командой STRTCPSVR *SSHD, прежде чем всё это станет доступно удалённо.
Машиночитаемо: JSON