As LLM- / Agent-generated workflows and PRs become commonplace, we, the Scientific Python maintainer community, have to decide how to engage with them. Much of our ecosystem was crafted by hand, with a lot of care and love, so it is unsurprising that the rise in LLM contributions may at first feel threatening. I know from personal experience that I felt somewhat deflated the first time one of these landed in front of me. There was a sense of frustration and loss, and it took me a few days to process the repercussions. Discussing this with a colleague, he rightfully positioned it as follows:

The reason for the success of projects like NumPy and SciPy is not primarily superior coding ability, or better tooling, but the explosive effect of humans working well together, and enjoying their work. We cannot ignore that human and social element, because if we do, we lose it all, and we really do become lesser versions of programming teams in companies.

In Rebel Code (Moody, 2001), there is this idea that open-source has always been a movement of rebellion, an attempt at taking back the commons from enclosure. What does the rebellion look like when it loses it social form? What kind of people will we lose? — Matthew Brett

It is against this backdrop that I spent a week pacing the corridor, hand-wringing. This post is some part of the result: an attempt at exploring risks and impacts of LLMs and agents on our ecosystem, and how we, as a community, may agree upon common cultural norms and standards for integrating such technology into contributor pathways and workflows. It is not a philosophical piece, jumping pretty much directly into pragmatic concerns. I think the other conversation, the one that ties more directly into Matthew’s concerns above, is also very much worth having.

Admittedly, my initial sense of foreboding around LLMs upending our community’s culture of collaboration, while by no means gone, has somewhat dissipated as I’ve started to also contemplate the other side of the coin: how these changes may benefit maintainers, who have, over the years, increasingly been burdened with more menial tasks, drawing them away from the work that originally attracted them to the ecosystem.

Whether we like it or not, the world has changed irrevocably, and now is a good time to consider how to position ourselves within it.

I start this post outlining concerns, since these have been the topic of most AI conversations within our community. I’ll follow with a section on proposed guidelines that we may iterate on, and end with a more hopeful section of how we may benefit from the revolution underfoot.

Maintainer concerns#

Licensing#

The earliest concern raised around LLMs was that they almost certainly violate licensing conditions. In many cases, they will readily produce material derived from training sources that have licenses incompatible with the library you are contributing to. Being a summarization of a large corpus, an LLM is unlikely to even know that it drew upon a BSD-licensed source when generating code, and as such attribution will not be given.

Of course, it matters what you generate. If you refactor a test suite or correct spelling, you are unlikely to contravene any licenses. If, however, you are implementing a sophisticated algorithm, perhaps one that exists in, say, GPL’d libraries (incompatible with our BSD-based ecosystem), the risk increases significantly.

Colleagues I spoke to prior to writing this post mentioned that they often use LLMs for annoying one-off tasks: generating an nginx configuration, writing an OPML-to-YAML converter, or setting up some throwaway experiment. There’s little reason to have licensing concerns about such use-cases.

Introduction of subtle bugs#

LLMs typically operate with limited context. Problem-specific context needs to be selected and provided by the user, and it is not clear what optimal context entails. Certain categories of prediction mistakes occur frequently, including hallucinations and over-confidence. Even having a “good memory” (i.e., being able to process and reference a lot of material quickly) cannot account for such missing context, and therefore proposed solutions may be sub-optimal. It happens, therefore, that contributions generated by LLMs introduce subtle bugs, due to a lack of systems architecture awareness. These are bugs which, unfortunately, you—the maintainer—will be responsible for resolving in the future :)

In a (mostly positive) summary of the current (beginning of 2026) state of AI for coding¹, Andrej Karpathy writes:

The mistakes have changed a lot - they are not simple syntax errors anymore, they are subtle conceptual errors that a slightly sloppy, hasty junior dev might do. The most common category is that the models make wrong assumptions on your behalf and just run along with them without checking. They also don’t manage their confusion, they don’t seek clarifications, they don’t surface inconsistencies, they don’t present tradeoffs, they don’t push back when they should, and they are still a little too sycophantic [telling users what they want to hear]. — Andrej Karpathy²

Reviewer frustration#

LLM contributions can be generated at a staggering pace, but reviews still require careful human attention. And while a first pass LLM review is fine, we’re not going to merge changes without looking at and understanding them first. After all, that is why the review process exists in the first place—because we’ve learned the cost of moving forward too hastily, and of making decisions without carefully considering their impact. Unless the contributor is attentive and deliberately careful in the follow-up conversation, the interaction may feel hollow and dehumanized, and generate frustration among reviewers. There are ways to improve the situation (see “Potential guidelines” below), but the essence of this concern is that it can be very discouraging for “artisans” to have to engage with—and spend time on—code that cost very little to build.

General concerns#

A reduction in learning#

When programmers shift towards relying on LLMs, they will be tempted to focus less on learning. Why go through the pain of figuring out a complex code base, or understanding an algorithm you are working on, when all that can be taken care of on your behalf? The reward is immediate, but over time there is a cost to bear as the contributor’s abilities decrease—or never evolve in the first place. This affects, in particular, those who are learning programming and problem-solving skills for the first time.

To be fair, there are good learning opportunities with LLMs as well: they may help you better understand a codebase, advise on subtleties of translating code to a new language, etc. If you apply it with care, you can benefit without succumbing to the risks—but it requires a fair amount of discipline, and humans are better at avoiding suffering than disciplining ourselves.

Uncertain improved efficiency#

Research is still out on whether AI improves coding efficiency, especially when it comes to experienced developers working on open source projects they know well. Preliminary studies of this specific scenario suggest neutral to negative results.³

Somewhat tongue in cheek, software engineer Mike Judge notes:

If so many developers are so extraordinarily productive using these tools, where is the flood of shovelware? We should be seeing apps of all shapes and sizes, video games, new websites, mobile apps, software-as-a-service apps — we should be drowning in choice. We should be in the middle of an indie software revolution. We should be seeing 10,000 Tetris clones on Steam. — Mike Judge⁴

