Interest in GSoC 2026 - DevOps improvement and standardization

[AAlexxis222]

Hi, I'm a second-year AI Engineering student interested in the DevOps improvement and standardization project for GSoC 2026.

I've been contributing to the ArviZ ecosystem recently. I standardized the call signatures across all 34 plotting functions in arviz-plots (PR #419, merged), and I have an open PR in pymc-extras migrating the codebase from InferenceData to DataTree for ArviZ 1.0 compatibility (PR #642).

From this work I got familiar with ruff, pre-commit, and the conventions across the repositories. I've also looked at the differences in DevOps tooling between arviz-base and the other repos and I can see the gaps mentioned in the project description.

I'd like to focus the proposal on bringing type hints via docstub and mypy checks to arviz-plots and arviz-base first, as those are the repos I know best. Would that be a reasonable starting point, or do you have a different priority in mind?

Thanks!

[OriolAbril]

Thanks for reaching out!

That sounds good as a starting point but do note that we would like to have a large project (350h). arviz-base already has docstub configured and a minimal mypy check, so work on that would only be improving mypy settings and refining the type hints. Estimating how long things will take is a hard task, but I think you'll need more tasks to fill a large project proposal.

[AAlexxis222]

Thanks for the clarification! I've done a more thorough audit of the repositories and I think there's enough work across the ecosystem to fill 350h comfortably. Here's what I found:

arviz-plots: missing docstub entirely, no nightlies testing environment, mypy hook absent from pre-commit, and still using outdated hooks (isort, black, pylint) instead of ruff.

arviz (metapackage): missing mypy configuration entirely, no docstub, no nightlies testing.

arviz-stats: missing docstub and mypy pre-commit hook, and warnings are not treated as errors in pytest (filterwarnings = ["error"] is absent).

Beyond adding the missing tools, making the actual code pass these new checks will take significant time across all repos. Would this scope sound reasonable for a 350h proposal?

[OriolAbril]

yes, I think things are in good shape generally but we do expect a significant part of the work to be related to fixing things for the newly added checks to pass not only to work on adding the checks themselves.

In general you can exclude the metapackage from the project though. It is a single file and defines no functions or classes so mypy, docstub or nightlies testing would be either redundant because we have them in the other 3 or directly useless.