-
-
Notifications
You must be signed in to change notification settings - Fork 485
GSoC 2026 projects
ArviZ is a project dedicated to promoting and building tools for exploratory analysis of Bayesian models. It currently has a Python and a Julia interface. All projects listed below are for the Python interface.
ArviZ aims to seamlessly integrate with established probabilistic programming languages like CmdStanPy, PyMC, Turing, Soss, emcee, and NumPyro, and to be easily integrated with novel or bespoke Bayesian analyses. Where the probabilistic programming languages aim to make it easy to build and solve Bayesian models, the ArviZ libraries aim to make it easy to process and analyze the results from those Bayesian models.
The timeline of the GSoC internships is available at the GSoC website
First and foremost, GSoC is NOT a code-for-hire program. Your results will matter, but they don't matter as much as your journey and learnings. You will be working on a completely new to you and complex codebase, which means you will make mistakes. The mistakes themselves will never be an issue; what is a grave issue is repeating the same mistakes over and over because it shows you are not learning.
You can use LLMs if you so choose, but we strongly discourage relying on them. Again, the main goal of the program is learning, which can be slowed or even completely hindered when uncritically relying on LLMs. LLMs tend to hinder learning when they replace your own reasoning rather than support it. You are the one responsible for any code you write/generate, so you should be able to fully understand it. If you can not explain, debug, or modify it, then you are not fully understanding it. LLMs can be helpful when used reflectively.
Don't use them to generate what you want to pass as "your ideas"; use them to critique your own ideas, ask for help when you need to clarify or polish docstrings, or help identify missing tests and edge cases. Do not trust their output without careful and extensive review; use LLMs' output as suggestions, iterate and reflect over them to identify better choices. LLMs often make mistakes, hallucinate, and suggest suboptimal or incorrect solutions. They have a tendency to be too verbose, more text than needed, more code than needed, more tests than needed, etc. They also have a tendency to reaffirm whatever you tell them, even if completely wrong.
Moreover, the context of the program is open source, where communication and trust are key. Asking your mentors and other maintainers to read an "LLM polished" PR description spanning 4 paragraphs instead of your initial 3 bullet points, which contain the same information, will only slow down the reviews you'll get. Don't do that, write your own PR messages. The results are likely going to be shorter, easier to follow, less unnecessarily verbose, and more useful, so we will have an easier time reviewing them. Don't treat communication as a burden; respect other people. Last but not least, we have also seen many cases where the PR description does not match the actual changes, which pulverizes any trust you might have already gained.
The evaluation of applicants generally depends on two things: 1) the interaction with the team and the community in issues and PRs, and 2) the proposal itself. In later stages, and depending on the circumstances, we might also ask for a short interview.
When looking at participation in issues and PRs the main things we care about are: you have gone through the contributing guide and made an effort to follow it; you are receptive to review comments and address them; you progressively learn about the libraries, their state, structure and conventions; you are aware about your own knowledge and limitations and ask questions when necessary. On the other hand, if the PR is directly related to the project plays no role whatsoever.
When looking at the proposals, the main things we look at are: the coherence of the plan and its fit with the current state of the library; the timeline structure and organization. We know that estimating how long something will take is extremely hard. However, even if the timings are not absolutely accurate the timeline still provides very useful information such as dependencies between different tasks or a complexity grading of the proposed tasks.
- ArviZ code of conduct
-
ArviZ contributing guide, and some highlighted pages within it:
- Contributing code via PRs
- PR step by step tutorial
- PR checklist
- Issue triaging (due to the recent refactor a large number of issues are outdated, this page can help check if an issue is still relevant)
Below is a list of possible topics for your GSoC project. We are also open to other topics. Contact us on GitHub discussions (we won't accept proposals on topics outside this idea list from people who haven't contacted us before).
When writing your proposal, choose some specific tasks and make sure your proposal is adequate for the GSoC time commitment. We expect all projects to be 350h projects, if you'd like to be considered for a 175h project, you must reach out on GitHub discussions. We will not accept 175h applications from people with whom we haven't discussed their time commitments before applying.
Students should be familiar with Python, NumPy, and SciPy. They should also be able to write unit tests for the added functionality using PyTest and be able to enforce development conventions and use tox, pre-commit, pylint, ruff, mypy, and other similar tools for code style and linting.
Each project also lists some specific requirements needed to be able to complete the project. Note that some of these requirements can be learned while writing the proposal and during the community bonding period. You should feel confident to work on any project whose requirements are interesting to you, and you would like to learn about them; they are not skills that you are expected to know before writing your proposal. We aim for GSoC to provide a win-win scenario where you benefit from an inclusive and thriving environment in which to learn and the library benefits from your contributions.
Students who work on ArviZ can expect their skills to grow in
- Matplotlib, bokeh, plotly usage
- Xarray usage
- Modern DevOps tooling
With the recent refactor, we have started standardizing common development tasks using tox. We think this helps switch between the different ArviZverse repositories with minimal overhead, but the tasks in each repository have started to diverge. The packages are independent and have different needs, but we should also strive for a common baseline regarding docs, type hints, testing with stable versions, and nightlies...
At the time of writing, ArviZ-base has a more complete and extensive infrastructure and DevOps tooling than the rest of the repositories, but we'd like all of them to be more or less on par and also continue improving ArviZ-base's checks and automations. This will mean improving the tox settings, pre-commit and GitHub actions workflow,s but also (and this will probably take even more time) add fixes and improvements on the libraries themselves, their docstrings and tests so all these new checks pass.
The main peculiarity of this project is that it will have minimal Bayesian modeling knowledge involved, which is a first for an ArviZ GSoC project.
The minimum expected output is all projects having:
- type hints through docstub
- extended tests for known issues and areas lacking coverage
- tests treat warnings as errors
- tests with scientific Python nightlies
- mypy (and/or similar) static typing checks
Note that this, in principle, is not a rewrite/overhaul of the infrastructure. Tools being used in one of the repositories but not the others will be prioritized over changing the existing workflow for the repos where there is something already, and adding the new tool to the rest, too.
The main required skills for this project will be knowledge of DevOps tools like tox, pytest, pre-commit, ruff, docstub, mypy, and others, depending on the specific proposal and focus areas.
We have mentioned that, unlike past ArviZ projects, this requires minimal Bayesian modeling knowledge. On the other hand, it will also require a deeper understanding of the whole library and the interactions between the different modules and submodules. You can't restrict yourself to understanding the arviz_plots.plots and arviz_plots.visuals submodules,s which was the norm in past projects (and in many GSoC projects in general).
- Expected size: 350h
- Difficulty rating: medium
- Potential mentors: Oriol Abril and Osvaldo Martin