This document explains who the maintainers are (see below), what they do in this repo, and how they should be doing it. If you're interested in contributing, see CONTRIBUTING.
| Maintainer | GitHub ID | Affiliation |
|---|---|---|
| Aleksei Atavin | axeoman | Aiven |
| Denis Zalevskiy | deztructor | Aiven |
| Rushi Agrawal | rushiagr | Amazon |
| Shephali Mittal | Shephalimittal | Amazon |
Maintainers are active and visible members of the community, and have maintain-level permissions on a repository. Use those privileges to serve the community and evolve code as follows.
Model the behavior set forward by the Code of Conduct and raise any violations to other maintainers and admins.
Security is your number one priority. Maintainer's Github keys must be password protected securely and any reported security vulnerabilities are addressed before features or bugs.
Note that this repository is monitored and supported 24/7 by Amazon Security, see Reporting a Vulnerability for details.
Review pull requests regularly, comment, suggest, reject, merge and close. Accept only high quality pull-requests. Provide code reviews and guidance on incomming pull requests. Don't let PRs be stale and do your best to be helpful to contributors.
Manage labels, review issues regularly, and triage by labelling them.
All repositories in this organization have a standard set of labels, including bug, documentation, duplicate, enhancement, good first issue, help wanted, blocker, invalid, question, wontfix, and untriaged, along with release labels, such as v1.0.0, v1.1.0 and v2.0.0, and backport.
Use labels to target an issue or a PR for a given release, add help wanted to good issues for new community members, and blocker for issues that scare you or need immediate attention. Request for more information from a submitter if an issue is not clear. Create new labels as needed by the project.
The Github workflow in backport.yml creates backport PRs automatically when the original PR with an appropriate label backport <backport-branch-name> is merged to main. To backport a PR to 1.x, add a label backport 1.x to the PR, once this PR is merged to main, the workflow will create a backport PR to the 1.x branch.
Respond to enhancement requests, and forum posts. Allocate time to reviewing and commenting on issues and conversations as they come in.
Keep the main branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches.
Use and enforce semantic versioning and do not let breaking changes be made outside of major releases.
Make frequent project releases to the community.
Assist, add, and remove MAINTAINERS. Exercise good judgement, and propose high quality contributors to become co-maintainers.