❤️ Blitz Maintainers

Aside from the core team, there are two levels of maintainers, described below.

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 impact.

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

Retiring

Maintainers may retire from their role at any time without any shame or guilt. Simply let a core team member know!

⚠️ Fundamentals

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 appreciated.

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 it soon
  • 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

Resources

• How to Be Helpful Online
• How to Start Reviewing Code

Monitoring 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.

Issue Triage

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

Actions

1. Add tags:
   • Add a status/* tag
   • Add a kind/* tag
   • Add a scope/* tag
   • 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?

Actions

1. Kindly request any changes if needed
2. 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.

1. Ensure the PR'ed code fully works as intended and that there are no regressions in related code
   1. If not fully covered by automated tests, you need to pull down the code locally and manually verify everything (the GitHub CLI helps with this!)
2. During squash & merge:
   1. Change the commit title to be public friendly - this exact text will go in the release notes
   2. 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