Experiments to determine the “AI efficiency multiplier” are structured as follows: you generate a list of tasks. For each, you estimate how long it will take, and then flip a coin to decide whether you implement the solution using the “classic approach”, or by using an agent. You then do the task, estimate how long it took, and note the time it actually took.

What the METR study showed (albeit with low N, so results are uncertain) is that programmers may feel like they’re faster with AI when often they’re not. It’s an easy trap to step into, especially when having to decide between two options where one requires effort and the other does not. Again, it’s worth noting that “farming out” the task means there is a good chance that you will fail to fully comprehend the solution and its potential impact, unless you deliberately and carefully review the result.

I think the equation clearly shifts when doing tasks you are unfamiliar with. For example, if you spend most of your time building scientific code in Python, having to scaffold a website from scratch will take longer than it would using an agent. But of course you then have the benefit of knowing how to build websites, and so it matters how many times you will be doing that type of task in the future.

Eroded artistic co-creation#

Many of us got into open source because there is a deep satisfaction that comes from productive collaboration with other humans. We enjoy thinking about and talking through hard problems, learning from the best, and sharing our art. The software we build is a culmination and reflection of this culture of collaboration.

Like with any tool, we need to learn whether, when, and how to apply AI. If it is used to replace thinking, instead of merely to reduce grunt-work, it risks derailing collaboration and sucking the joy out of attentive design and meticulous problem solving.

Given all the concerns above, some projects may well decide that they should not be using it at all. We are only starting to engage more with AI contributions, only starting to see its impact on our projects and our collaborative culture. I think 2026 will prove to be highly educational.

Potential guidelines#

Given the above concerns, what should we as a community do to engage with (a) the new tools (b) developers who utilize these tools and (c) the contributions they generate. What I’m asking is: instead of being prescriptive around the tools others choose to use to do their work, can we instead formulate guidelines that will allow us to continue enjoying working together?

Here are some initial suggestions:

1. Be transparent

Trust would greatly increase if contributors declared their AI use. This would help reviewers decide how they want to engage in the review process, and make them aware of potential risks. Declaring the use of AI sets the stage for honest conversations, improving the likelihood of a good interaction.

Kernel contributors have been using tooling to generate contributions for a long time. These tools can increase the volume of contributions. At the same time, reviewer and maintainer bandwidth is a scarce resource. Understanding which portions of a contribution come from humans versus tools is helpful to maintain those resources and keep kernel development healthy. — Proposed Linux kernel developer guideline⁵

Needless to say, if a project has AI guidance (and many already do), it should be followed.

2. Take responsibility

When you submit a PR, no matter what tools you use, it is your responsibility to make sure that it addresses the problem correctly and doesn’t introduce subtle errors—in that sense, it is no different from contributing code you wrote yourself. In that case, however, you may have a clearer idea about potential pitfalls, and how careful you were in avoiding them. When using LLMs, there should be a deliberate effort to ensure that code conforms to community norms.

For example, when writing tests with an LLM, it may simply generate a large number of very similar tests, instead of using parametrization and fixtures the way the rest of the project does. It would then be up to you to identify that deficiency and refactor your code (or have the LLM refactor the code) to address it.

3. Gain understanding

With the assistance of AI, it will happen that contributors venture into territory beyond their technical expertise. With the help of LLMs, contributors are able to solve harder problems than before, but it remains crucial that they put in the effort to understand their contribution before submitting. We have to appreciate that there are some risks associated with LLM-assisted contributions, both as these models evolve to be “better programmers” and avoid common pitfalls, and as authors work out how to best provide context and assess LLM-generated content. Transparency here helps a great deal to set expectations.

For contributors, it is important to keep in mind that reviews remain human conversations between peers. Reviewers typically prefer not engaging an LLM directly, but having a knowledgeable exchange around the motivation behind a PR, how various technical choices are justified, and the impact it may have on the rest of the code.

We therefore recommend that contributors work to fully understand the changes they submit, and present it in such a way that reviewers can dive straight into the motivation, design decisions, and technical requirements.

4. Honor Copyright

I had a longer section here around copyright and attribution, but I cut most of it, since I fear we may have run out of good options. Projects in our ecosystem have been very deliberate about adhering to licensing requirements, and about giving attribution. But LLMs are unlikely to ever produce meaningful license updates, and by this stage they’ve read and assimilated most of our library codebases. Patterns that were once copyrighted are now commonly duplicated and fully generic.

Personally, I am pulled in two directions: first, I care about people getting credit for the work they do. On the other hand, and also the reason we do not employ copyleft licenses, is that we really want our work to be used widely and impact as many lives as possible. Credit is important, especially for younger people starting their careers, and we’ll have to continue thinking about how to give it justly. Practically speaking, however, I’m not convinced that licenses are an effective mechanism to enforce credit anymore.

I think it is reasonable to expect, still, that when you make a contribution you have a reasonable sense that you are not violating copyright. After all, you cannot force contributors to some random GPL library to be OK with your using their code. In the case of a test suite refactoring, or contributing to a typical React app, this is unlikely to be a problem. But once you start implementing new algorithms in SciPy, e.g., you’re running the risk of, e.g., copying algorithms or bringing in copyrighted ideas from other projects.

I’d therefore recommend playing it safe and only making AI-guided contributions that clearly steer clear of copyright infringements. Also see the Python Developer’s Guide on what they consider reasonable use-cases.

Potential Benefits#

Notwithstanding the above concerns, and pervading sentiments around AI in our community, I think it’s worth honestly assessing potential benefits.

When I started writing this blog post, I had dabbled with LLM-generated code from time to time “to keep my finger on the pulse”. I was, frankly, quite underwhelmed. During a routine re-evaluation in December, however, I noticed a marked shift in how quickly an agent was able to solve a routine coding task. The same caveats as usual applied (the AI sometimes went down rabbit holes, it made up function names, etc.), but it did give me pause.

As I wrestled with the implications of AI for our community, I realized that the Scientific Python project was formed, in part, because of the enormous burdens that maintainers now face. To address those burdens, we build tools, we coordinate, and we explore new solutions. But one thing that is very difficult to increase is labor. The existing maintainer community is slow to grow—after all, it takes a very specific kind of person to do (and enjoy doing) the work we do. And there are only 24 hours in a day—substantially fewer for many of us as we move from being students to having families, industry careers, etc.

