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
- Our goal is to respond to all issues and PRs within 2 days, but
ideally within 1 day.
- 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
- We want every single question to get a response, ideally within a day,
or 2 at max. But this doesn't mean you have to solve their problem. For
example, if they ask about some random library you know nothing about,
you can respond saying you aren't familiar with that, but that they
could try looking for examples/docs on using it with nextjs, since the
integration would the same.
- Ensure threads are used as much as possible to keep channels organized.
Even if there are a few messages about a topic in the main channel and
the issue/question is not resolved, go ahead and create a thread and
respond in the thread.
- If someone reports something that's likely a bug, kindly ask them to
open an issue on Github
- If someone requests a feature or change, kindly ask them to open a
feature request issue on Github
- If you notice some type of DX issue or opportunity for improvement in
any conversation, please open an issue on Github for this. Making lots
of tiny improvements over the long has compounding returns
- If someone asks a question about something that either doesn't have docs
or isn't documented well, then take a minute to go add the docs for
that. And then paste a link to the new docs you added.
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
- If applicable, has a PR been opened to update the docs?
- 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