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.
Initially, GitHub maintainers will be from within AWS: As we progress, we'll add additional external maintainers. Guidelines for adding external maintainers will be published. Current list of maintainers
| Maintainer | GitHub ID | Affiliation |
|---|---|---|
| Zane Li | zli236 | Amazon |
| Huansong Fu | huansong | Amazon |
| Kuntal Ghosh | slightst | Amazon |
| Di Wu | macwoody | Amazon |
| Korry Douglas | korryd | Amazon |
| Suprio Pal | suprio-amzn | Amazon |
| Jim Mlodgenski | jim-mlodgenski | Amazon |
| Jim Nasby | nasbyj | Amazon |
| Jim Finnerty | JimFinnerty | Amazon |
| Rob VErschoor | rcv-aws | Amazon |
| Simon Lightstone | slightst | Amazon |
| Richard Waymire | waymire | Amazon |
| Gopinath Pai | gopinathpai | 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, v2.0.0, patch, 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.
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.
Add integration checks that validate pull requests and pushes to ease the burden on Pull Request reviewers.
Validates pull requests commits are all signed with the doc, doc.yml.
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.