一位研究者手里有一套运行良好的算法，有说服力的基准测试，也有理由认为其他科学家会用到它。按照 SciPy 的接纳政策，还得满足一项条件：找到愿意评审这份贡献的人。这一步需要作者之外的人参与，也点明了谁在维系科学计算库的可用性。项目承担新函数的维护责任之前，需要另一位参与者愿意仔细审视它的前提假设。[1]

SciPy 自身的历史，让这份责任的分量更加清楚。开发者在 2020 年回顾这个计算库时写道，随着周边软件生态不断扩展，SciPy 逐渐收窄了自身的功能范围，专门面向某一领域的软件包则可以在核心库之外探索新想法。他们还提醒，贡献者更替过于频繁，会流失项目积累的知识与经验，也容易造成新旧接口之间的不一致。[5] 将这两点放在一起看，决定接纳什么，也是在决定今后的维护者需要记住什么。

第二位参与者，也是提案的一部分

核心开发者指南会权衡新功能的适用面、与现有子模块的契合程度、实现质量，以及预计需要投入的维护工作。除此之外，还要求贡献者与评审者同时到位。指南明确指出，评审经常是工作卡住的环节，因此建议在投入大量工作之前，先找到具备相应领域知识的评审者。[1]

设想有一个求解器，在作者给出的示例上表现出色。评审者有时会发现，这些示例避开了另一个学科中常见的棘手输入。及早发现这类问题，就能调整提案：视具体情况，为方法写明更清楚的适用限制、补充测试，或将它放到更合适的项目中。第二位参与者的专业知识，价值就在这里，远超过多一次点击同意。

双方都要付出代价。对贡献者来说，等待有时会被理解为冷淡；维护者则要在尚未完成的责任之间取舍，决定下一个可用的小时该花在哪里。这项政策可以理解为：SciPy 在接纳贡献之前，就把人手稀缺的问题摆了出来。一个想法即便在技术上成立，能否找到足够的人手长期维护，仍有待落实。

一个缺失值，足以带来多年的维护工作

贡献指南要求作者在完成实现之前先讨论功能，随后补齐文档、测试和基准测试。评审还要检查科学原理是否正确，以及函数遇到空数组、nan 和无穷大时会怎样运行。这些问题把需要仔细检查的地方列得很具体，让完善工作的要求有据可依。[3]

以 nan_policy 为例，许多 scipy.stats 函数用这个参数指定缺失值或无效数值的处理方式。SciPy 的设计文档区分了 omit、raise 和 propagate 三种取值。对于成对观测，只要其中一个值是 nan，省略操作就应移除整对观测，以保留剩余测量值之间原有的配对关系。这份文档指导的是 API 设计的一致性；至于某个统计函数是否支持该参数，还要看该函数的具体情况。[4]

设想有三组成对读数：(10, 11)、(20, NaN) 和 (NaN, 31)。如果分别过滤每一列，就会留下 [10, 20] 和 [11, 31]：两个数组的长度依然相等，第二组配对却是凭空拼出来的。移除含有缺失值的整对观测，则只会保留 (10, 11)。有时，函数返回的数值看似合理，回答的问题却已经偏离了用户原意。

同一份规范还指出，当输入全部为 nan 时，省略这些值后的行为，应与相应的空输入一致。至于具体应该抛出异常、返回 nan，还是给出其他结果，需要逐个函数作出决定。[4] 这项决定涉及核心公式之外的考量。

这就是一个看似微小的选项背后，藏着的维护工作。测试要守住预定的行为，文档要把它解释清楚，后来参与的人要理解为何如此设计。细节经过评审，下一位维护者就有了比对原作者的信任更持久的依据。

谁来解决分歧？

