Please treat this content as a living document.
This is 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 |
|---|---|---|
| Richard Davison | richarddavison | Amazon |
| Nik Pinski | nikp | Amazon |
| Harold Sun | bnusunny | Amazon |
| Iain Maitland | imaitland | Amazon |
WORK IN PROGRESS
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.
Be aware of recurring ambiguous situations and document them to help your fellow maintainers.
Model the behavior set forward by the Code of Conduct and raise any violations to other maintainers and admins. There could be unusual circumstances where inappropriate behavior does not immediately fall within the Code of Conduct.
These might be nuanced and should be handled with extra care - when in doubt, do not engage and reach out 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 incoming pull requests.
PRs are labeled based on file changes and semantic title. Pay attention to whether labels reflect the current state of the PR and correct accordingly.
Use and enforce semantic versioning pull request titles, as these will be used for CHANGELOG and Release notes - make sure they communicate their intent at the human level.
See Common scenarios section for additional guidance.
Manage labels, review issues regularly, and create new labels as needed by the project. Remove triage label when you're able to confirm the validity of a request, a bug can be reproduced, etc. Give priority to the original author for implementation, unless it is a sensitive task that is best handled by maintainers.
Make sure issues are assigned to our board of activities
Use our labels to signal good first issues to new community members, and to set expectation that this might need additional feedback from the author, other customers, experienced community members and/or maintainers.
WORK IN PROGRESS