GSoC 2026: Interest in DevOps improvement project

[ellatso]

Hi! I'm interested in the DevOps improvement project for GSoC 2026.

I've been contributing to arviz-plots recently (PR #433, user testing on #236, PR #2534(waiting for CI approval)). I have experience with pre-commit and pytest, and I'm eager to learn more about tox, mypy, and docstub.

Is there a good first issue related to DevOps/typing/testing that I could work on to get started in this direction?
Thanks!

[OriolAbril]

Thanks for reaching out!

We are a bit swamped with work in general which means for example reviews and issue coments can take a while. It would be very helpful and a good way to familiarize with the repos and workflows to go over open issues related to DevOps and see if they are still relevant. For example, quickly skimming through the list inarviz-base I can see: arviz-devs/arviz-base#85 which can probably be addressed and fixed now or arviz-devs/arviz-base#107 which will now be mostly outdated after these couple PRs but probably not fully addressed. Something similar is also bound to happen in arviz-stats and arviz-plots.

[ellatso]

Thanks for the reply,
I can help by triaging the open DevOps-related issues across arviz-base, arviz-stats, and arviz-plots to check what’s still relevant and what’s outdated after recent PRs.

I'll Start with arviz-base#85 and arviz-base#107, For each issue I’ll report back with: current status on main, minimal repro (commands), and a suggested next step (close / update / small PR), If something looks like a quick win, I can open a focused PR to fix it

I’ll post updates directly on the corresponding issues so it’s easy to track.

[ellatso]

Hi @OriolAbril — thanks again for the guidance.

I took a pass over the open DevOps issues in arviz-base (incl. #85/#107) and it looks like most of them are already being handled, so I’m starting to draft my GSoC proposal for the DevOps project.

Here’s the plan I’m leaning towards for a 350h scope:

Core deliverables (pick 2–3 to focus):

• Standardize mypy + pre-commit configs across arviz-base / arviz-stats / arviz-plots
• Expand/align docstub type hints (bring arviz-stats + arviz-plots closer to arviz-base)
• Improve CI reliability: warnings-as-errors (where reasonable) + fill obvious test gaps

Optional (if you think it’s valuable):

• Add scientific-python-nightly / nightly dependency testing
• Make tox envs more consistent across repos

A couple quick questions so I don’t over/under-scope:

1. Is this scope appropriate for a 350h project, or should I narrow/expand focus?
2. Are there specific areas that are higher priority for the team?
3. Should I start with one repository (e.g., arviz-stats) and then extend to others?

Happy to take on another small task if there’s a particular area you’d like me to get familiar with first. Thanks!

[OriolAbril]

mypy will probably give a lot of work, even arviz-base which already has some checks for it is using a very minimal setting with a lot of ignores, but removing those will probably mean many changes in tests and the library itself. For arviz-stats and plots we'll probably see something similar, even once we have type hints through docstub, running the library and test suite through mypy will trigger many warnings and errors. Depending on how many we want to keep and how many to ignore we can probably define how much effort goes into library and test tweaks.

docstub will probably be less work I think because we generally have good docstrings but still, many parameters might need small fixes in their type info for things to parse correctly.

warnings as errors is proving to be extremely simple. Filling test gaps will be much more interesting and much more work too. The backend interface functions in arviz-plots for example have no direct testing basically, and the test suite in arviz-stats is a bit chaotic so it is not very clear what is lacking, but there are probably relevant gaps that need fixing.

testing with nightlies is also very simple to set up (by itself and it is already configured in some of the repos so it is basically copy pasting a dozen of lines in tox.ini), the only work that could come from that is having to fix either tests or the library due to deprecation warnings, but I think this has low probability of happening.

making tox more consistent should also be low hanging fruit, there might be some repos missing some more niche tasks like livedocs but in general I think they are in good shape.

---

I think you can define a 350h project from the main 3 points you identified. Regarding the order of work I don't think it will matter much as long as you get a good idea of the different things available across repositories to define the tasks.

[ellatso]

Thank you so much for the detailed breakdown! This is really helpful for planning.
I'll restructure my proposal to start with the quick wins (warnings as errors, nightlies, tox consistency) and then move to the more substantial work (docstub, test gaps, mypy) based on your feedback.