SciPy 公布的治理文件，将项目方向和日常讨论难以解决的决策交由指导委员会（Steering Council）负责。BDFL（终身仁慈独裁者）这一角色保留最终决定权，但其定位是后备安排，通常应尊重社区与委员会的共识。在日常讨论中，委员会成员以平等参与者的身份发言。发布经理负责确定发布时间，并在各方难以达成一致时决定发布内容。[2]

这样的安排，将贡献者容易混在一起的几个问题分开处理：提案是否属于项目范围？实现是否已经就绪？放进这次发布是否合适？第一项达成共识，后两项仍需各自判断。

在考虑委员会成员人选时，治理文件也认可评审、基础设施、社区帮助、教育和设计方面的贡献，刻意避免以固定的代码提交次数作为门槛。机构即便出资，委员会仍保有决策权，仅凭资金也不足以获得机构合作伙伴身份。[2] 按照这些规则，影响力来自持续参与项目工作。

这些成文规则所能说明的范围有限。讨论对每个人是否同样开放、积压工作是否都能妥善处理，还需要另外的证据。规则本身支持的是一个更具体的判断：SciPy 向贡献者公开说明了权责如何分配，也承认那些没有产出新函数的工作。

让下一次评审更容易

独立报道有助于理解这类工作的分量。Julian Nowogrodzki 在 2019 年的一篇《自然》文章中，描述了科学软件发布后随之而来的用户支持负担，包括研究者承担的工作，以及维护经费难以筹措的问题。受访者强调了代码可读性、文档和公开支持讨论的重要性。[6] 这篇历史报道为维护劳动的问题补充了背景，其内容限于当时的报道，SciPy 今天的人手和经费状况仍需另外衡量。

对于准备提交一项贡献的小型实验室，起点可以是一份简明的科学需求说明，几组有代表性的棘手输入，再加上对方法应归入何处的讨论。有能力持续贡献的团队，还可以复现他人报告的故障，参与相关改动的评审。SciPy 明确欢迎人们在编写代码之外，评审拉取请求（pull request），并协助问题分流与初步处理（issue triage）。[3]

这些准备能带来的帮助也有范围。测试齐备，是否接纳仍要综合判断；即使有人愿意评审，面向狭窄应用的功能也仍须满足通用计算库的广泛适用要求。在接口与用户群逐渐成熟的过程中，外部软件包可以继续作为合适的归宿。这种安排，也符合贡献指南对 SciPy 通用功能范围与专门领域项目所作的区分。[3]

真正有用的信号，是这份工作开始能够由他人共同承担：另一位参与者能够解释其中的假设，复现故障，并判断一项改动是否合适。一个好算法开启讨论，一份便于评审、能够长期维护的贡献，则让讨论有了延续下去的基础。

来源

1. SciPy，《SciPy 核心开发者指南》（“SciPy Core Developer Guide”），尤其是“决定是否接纳新功能”（“Deciding on new features”）一节——接纳标准，以及由具备相应领域知识的人参与评审的要求；在线文档查阅于 2026 年 10 月 12 日。
2. SciPy，《SciPy 项目治理》（“SciPy Project Governance”）——委员会权限、BDFL 与发布经理的职责、成员资格标准，以及机构资助。
3. SciPy，《参与贡献的方式》（“Ways to Contribute”）——项目范围、前期讨论、测试、基准测试、文档、评审与问题分流。
4. SciPy，《nanpolicy 设计规范》（“A Design Specification for nanpolicy”）——成对观测、缺失值处理与空输入行为。
5. Pauli Virtanen 及同事，“SciPy 1.0: fundamental algorithms for scientific computing in Python”，《自然·方法》17，261–272（2020）——项目历史、专门领域软件包，以及项目积累的知识与经验。
6. Julian Nowogrodzki，“Tips for open-source software support”，《自然》571，133–134（2019）——关于维护劳动与用户支持的独立报道；PDF 由出版方托管。
7. SciPy 2023，《大会概览》（“Conference Overview”）——官方对科学计算 Python 社区大会的介绍，也是文中大会照片的来源。