Aside from the core team, there are two levels of maintainers, described
Becoming a Maintainer
We always need more level 1 maintainers! The main requirement is that you
can show empathy when communicating online. We'll train you as needed on
the other specifics. This is a great role if you have limited time,
because you can spend as much time as you have without any ongoing
responsibilities (unlike level 2)
Level 2 maintainers have a much higher responsibility, so usually you will
spend time as a level 1 maintainer before moving to level 2.
Please DM a core team member (Brandon Bayer) in Discord if you're
interested in becoming an official maintainer!
Level 1 Maintainers
Level 1 maintainers are critical for a healthy Blitz community and
project. They take a lot of burden off the core team and level 2
maintainers so they can focus on higher level things with longer term
The primary responsibilities of level 1 maintainers are:
- Being a friendly, welcoming voice for the Blitz community
- Issue triage
- Pull request triage
- Monitor and answer the Discord help channels
- Following up on assigned issues to make sure they are being worked on
- Following up on in-progress PRs to make sure they don't get stuck
- Community encouragement
- Community moderation
Level 2 Maintainers
Level 2 maintainers are the backbone of the project. They are watchdogs
over the code, ensuring code quality, correctness, and security. They also
facilitate a rapid pace of progress.
The primary responsibilities of level 2 maintainers are:
- Code ownership over specific parts of the project
- Maintaining and improving the architecture of what they own
- Final pull request reviews
- Merging pull requests
- Tracking and ensuring progress of open pull requests
Maintainers may retire from their role at any time without any shame or
guilt. Simply let a core team member know!
Maintainers are the face of the project and the front-line touch point for
the community. Therefore maintainers have the very important
responsibility of making people feel welcome, valued, understood, and
Please take time to read and understand everything outlined in this
guide on building welcoming communities
Some especially important points:
- Gratitude: immediately express gratitude when someone opens an issue
or PR. This takes effort/time and we appreciate it
- Responsiveness: during issue/PR triage, even if we can’t do a full
review right away, leave a comment thanking them and saying we’ll review
- Understanding: it's critical to ensure you understand exactly what
someone is saying before you respond. Ask plenty of questions if needed.
It's very bad if someone has to reply to your response and say "actually
I was asking about X"
- In fact, at least one question is almost always required before you
can respond appropriately — whether in GitHub or in Discord
If a bug report:
- Does it have enough information? Versions? Logs? Some way to reproduce?
- Has this already been fixed in a previous release?
- Is there already an existing issue for this?
If a feature/change request:
- Is it clear what the request is and what the benefit will be?
- Is this an obvious win for Blitz? Then accept it
- If not obvious, then pull in a core team member or level 2 maintainer
for more review
- Add tags:
- Add a
- Add a
- Add a
- Add a good first/second issue tag if appropriate
Pull Request Triage
- Are the changes covered by tests?
- Do the changes look ok? Make sure there's no obvious issues
- Kindly request any changes if needed
- Else add a GitHub approval so that level 2 maintainers know it's
already had an initial review
Final PR Review & Merging (Level 2 maintainers)
As a level 2 maintainer, it is your responsibility to make sure broken
code and regressions never reach the canary branch.
- Ensure the PR'ed code fully works as intended and that there are no
regressions in related code
- If not fully covered by automated tests, you need to pull down the
code locally and manually verify everything (the GitHub CLI helps
- During squash & merge:
- Change the commit title to be public friendly - this exact text will
go in the release notes
- Add the commit type in the description, in parenthesis like
(patch). Commit types:
major - major breaking change
minor - minor feature addition
patch - patches, bug fixes, perf improvements, etc
newapp - changes to the new app template
recipe - changes to a Blitz recipe
example - change to an example app
meta - internal meta change related to the Blitz repo/project