opensearch-project / opensearch-project/.github
Document code reviews best practices in MAINTAINERS
Open
Nobody has claimed this yet.
documentation
good first issue
help wanted
- Dominant language
- No language data
- Stars
- 41
- Forks
- 74
- Avg merge
- 3d 19h
- Merged PRs (30d)
- 1
Description
Add to MAINTAINERS
- What is the commit process from the maintainer POV? (e.g. puck-up any of the open PRs, is there an SLA?)
- What's specific about PRs in OpenSearch org (e.g. generally require 1 approval, merged by the contributor if they have contributor rights)?
- What do maintainers look for in PRs (e.g. tests)?
- What's the merge bar? (e.g. code is an improvement over what we have vs. perfect)
- What to look for in a PR? (e.g. ensure quality or security)
- How do we expect maintainers to behave? (e.g. be clear about what's a must have, should have or nice to have, and lead with empathy)
- Links to external resources about doing excellent code reviews.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.