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 |
---|---|---|
Junqiu Lei | junqiu-lei | Amazon |
Shivam Dhar | Shivamdhar | Amazon |
Vamshi Vijay Nakkirtha | vamshin | Amazon |
Vijayan Balasubramanian | VijayanB | 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 DCO, dco.yml. Example pull request.
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.
Make sure the repo has a well-written, accurate, and complete description. See opensearch-project/.github#38 for some helpful tips to describe your repo.