So, here we are, at a time where we risk being immobilized by our own success: as our libraries grow and are adopted by more and more users, we are unable to add new features because we are so overburdened by maintenance requirements. And now we are presented with a tool that cannot handle the sophisticated thinking and problem solving required to architect libraries and implement novel algorithms, but that is useful for solving common maintenance chores. Then one has to wonder: is this perhaps an opportunity for us to see our maintenance burden lightened, so we can get back to the craft we love—i.e., producing hand-crafted APIs and novel implementations of algorithms that give researchers across the world access to cutting edge methods?

Conclusion#

When it comes to a disruptive technology that has the potential to rapidly reshape the ecosystem that we have built with so much care and attention to detail, how we engage with it demands careful consideration. From what I’ve seen from the current generation of LLMs, they’re not ready to provide us with best-in-class solutions, but they may already be useful in reducing some of the tedium involved in contributing. Will utilizing AI, due to the risks outlined above, unravel the very tapestry of collaboration that holds our ecosystem together, or can it be harnessed to restore developer bandwidth and preserve the “explosive effect of humans working well together”? It is worth exploring how to adjust to and incorporate these changes, and how to best let our different “coding philosophies” and tool choices co-exist—all while preserving the incredible benefit that our open-source scientific software ecosystem provides.

Please let us know your thoughts in the comments below. This post is part of an effort to come up with a community approach to AI and AI-generated contributions.

References#

• Fedora AI contribution policy
• scikit-image AI contribution guidelines
• Gentoo AI policy
• Linux Kernel: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
• Python Developer’s Guide: Generative AI

Credit#

I would like to thank the following community members for feedback on early drafts: Matthew Brett, Henry Schreiner, Dan McCloy. And Chris Holdgraf, Angus Hollands, Brian Hawthorne, for conversations on the topic. This post does not necessarily reflect their views.

This post is a while overdue, but it’s been a busy summer for everyone!

In June, several of us got together for the “annual” (well, we’ve had it twice now) Scientific Python developer summit in Seattle. Our friends at the eScience Institute were again kind enough to host us. This time around, we made the event a bit shorter to avoid clashing with graduation.

As before, the Developer Summits are for members of the community to come together, in person, so they can work. Of course, we work together already online, but the event allows us to focus our energies on cross-project concerns (that often fall by the wayside) with planning and intent.

This is why, before the summit, we have planning Zoom calls, where we identify topics of interest, which are turned into issues, which are then fleshed out and discussed prior to the event. That way, we hoped to hit the ground running—as we did!

Topics#

You can get a rough idea of what we worked on by browsing the planning issues and the summit worklog.

Broad topics included SPECs, documentation, tools & bots, lectures, scipy.sparse, telemetry, Array API, and type annotation.

Documentation#

Documentation was a much more popular topic than anticipated!

• The new mystmd tooling generated some excitement, and an experimental port of the NumPy tutorials was made by Melissa and Ross.
• Recommendations on consistent use of backticks and monospaced font were submitted to numpydoc and pydata-sphinx-theme, respectively.
• Madicken, Paul, and Dan worked together to extend PyData Sphinx Theme’s testing infrastructure, by combining Sphinx Build Factory (for generating small test sites) with Playwright (for browser automation).
• Eric and Elliott fixed an intersphinx issue in sphinx-gallery.

SPECs#

The Scientific Python Ecosystem Coordination documents (SPECs) aim to improve coordination of technical development across the ecosystem.

Several new SPECs were started:

• SPEC-?: Dispatching (spatch)
• SPEC-8: Securing The Release Process
• SPEC-9: Governance
• SPEC-10: Changelog and release documentation
• SPEC-12: Formatting mathematical expressions
• SPEC-13: Naming conventions

Some existing SPECs were discussed and improved:

• SPEC-7: Seeding pseudo-random number generation (SPRaNG)

Matplotlib endorsed several SPECs.

Tooling#

• We created a new tools team to handle the ever-growing list of tools we maintain.
• Eric added his circleci-artifacts-redirector-action to the suite.
• Matthias brought over his backport bot and set up a maintenance team.

SciPy#

Several of the SciPy developers were present, and we used the opportunity to celebrate Dan Schult joining as a core developer 🎉! Matt and Pamphile did some work on the new distribution infrastructure, Dan worked on sparse (remotely with CJ), and a PR adding newly-supported const statements to Cython code got reviewed and merged. Eric isolated a non-deterministic bug in Sphinx that was impacting parallel builds of SciPy’s documentation. He found a work-around that had been eluding the team for months!

Unplanned collaborations#

As is the nature of these events, some collaborations arise spontaneously. For example:

• Nick and Ariel explored using Awkward Array for neuro-tractography.
• Nick and Mridul explored using scipp for high-energy physics data.
• Guen worked on telemetry.
• Inessa and Sanket discussed best practices for community surveys and project governance.
• Sebastian and Thomas discussed parallelization APIs.
• Inessa, with input from Tim and Thomas, finalized the design of the 2024 scikit-learn user survey.
• Erik and Dan discussed index compression options for CSR-like N-D sparse arrays.

Conclusion#

Numerous other PRs were made, of which a number were probably not even captured in the worklog. But, besides the inherent satisfaction of working together with this great group, the best feature of the summit was that we were able to hang out, bonding over our communal joys and struggles—both technical and personal.

We are grateful to the ecosystem developers who gave up their time to attend the summit (many had to put in leave just to do more work!). The summits are valuable, and translate to a lot of work getting done and decisions being made. We hope that there will be more on the horizon!

In November 2022, the Chan Zuckerberg Initiative (CZI) awarded the Scientific Python project with a grant to improve communications infrastructure and accessibility. This proposal involves several key areas to improve sustainability, inclusivity and accessibility of the Scientific Python ecosystem. One of these areas is making software documentation and user interfaces available in multiple languages. We are happy to announce that we have organized the necessary infrastructure and processes to allow volunteers to start translating multiple project websites.

