This applies across all Mesa repos (mesa, mesa-examples, mesa-llm).

The situation

Mesa is maintained by a small group of volunteers. We want GSoC to be a genuinely valuable learning experience for you, and we want your contributions to make Mesa better. But we have limited capacity — every PR we review is time we're not spending on development, mentoring, or our own lives.

This is an experiment for us too. We're trying to find a process that maximizes your learning, produces quality contributions, and is sustainable for our maintainers. We need your help making it work. The single most important thing you can do: invest in understanding before you invest in PRs.

A few well-understood contributions are worth far more than many shallow ones — for you and for us. When you deeply understand a problem, your PR is easier to review, more likely to be merged, and you learn more from the process. When you don't, the review becomes a back-and-forth that drains everyone's time and energy.

See also the Google Summer of Code 2026 guide.

Step 1: Build models first

Before opening PRs, fork the GSoC-learning-space template repo and start building models. This is the foundation for everything else. See the template README for why this matters and how to use it.

Your learning repo is not graded and maintainers won't monitor it. But when you open a PR, you'll link to it, and it will be obvious whether you've done the work.

Step 2: Engage in discussions

Read open issues, discussions, and recent release notes. Before working on something, make sure there's agreement that it's worth doing — comment on the issue or discussion, or open a new one. Don't start coding before direction is clear. See our contributing guide for when to open what.

If you're unsure whether something is a good use of your time, ask. We'd much rather spend five minutes aligning on an idea than three hours reviewing a PR that goes in the wrong direction.

Step 3: PR requirements

Once you've built understanding and aligned on what to work on, here's what each PR needs.

Use the normal PR template

Fill out the existing bugfix or feature PR template as usual. Don't skip sections.

Add the GSoC checklist below your PR description

Copy the block below and paste it at the bottom of your PR description. Fill in the text fields and check the boxes.

---

## GSoC contributor checklist

### Context & motivation
<!-- Why are you addressing this problem? How did you find it? What interests you about it? -->
<!-- ⚠️ Write this yourself. Do not use LLM/AI tools for this section — we want to hear your voice and your understanding. -->



### What I learned
<!-- What did you specifically learn while working on this? What was harder or different than you expected? -->
<!-- ⚠️ Write this yourself. Do not use LLM/AI tools for this section. -->



### Learning repo
<!-- Link to your fork of GSoC-learning-space, and to any specific models relevant to this PR -->
🔗 My learning repo: <!-- e.g., https://github.com/yourname/GSoC-learning-space-->
🔗 Relevant model(s): <!-- e.g., link to a specific model folder if applicable -->

### Readiness checks
- [ ] This PR addresses an agreed-upon problem (linked issue or discussion with maintainer approval), **or** is a small/trivial fix
- [ ] I have read the [contributing guide](https://github.com/mesa/mesa/blob/main/CONTRIBUTING.md) and [deprecation policy](https://github.com/mesa/mesa/blob/main/CONTRIBUTING.md#deprecation-policy)
- [ ] I have performed a self-review: I reviewed my own PR as if I were a reviewer and left comments on anything that needs explanation
- [ ] Another GSoC contributor has reviewed this PR: @<!-- tag reviewer here -->
- [ ] Tests pass locally (`pytest --cov=mesa tests/`)
- [ ] Code is formatted (`ruff check . --fix`)
- [ ] If applicable: documentation, examples, and/or migration guide are updated

Self-review (required)

Before requesting maintainer review, go through your own PR diff and leave review comments. Walk through the changes as if you were seeing them for the first time. This isn't busywork — re-reading your own code with fresh eyes is one of the fastest ways to deepen your understanding of what you actually built and why. It also catches obvious issues before a maintainer has to.

Peer review (required)

Get at least one other GSoC contributor to review your PR before tagging a maintainer. Tag them in the checklist above. Reading someone else's code — figuring out what it does, whether it makes sense, how it fits into Mesa — is one of the best ways to learn. You'll often learn more reviewing a PR than writing one. The review doesn't need to be exhaustive. Start at a high-level (does it solve a problem, does it solve it in the right way) before reviewing the details.

When will maintainers review?

Maintainers will review your PR once:

1. The normal PR template is filled out completely
2. The GSoC checklist is added and filled in
3. Your self-review is posted
4. At least one GSoC peer review is done

PRs missing these steps will be asked to complete them before maintainer review proceeds.

How you can help us help you

• Quality over quantity. One thoughtful PR that solves a real problem is better than five superficial ones.
• Align before you build. Check that there's agreement on the problem and approach before writing code.
• Be honest about what you know and don't know. We can help you learn, but only if you're upfront about where you are.
• Review each other's work. This helps everyone — the reviewer learns, the author gets feedback, and maintainers get PRs that are closer to ready.
• If something about this process isn't working, tell us. This is an experiment. We'll adjust based on what we learn.

Questions?

Ask in Matrix or comment below.