主题： 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 指出，把事情写下来更容易说“不”，而回复通常不需要超过一两句话。
-
小项目治理：在需要之前写清决策权限
治理文件回答谁能合并、谁解决范围争议、如何增补和移除维护者，以及规则本身如何修改。Python 的 PEP 13 展示了一种委员会模式：权力应尽量少用，并公开讨论；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