In this blog post, we will discuss how we set up manage translations for Scientific Python projects, and how you can participate in the translation and localization effort. The work described here was done by Quansight Labs.

Why translations are important#

Accessibility and inclusion are important aspects of building a healthy community around open source software development. By providing translations of our websites, documentation and user interfaces in multiple languages, we can reach a wider global audience, thereby making our projects more inclusive and increasing the diversity of contributions and ideas. This is especially important for scientific software projects, which are used by researchers and scientists from around the world with a wide range of language proficiencies and backgrounds.

Recently, machine translation tools have made it easier to translate content into multiple languages. While such tools are improving, they often fall short in the context of technical documentation. In addition, without a human in the loop, maintainers can never be sure if translated content is correct for languages they are not familiar with. For this reason, we chose to work with a group of volunteers to help us translate selective subsets of project websites and documentation.

Setting up translations workflow#

You may have seen that translations into some languages are already available for numpy.org, with a version switcher in the top right corner.

A number of core projects have also joined this effort and are set up to start with translations. At the moment, we are targeting NumPy, SciPy, NetworkX, Xarray, and pandas. We’re offering to help other core projects integrate something similar into their websites, and we aim to accomplish this in a way that requires minimal effort from the core project maintainers, using Crowdin.

For the moment, our scope is to translate only the projects’ websites—the landing pages you see when you check out the links above—and not full documentation. We are intentionally starting small with the goal of completing this first phase and then potentially expanding once the translations team is established.

Translations team#

For new contributors who are looking to get involved in the projects they already use and depend on, joining the translations team can be a great way to get started. Because of how the translations infrastructure is set up in Crowdin, this workflow is particularly well-suited for new contributors who are not yet familiar with GitHub or other development tools—they can work entirely on the Crowdin web platform.

One advantage of setting this up at the Scientific Python level, and not on a per-project basis, is that the translations team can work on multiple projects, and knowledge and experience can be shared. This also helps to ensure that translations are consistent across projects.

The translations team will be responsible for:

• Translating (and reviewing) content into multiple languages;
• Ensuring that translations are accurate and up-to-date;
• Engaging with the community to help maintain and improve translations.

Once the translations are complete and reviewed, a maintainer for each project can merge the translations and publish them to the project website. After the initial setup, the translations team will be able to manage the translations workflow independently, with minimal input from the project maintainers.

For more information on the infrastructure and team working on the translations, and how to join as a translator, see https://scientific-python-translations.github.io/. You can also join the #translation channel at the Scientific Python Discord server.

One outcome of the 2023 Scientific Python Developer Summit was the Scientific Python Development Guide, a comprehensive guide to modern Python package development, complete with a new project template supporting 10+ build backends and a WebAssembly-powered checker with checks linked to the guide. The guide covers topics like modern, compiled, and classic packaging, style checks, type checking, docs, task runners, CI, tests, and much more! There also are sections of tutorials, principles, and some common patterns.

This guide (along with cookie & repo-review) started in Scikit-HEP in 2020. During the summit, it was merged with the NSLS-II guidelines, which provided the basis for the principles section. I’d like to thank and acknowledge Dan Allan and Gregory Lee for working tirelessly during the summit to rework, rewrite, merge, and fix the guide, including writing most of the tutorials pages and first patterns page, and rewriting the environment page as a tutorial.

The guide#

The core of the project is the guide, which is comprised of four sections:

• Tutorials: How to go from “research” code to a basic package, for beginning readers.
• Topical guides: The core of the guide, for intermediate to advanced readers.
• Principles: Some general principles from the NSLS-II guide.
• Patterns: Recipes for common situations. Three pages are there now; including data, backports, and exports.

From the original Scikit-HEP dev pages, a lot was added:

• Brand new guide page on documentation, along with new sp-repo-review checks to help with readthedocs.
• A compiled projects page! Finally! With scikit-build-core, meson-python, and maturin. The page shows real outputs from the cookiecutter, kept in sync with cog (a huge benefit of using a single repo for all three components!)
• Big update to GHA CI page including a section on Composite Actions given at the Dev summit.
• CLI entry points are now included.
• Python 3.12 support added, Python 3.7 dropped.
• New sp-repo-review badges throughout (more on that later!)
• Updates for Ruff’s move and support for requires-python.
• Lots of additions for GitHub Actions.

The infrastructure was updated too:

• Using latest Jekyll (version 4) and latest Just the Docs theme. More colorful callout boxes. Plugins are used now.
• Live PR preview (provided by probably the world’s first readthedocs Jekyll build!). Developed with the Zarr developers during the summit.
• Better advertising for cookie and sp-repo-review on the index page(s).
• Auto bump and auto-sync CI jobs.

Cookie#

We also did something I’ve wanted to do for a long time: the guide, the cookiecutter template, and the checks are all in a single repo! The repo is scientific-python/cookie, which is the moved scikit-hep/cookie (the old URL for cookiecutter still works!).

Cookie is a new project template supporting multiple backends (including compiled ones), kept in sync with the dev guide. We recommend starting with the dev guide and setting up your first package by hand, so that you understand what each part is for, but once you’ve done that, cookie allows you to get started on a new project in seconds.

A lot of work went into cookie, too!

• Generalized defaults. We still have special integration if someone sets the org to scikit-hep; the same integration can be offered to other orgs.
• All custom hooks removed; standard jinja now used throughout templates. Using cookiecutter computed variables idiom too. Windows still fully supported and tested. Adding new choices is much easier now.
• Added cruft (a cookiecutter updater) testing.
• Dual-supporting copier now too, a cookiecutter replacement with a huge CLI improvement (and also supports updating). Might be the first project to support both at the same time. CI (or nox locally) checks to ensure generation is identical. Much better interface with copier, including validation, descriptive text, arrow selection, etc.
• Improved CLI experience even if using cookiecutter (like no longer requesting current year).
• Reworked docs template.
• Support for cookiecutter 2.2 pretty descriptions (added about four hours after cookiecutter 2.2.0 was released) and cookiecutter 2.2.3 choice descriptions.
• GitLab CI support when not targeting github.com URLs (added by Giordon Stark).
• Support for selecting VCS or classic versioning.

