A researcher has an algorithm that works, a convincing benchmark, and a reason other scientists might use it. SciPy's acceptance policy still asks for something the researcher cannot supply alone: someone willing to review the contribution. That requirement is a revealing statement about who keeps a scientific library usable. A new function needs another person prepared to examine its assumptions before the project takes responsibility for it.[1]

SciPy's own history gives that responsibility scale. In their 2020 account of the library, its developers described how its scope narrowed as the surrounding ecosystem expanded. Specialized packages could explore ideas outside the central library. They also warned that excessive contributor turnover loses institutional memory and can make new interfaces inconsistent with existing ones.[5] Read together, those observations suggest that choosing what to accept is also choosing what future maintainers must remember.

The second person is part of the proposal

The core developer guide weighs broad usefulness, fit with an existing submodule, implementation quality, and expected maintenance effort. It then requires both a contributor and a reviewer. The guide explicitly identifies review as a frequent sticking point and recommends finding someone with suitable domain knowledge before starting substantial work.[1]

Consider a hypothetical solver that performs beautifully on its author's examples. A reviewer might recognize that those examples avoid the difficult inputs common in another discipline. Finding that problem early changes the proposal: perhaps the method needs clearer limits, additional tests, or a different home. This is why the second person's expertise matters more than a second approving click.

There is a cost on both sides. A contributor can experience waiting as indifference; a maintainer has to decide which unfinished obligation deserves the next available hour. My reading of the policy is that SciPy makes this scarcity visible before acceptance. It cannot promise that every sound idea will acquire the people needed to maintain it.

A missing value can become years of work

The contribution guide asks authors to discuss features before finishing the implementation, then supply documentation, tests, and benchmarks. Its review questions extend to scientific correctness and behavior on empty arrays, nan, and infinity. Those are concrete prompts for scrutiny, rather than a demand for an unspecified quantity of polish.[3]

Take nan_policy, the parameter through which many scipy.stats functions specify how to handle missing or invalid numeric values. SciPy's design document distinguishes omit, raise, and propagate. For paired observations, omission should remove a whole pair when either member is nan, preserving the relationship between the surviving measurements. This is guidance for consistent API design, not a claim that every statistics function supports the parameter.[4]

Imagine paired readings (10, 11), (20, NaN), and (NaN, 31). Filtering each column independently leaves [10, 20] and [11, 31]: the arrays still have equal lengths, but the second pair has been invented. Removing incomplete pairs preserves only (10, 11). A function can return a plausible number while answering a question its user never asked.

The same specification says omitting an entirely nan input should behave like the corresponding empty input. What that means—an exception, nan, or another result—requires a decision for the particular function.[4] The algorithm's central formula cannot make that decision on its own.

This is the maintenance work hidden in an apparently small option. The test must preserve the intended behavior; the documentation must explain it; a later contributor must recognize why it exists. Reviewing those details gives the next person something more durable than confidence in the original author.

Who can settle an argument?

SciPy's published governance assigns the Steering Council responsibility for project direction and decisions that ordinary discussion cannot resolve. Its BDFL role retains final authority, but is described as a fallback expected to defer to community and council consensus. In everyday discussions, council members participate as peers. The release manager has responsibility for release timing and for deciding release contents when agreement fails.[2]

That arrangement separates several questions a contributor might otherwise collapse into one. Is the proposal in scope? Is the implementation ready? Can it reasonably enter this release? Agreement on the first question does not answer the other two.

The governance document also recognizes review, infrastructure, community assistance, education, and design when considering council membership. It deliberately avoids a fixed commit-count threshold. Institutional funding cannot override the council, and money alone does not confer institutional-partner status.[2] The stated route to influence is sustained participation in the work.

These are published rules, not evidence that every discussion is equally accessible or every backlog manageable. The strongest claim they support is narrower: SciPy gives contributors a visible account of authority, including work that produces no new function.

Make the next review easier

Independent reporting helps explain the stakes. In a 2019 Nature article, Julian Nowogrodzki described the support burden that follows scientific software releases, including work absorbed by researchers and the difficulty of funding maintenance. Interviewees emphasized readable code, documentation, and public support discussions.[6] That historical reporting is context for the labor problem, not a measurement of SciPy's staffing or funding today.

For a small laboratory with one proposed contribution, I would start with a compact explanation of the scientific need, representative awkward inputs, and a discussion of where the method belongs. A team with capacity to contribute repeatedly could also reproduce reported failures and review related changes. SciPy explicitly welcomes reviewing pull requests and triaging issues alongside writing code.[3]

There is a limit to what that preparation buys. Tests cannot guarantee acceptance, and a willing reviewer cannot turn a narrow application into a broadly useful library feature. An external package may remain the right place while its interface and audience develop. That possibility is consistent with the contribution guide's distinction between SciPy's general scope and more specialized projects.[3]

The useful signal is the work becoming shareable: another person can explain the assumptions, reproduce a failure, and judge a proposed change. A good algorithm opens the conversation. A reviewable, maintainable contribution gives that conversation a future.

Sources

1. SciPy, “SciPy Core Developer Guide,” especially “Deciding on new features”—acceptance criteria and the need for domain-qualified review; live documentation consulted October 12, 2026.
2. SciPy, “SciPy Project Governance”—council authority, the BDFL and release-manager roles, membership criteria, and institutional funding.
3. SciPy, “Ways to Contribute”—scope, early discussion, tests, benchmarks, documentation, review, and issue triage.
4. SciPy, “A Design Specification for nan_policy”—paired observations, missing-value handling, and empty-input behavior.
5. Pauli Virtanen and colleagues, “SciPy 1.0: fundamental algorithms for scientific computing in Python,” Nature Methods 17, 261–272 (2020)—project history, specialized packages, and institutional memory.
6. Julian Nowogrodzki, “Tips for open-source software support,” Nature 571, 133–134 (2019)—independent reporting on maintenance labor and support; publisher-hosted PDF.
7. SciPy 2023, “Conference Overview”—official account of the wider scientific Python gathering and source of the conference photograph.