Repo-review#

See the introduction to repo-review for information about this one!

Along with this was probably the biggest change, one requested by several people at the summit: scientific-python/repo-review (was scikit-hep/repo-review) is now a completely general framework for implementing checks in Python 3.10+. The checks have been moved to sp-repo-review, which is now part of scientific-python/cookie. There are too many changes to list here, so just the key ones in 0.6, 0.7, 0.8, 0.9, and 0.10:

• Extensive, beautiful documentation for check authors at (used to help guide the new docs guide page & template update!)
• Support for four output formats, rich (improved), svg, json (new), html (new).
• Support for listing all checks.
• GitHub Actions support with HTML step summary, pre-commit support.
• Generalized topological sorting to fixtures, dynamic fixtures.
• Dynamic check selection (via fixtures! Basically everything is powered by fixtures now.)
• URL support in all output formats (including the terminal and WebApp!)
• Support for package not at root of repo.
• Support for running on a remote repo from the command line.
• Support for select/ignore config in pyproject.toml or command line.
• Pretty printed and controllable sorting for families.
• Supports running from Python, including inside a readme with something like cog.
• Support for dynamic family descriptions (such as to output build system and licence used).
• Support for limiting the output to just errors or errors and skips.
• Support for running on multiple repos at once, with output tailored to multiple repos. Also supports passing pyproject.toml path instead to make running on mixed repos easier.
• Support for linting [tool.repo-review] with validate-pyproject.

The full changelog has more - you can even see the 10 beta releases in-between 0.6.x and 0.7.0 where a lot of this refactoring work was happening. If you have configuration you’d like to write check for, feel free to write a plugin!

validate-pyproject 0.14 has added support for being used as a repo-review plugin, so you can validate pyproject.toml files with repo-review! This lints [project] and [build-system] tables, [tool.setuptools], and other tools via plugins. Scikit-build-core 0.5 can be used as a validate-project plugin to lint [tool.scikit-build]. Repo-review has a plugin for [tool.repo-review].

sp-repo-review#

Finally, sp-repo-review contains the previous repo-review plugins with checks:

• Fully cross-linked with the development guide. Every check has a URL that points to a matching badge inside the development guide where the thing the check is looking for is being discussed!
• Full list of checks (including URLs), produced by cog, in readme.
• Also ships with GitHub Action and pre-commit checks
• Released (in sync with cookie & guide, as they are in the same repo) as CalVer, with release notes.
• Split CI that selects just want to run based on changed files, with green checkmark that respects skips (based on the excellent contrition to pypa/build).

Using the guide#

If you have a guide, we’d like for you to compare it with the Scientific Python Development Guide, and see if we are missing anything - bring it to our attention, and maybe we can add it. And then you can link to the centrally maintained guide instead of manually maintaining a complete custom guide. See scikit-hep/developer for an example; many pages now point at this guide. We can also provide org integrations for cookie, providing some customizations when a user targets your org (targeting scikit-hep will add a badge).

The first Scientific Python Developer Summit (May 22-26, 2023) brought together 34 developers at the eScience Institute at the University of Washington to develop shared infrastructure, documentation, tools, and recommendations for libraries in the Scientific Python ecosystem.

Pre-summit planning#

Prior to the summit we held several hour-long planning meetings:

• General (2023-02-27)
• May 15, Package metrics, DevStats
• May 15, SPECs
• May 18, Community & Documentation
• May 19, Build Systems & CI Infrastructure
• May 19, PyTest plugins & Sphinx extensions

Summit execution#

At the summit, we had a brief check-in and then split into several groups based on each developers time and interests. Raw work progress and log have been collected in a document, we highlight just a few of things we accomplished below:

Sparse arrays#

Almost a quarter of the group worked on sparse arrays for the entire week. This work is part of a larger, multi-year effort to improve and expand SciPy’s sparse array API, which will eventually involve removing the sparse matrix API and eventually np.matrix.

More details can be found in the Developer Summit 1: Sparse blog post.

Scientific Python Ecosystem Coordination documents#

We made significant progress on several SPECs, which had been drafted during previous sprints.

SPEC 0—Minimum Supported Versions , an updated and expanded recommendation similar to the NEP 29, was discussed and endorsed by several core projects.

SPEC 1—Lazy Loading of Submodules and Functions was discussed and endorsed by two core projects.

SPEC 2—API Dispatch was discussed (in a follow-up video meeting just after the summit) and is in the process of being marked as withdrawn or something similar.

SPEC 3—Accessibility was discussed and updated. We hope to see it endorsed by several core projects in the near future.

SPEC 4—Using a creating nightly wheels was rewritten, a helper GitHub action upload-nightly-action was created, and PRs to update the various projects to use the new nightly wheels location were made. The updates are now complete and the SPEC was endorsed by two core projects.

We anticipate several more core projects to endorse the existing SPECs over the coming months and we are now holding regular SPEC steering committee meetings to continue developing and expanding the SPECs.

Community building#

We created a comprehensive community guide to empower projects in fostering their communities. This guide includes essential information on the role of community managers, along with practical strategies for community meetings, outreach, onboarding, and project management.

Development Documentation#

We created a development guide, a new project template, and existing project review.

Serendipitous Collaboration#

One of the fun things that happens at summits like these are the chance encounters of people from different projects. For example, a couple of attendees worked on creating a co-collaboration network across the broader scientific python ecosystem. This gave us the opportunity to look at how contributors collaborate across projects. We could see how the bigger projects were all clustered together as there are multiple contributors who share maintenance duties for multiple projects. We could also, for example, see how the Scikit-HEP cluster was a bit further away from the usual scientific Python cluster. An action item for us :) We need more collaboration!!

Pytest plugins/Sphinx extensions#

Several attendees worked on pytest plugins and Sphinx extensions:

• pytest-regex was created to support selecting tests with regular expressions.

• pytest-doctestplus was moved upstream into the Scientific Python organization. The summit provided new momentum to develop new features (e.g. produce updated docstring), and to use it for the NumPy documentation testing.

• sphinx-scientific-python, a new extension as a home for various features from the ecosystem, e.g., we agreed on bringing existing extensions from MNE tools to this extension.

• pydata-sphinx-theme updates

SciPy release management progress#

The first release candidate of SciPy 1.11.0 was published on PyPI on May 31, 2023, five days after the conclusion of the summit. The summit facilitated high-bandwidth decision making on several proposed SciPy code changes by allowing the current SciPy release manager (Tyler Reddy, Los Alamos National Laboratory) to consult with other SciPy core developers in person. Specific code changes were discussed with the following SciPy maintainers: Stefan van der Walt (scipy.ndimage), CJ Carey (scipy.sparse), Matt Haberland (scipy.stats), and Pamphile Roy (scipy.stats). When SciPy releases are performed out of band from the summit, the release manager will often have to delay incorporation of useful code changes to the next release six months later, due to lack of availability of the pertinent domain experts.

Package metrics#

We factored out a general developer statistics package from our prototype developer statistics website.

(May 22-26, 2023, Seattle WA) – The first Scientific Python Developer Summit provided an opportunity for core developers from the scientific Python ecosystem to come together to:

1. improve joint infrastructure
2. better coordinate core projects
3. work on a shared strategic plan

Related notes/sites:

• Worklog.
• Planning Meeting Notes and Info.

One of the focuses of the summit was Sparse Arrays, and specifically their implementation in SciPy. This post attempts to recap what happened with “sparse” at the summit and a glimpse of plans for our continuing work. The Sparse Array working group holds open follow-up meetings, currently scheduled every two weeks, to continue the momentum and move this project forward.

At the Summit, we focused on improving the newly added Sparse Array API in SciPy, that lets users manipulate sparse data with NumPy semantics (before, SciPy used NumPy’s 2D-only Matrix API, but that is slated for deprecation). Our goal at the summit was to give focused energy to the effort, bring new people on board, and connect downstream users with the development effort. We also worked to create a working group for this project that would last beyond the summit itself.

The specific PRs and Issues involved in scipy.sparse are detailed in the Summit 2023 scipy.sparse Report, with more detailed description appearing in the Summit Worklog. Some big picture take-aways are:

• Reorganized how to check for matrix/array/format info. This involved adding a format attribute describing which format of sparse storage is used, changing functions issparse/isspmatrix as well as shifting the class hierarchy to allow easy isinstance checking. The interface going forward includes:
  • issparse(A): True when a sparse array or matrix.
  • isinstance(A, sparray): True when a sparse array.
  • isspmatrix(A): True when a sparse matrix. To check the format of a sparse array or matrix use A.format == "csr" or similar.
• Made decisions about how to approach the “creation functions” for sparse arrays. The big-picture approach is to introduce new functions with an _array suffix which construct sparse arrays. The old names will continue to create sparse matrix until post-deprecation removal. Some specific changes made include:
  • Add the creation function diags_array(A) (and planned for eye_array, random_array and others).
  • Create a sparse.linalg.matrix_power function for positive integer matrix power of a sparse array
• Made progress toward 1D sparse arrays. The data structures for 1d may be quite different from 2d. A prototype coo_array allowed exploration of possible n-d arrays, though that is not a short-term goal.
• Explored feasibility and usefulness of defining __array_ufunc__ and other __array_*__ protocols for sparse arrays
• Made clearer distinction between private and public methods for sparse arrays
• Improved documentation for sparse arrays

Our goal is to have a working set of sparse array construction functions and a 1d sparse array class (focusing on coo_array first) in plenty of time for intensive testing before SciPy v1.12. This will then allow us to focus on creating migration documents and tools as well as helping downstream libraries make the shift to sparse arrays. We hope to enable the removal of deprecated sparse matrix interfaces in favor of the array interface. For this to happen we will need most downstream users to shift to the sparse array API. We intend to help them do that.

Our work continues with a community call every two weeks on Fridays. Near term work is to:

• Continue improving sparse creation functions: diags, eye, random and others.
• Deprecate some matrix-specific functionality
• General performance improvements
• Adapting scikit-learn to support sparse arrays (to be discussed with scikit-learn’s maintainers)

We are delighted to announce a two-year grant from the Chan Zuckerberg Initiative (CZI) in support of the Scientific Python project. This grant will support work on common web themes, joint infrastructure and practices, accessibility, and interactivity of core library documentation. We are particularly excited that, through this work, we may expand global participation of scientific communities in using and contributing to Python tools. It is, to the best of our knowledge, the first time that a scientific open source community has received significant support for accessibility and internationalization efforts.

CZI & Scientific Python#

CZI continues to support many impactful and innovative projects in the scientific Python community through its Essential Open Source Software for Science (EOSS) program. Today, they announced the 5th funding cycle of that program. This grant to Scientific Python, while outside the EOSS program, complements it well. Among other things, the Scientific Python project aims to support, document, and make accessible common practices & infrastructure. Such infrastructure will benefit not only the projects at the core of the ecosystem, but also those well beyond it.

“We are thrilled to partner with the Scientific Python project, an effort to harmonize a critical set of open source research software projects widely used across all the areas of biomedical research that CZI supports. The distributed nature of the scientific open source ecosystem will greatly benefit from their efforts to standardize best practices and focus on ecosystem-level initiatives,” said Dario Taraborelli, Science Program Officer at the Chan Zuckerberg Initiative.

What will we be working on?#

This grant will support core scientific Python projects by doing release management, writing documentation, building and supporting joint infrastructure, and by measuring and publishing metrics on community involvement and project health. In addition, here are some specific deliverables:

Common web themes#

There are two web themes commonly deployed on community sites: the Scientific Python Hugo Theme—for project websites, and the pydata-sphinx-theme—for documentation. We will improve these themes, effectively upgrading several project websites simultaneously. By fostering theme adoption, we will help the ecosystem present a more unified front to users, while reducing the web maintenance burden on developers. Other theme work includes better responsive layouts (important for use on mobile and tables), blogging facilities, increased usability, and accessibility compliance.

Adopting and promoting access-centered practices#

Better accessibility of online resources increases usability for everyone, while fostering community participation and inclusion. The Scientific Python Hugo Theme and pydata-sphinx-theme are natural conduits for introducing accessibility standards and best practices to the broader ecosystem. We will develop access-centered best practices and contribution guidelines, organize online workshops, and work with other maintainers to improve their projects’ documentation and homepage accessibility. A set of access-centered practices will be written up as a Scientific Python Ecosystem Coordination document (or SPEC, for short), to provide guidance to those projects we cannot support directly.

A key aim of this work is to have web and documentation themes, as well as core scientific Python project websites, meet the applicable Web Content Accessibility Guidelines.

Interactive documentation & translations#

Documentation is key to a project’s success, and good documentation is approachable to end users with a wide range of backgrounds and skills. While most scientific Python projects value documentation and work hard at it, there is still much room for improvement.

One such improvement is translation and localization. Development takes place in English, as reflected by project websites and documentation. While many contributors are comfortable with English as a first, second, or even third language, the language barrier excludes especially users that are very young, are new to the community, have learning disabilities, or are from the Global South—all potential future contributors and leaders in the scientific Python community! We will therefore translate key pages of core project websites, and provide translation infrastructure for the web themes.

A second area of improvement is interactivity. Interactive project documentation has the potential to engage less experienced users, making it easier to experiment with and teach ecosystem libraries. We will work on documentation interactivity by providing seamless, in-browser execution of code via JupyterLite, a WebAssembly Jupyter distribution.

Who will be involved#

The four PI’s for this grant are Stéfan van der Walt (UC Berkeley; NumPy, scikit-image, SciPy; Scientific Python Hugo Theme), Tania Allard (Quansight Labs; JupyterHub, NumFOCUS DISC, Jupyter accessibility), Jarrod Millman (Scientific Python; NetworkX; scikit-image; Scientific Python Hugo Theme, pydata-sphinx-theme), and Ralf Gommers (Quansight Labs; SciPy, NumPy, data-apis.org). Melissa Weber Mendonça (Quansight Labs; NumPy, SciPy) and Chris Holdgraf (2i2c; Project Jupyter, MyST, pydata-sphinx-theme) will participate as key personnel, providing expertise in documentation and Sphinx themes in particular. Jarrod and Stéfan are co-creators of the Scientific Python project, and everyone on the grant has been involved in the larger scientific Python ecosystem and community for many years.

Next steps#

Today was announcement day, but the real work starts in December. Some topics we’ll be able to dive straight into; others will require hiring—and we’re excited to involve new web designers, accessibility experts, and engineers in this journey. Stay tuned—there’s a lot more to come!

To connect with the team, and to follow job posts, please join us at https://discuss.scientific-python.org.

The Scientific Python project is an initiative to better coordinate and support the scientific Python ecosystem of libraries and to grow the surrounding community. It aims to improve communication between ecosystem projects, to better plan for their joint future, and to make that future a reality.

Why is this important?#

Initially, the Scientific Python developer community was small, so that it was easy to discuss important ecosystem-wide decisions at events like the annual SciPy conference. But with the rapid growth of the community, number of libraries, as well as geographical diversification, this was no longer possible. Scientific Python is a loose federation of somewhat independent community projects, and while this configuration is robust, it also tends to favor reinvention of the wheel and decisions that focus on project needs, instead of being strategically aligned with the entire ecosystem. Ultimately, the different projects depend on one another, so that it makes sense to have close coordination between them.

How are we doing this?#

SPECs#

The SPECs, or Scientific Python Ecosystem Coordination documents, provide a mechanism through which the community can establish cross-project policies. They function similarly to PEPs, NEPs, SKIPs, or any of the other enhancement proposals—except that they are relevant to multiple projects in the ecosystem.

These documents will be recommendations written up by the community, and their authority will derive from endorsement by popular libraries. Some of them are already in progress and many are on the way!

SPECs are short and concise, and are endorsed by core projects in the ecosystem once they are adopted.

Shared infrastructure#

We provide common engineering infrastructure to help maintainers. Some tools we currently work on include a Hugo web theme for project websites, a self-hosted privacy-friendly web analytics platform, a shared discussion forum, the devpy developer CLI, this blog, and a project development statistics dashboard.

Developer events#

We organize virtual “domain summits” where developers can meet to discuss relevant cross-project topics. These will be recorded and shared on our YouTube channel. Thus far, we’ve organized four such events on: API dispatching, alt-text for improved accessibility, domain stacks, and sparse arrays.

We also organize an annual in-person developer summit: a week of intense collaboration, with work scheduled ahead of time, during which we address as many cross-project concerns as we can.

Documentation#

We work on documentation for new contributors and maintainers. Our YouTube channel hosts onboarding videos, that show how to get started contributing to a scientific Python project, as well as developer interviews. Over the next year, we also plan to unify several disparate community resources into a maintainer guide.

Community outreach#

We love to reach out to and connect with our growing community of users and developers! Platforms we are present on include Twitter, Facebook, Instagram, and TikTok.

Who is behind this?#

The short answer: anyone who wants to be. The long answer: we are a community of volunteers from different scientific Python ecosystem packages. There are several teams working on the different aspects of the project, such as our community managers & leaders, the SPEC steering committee, and blog content reviewers and editors. The project is led by Jarrod Millman and Stéfan van der Walt, both long-term community members who care deeply about the success of the ecosystem and its developers.

Currently there are eight projects that endorse the SPECs: IPython, Matplotlib, NetworkX, NumPy, pandas, scikit-image, scikit-learn, and SciPy. However, contributors from many more projects participate on our discussion forum, write blogs, and contribute to the community in other ways. We welcome everyone to become part of the community and to contribute however they can!

What am I doing here?#

For the past couple of months I have been a community manager for the project. This includes recording documentation videos for the website, recording developer interviews for our YouTube channel, presenting talks at conferences, hosting developer events, creating content for our Instagram, Facebook, TikTok, and Twitter channels, and many other things that I never thought I would do.

Why? Because I believe in this. Jarrod and Stéfan reached out to me last year, inviting me to be part of this amazing idea and I was honored and very grateful. I wasn’t sure that I could do it, but now I find myself here and I know that this is the right place for me. Not because I have a lot of experience in these things (I had actually never even used TikTok before joining the project), but because I care. I have learned the importance of building community and while the Scientific Python tools are amazing, what makes the difference is the community around them and I’m grateful to be able to help make this community great.

I have learned a lot from the Scientific Python ecosystem by being a community manager, I have met a lot of wonderful people and I have seen what people can do with the tools that the ecosystem offers. So, my take: The Scientific Python project is a great bet. Open source Scientific Python is about much more than coding, it is about collaborating, teaching, and communicating. So unifying the community and promoting the integration of the projects sounds like the perfect path to follow in order to get the most out of the ecosystem.

The Scientific Python blog has just gotten a little more accessible! If you didn’t catch our invite on Twitter or run into the problem firsthand, there’s a good chance you might not have noticed the new descriptions for a number of blog post images.

Since it’s not a flashy improvement, we wanted to make a point to highlight the community effort to to make a more accessible blog–and internet as a whole–last week.

What did we do?#

In the spirit of Scientific Python’s mission to build community-developed and inclusive spaces, the project had its first image description workshop on May 13, 2022. We gathered to learn about and practice writing about images from the ground up. Image descriptions– often called alt text– are one of many accessibility considerations that people making content are responsible for. Missing alt text is among the most common culprits of inaccessible content on the internet. Fortunately, missing alt text has a clear fix even for those new to with accessibility: describe the image based on its context.

During this event, thirteen people wrote 23 image descriptions to improve 11 blog posts in one hour (plus the time for post-event feedback 😉). Wow! The images covered range from illustrative additions, to creative tutorials, to charts that carry the message of the blog post, so it provides great set of examples on how to consider writing alt text in different situations.

That’s not even counting the many questions, discussions, and ephiphanies that happened during out work time. Learning can’t be captured as easily by a number, but a taste of our less quantifiable wins can be found on the workshop recording.

Want to learn more?#

If you want to further explore the experience and relive the joy, you can find resources on the event agenda, discussions on the working pull request, and the final steps needed to make change on the contributing pull request.

But wait, there’s more! While the community made great progress on improving the blog, the work to add or improve alt text on Scientific Python’s blog, website, and documentation is ongoing. You can continue these efforts by

• Contributing as an individual! There’s no reason you can’t write some image descriptions for your favorite blog post to make it even better. (👀 This is a great excuse to find a new favorite blog post.)
• Contributing as a group! Collect your friends, co-workers, neighbors, local book club attendees, or others to team up and write alt text. (Help for duplicating the process of our group PR can be found on the draft event documentation.)
• Staying in touch for announcements of future contributing events on the Scientific Python Twitter.

This image description event has been run across multiple open-source projects in the scientific computing ecosystem. Reach out via issue if you are interested in running a similar event on a project you are part of. ❤️

Create educational content for the Scientific Python Blog#

About your organization#

With an extensive and high-quality ecosystem of libraries, scientific Python has emerged as the leading platform for data analysis. This ecosystem is sustained largely by volunteers working on independent projects with separate mailing lists, websites, roadmaps, documentation, engineering and packaging solutions, and governance structures.

The Scientific Python project aims to better coordinate the ecosystem and prepare the software projects in this ecosystem for the next decade of data science.

About your project#

Your project’s problem#

There is no shortage of blog posts around the web about how to use and explore different packages in the scientific Python ecosystem. However, some of it is outdated or incomplete, and many times doesn’t follow the best practices that would be advocated for by the maintainers of these packages.

In addition, we would like to create a central, community-driven location where Scientific Python projects can make announcements and share information.

Our project aims to be the definitive community blog—for people looking to make use of these libraries in education, research and industry, contribute to them, or maintain them—written, reviewed, and approved by the community of developers and users.

While our core projects (NumPy, SciPy, Matplotlib, scikit-image, NetworkX, etc.) will be regularly contributing content, we also would like to increase the number of contributors by providing support to newer members to generate high-quality, peer-reviewed blog posts.

Your project’s scope#

Our goal is to populate the https://blog.scientific-python.org/ website with high-quality content, reviewed and approved by the maintainers of the libraries in the ecosystem. The main goal of these documents is to centralize information relevant to all (or most) projects in the ecosystem, at the reduced cost of being maintained in one place.

This project aims to:

• Create content for the https://blog.scientific-python.org/ website

To ensure this project is successful, it is recommended that the technical writer has some familiarity with at least a few of Scientific Python’s core projects.

Measuring your project’s success#

We would consider the project successful if:

• At least 3 blog posts were published on blog.scientific-python.org, by each of the technical writers.
• Improved submission and review guide

Timeline#

We anticipate the project to be developed over six months including onboarding five technical writers, reviewing existing material, developing blog post ideas with the project mentors and blog editorial board, writing and revising the blog posts, as well as providing feedback on the submission and review process.

Project budget#

Additional information#

The Scientific Python project is a new initiative, and this is our first time participating in Google Season of Docs. However, both Jarrod Millman and Ross Barnowski are established members of the Python community, with a vast collective experience in mentoring, managing and maintaining large open source projects.

Jarrod cofounded the Neuroimaging in Python project. He was the NumPy and SciPy release manager from 2007 to 2009. He cofounded NumFOCUS and served on its board from 2011 to 2015. Currently, he is the release manager of NetworkX and cofounder of the Scientific Python project.

Both mentors Jarrod and Ross have mentored many new contributors on multiple projects including NumPy, SciPy, and NetworkX. Ross has served as a co-mentor for three former GSoD students on the NumPy project, largely related to generating new content for tutorials, as well as refactoring existing user documentation.

Links:

• https://scientific-python.org/
• https://blog.scientific-python.org/
• https://github.com/scientific-python/