-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added generic maintainers and admins responsibilities. #11
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
## Overview | ||
|
||
This document explains who the admins are (see below), what they do in this repo, and how they should be doing it. If you're interested in becoming a maintainer, see [MAINTAINERS](MAINTAINERS.md). If you're interested in contributing, see [CONTRIBUTING](CONTRIBUTING.md). | ||
|
||
## Current Admins | ||
|
||
| Admin | GitHub ID | Affiliation | | ||
| --------------- | --------------------------------------- | ----------- | | ||
| Henri Yandell | [hyandell](https://github.com/hyandell) | Amazon | | ||
|
||
## Admin Responsibilities | ||
|
||
As an admin you own stewartship of the repository and its settings. Admins have [admin-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and protect the repository as follows. | ||
|
||
### Prioritize Security | ||
|
||
Security is your number one priority. Manage security keys and safeguard access to the repository. | ||
|
||
Note that this repository is monitored and supported 24/7 by Amazon Security, see [Reporting a Vulnerability](SECURITY.md) for details. | ||
|
||
### Enforce Code of Conduct | ||
|
||
Act on [CODE_OF_CONDUCT](CODE_OF_CONDUCT.md) violations by revoking access, and blocking malicious actors. | ||
|
||
### Adopt Organizational Best Practices | ||
|
||
Adopt organizational best practices, work in the open, and collaborate with other admins by opening issues before making process changes. Prefer consistency, and avoid diverging from practices in the opensearch-project organization. |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,53 @@ | ||
# Maintainers | ||
| Maintainer | GitHub ID | Affiliation | | ||
| --------------- | --------- | ----------- | | ||
## Overview | ||
|
||
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](CONTRIBUTING.md). | ||
|
||
## Current Maintainers | ||
|
||
| Maintainer | GitHub ID | Affiliation | | ||
| ------------------------ | --------------------------------------- | ----------- | | ||
| Henri Yandell | [hyandell](https://github.com/hyandell) | Amazon | | ||
| Daniel "dB." Doubrovkine | [dblock](https://github.com/dblock) | Amazon | | ||
|
||
## Maintainer Responsibilities | ||
|
||
Maintainers are active and visible members of the community, and have [maintain-level permissions on a repository](https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories/repository-permission-levels-for-an-organization). Use those privileges to serve the community and evolve code as follows. | ||
|
||
### Uphold Code of Conduct | ||
|
||
Model the behavior set forward by the [Code of Conduct](CODE_OF_CONDUCT.md) and raise any violations to other maintainers and admins. | ||
|
||
### Prioritize Security | ||
|
||
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](SECURITY.md) for details. | ||
|
||
### Review Pull Requests | ||
|
||
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. | ||
|
||
### Triage Open Issues | ||
|
||
Manage labels, review issues regularly, and triage by labelling them. For example, 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. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You've pulled out some of the specifics of what our labels currently are. Considering we're iterating on them, that might be smart (I'd hate to roll this out to 25+ repos and decide we wanted to change from "minor" to "trivial" or something like that.. What do you think of a putting out a separate doc with label information into .github? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It's a good idea. I think I'd like to leave this text as is for now as it says "For example, .." but as we try to standardize labels we can extract. |
||
|
||
### Be Responsive | ||
|
||
Respond to enhancement requests, and forum posts. Allocate time to reviewing and commenting on issues and conversations as they come in. | ||
|
||
### Maintain Overall Health of the Repo | ||
|
||
Keep the `main` branch at production quality at all times. Backport features as needed. Cut release branches and tags to enable future patches. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You've cut out the "how" here of how we want to do this. I think it's important that we don't assume people know what the tags should be or what the branches should be. So similar comment to above -- should the "hows" be in separate documents that live in github? I had rolled the what you do and how you do it together in my maintainer doc. But I'm not religious about keeping it that way, as long both are covered somewhere. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can't possibly spell the detailed how's in the template repository because YMMV across repos. How about accepting this as a start or suggest what additional text will bring it to par with minimum expectations? |
||
|
||
### Use Semver | ||
|
||
Use and enforce [semantic versioning](https://semver.org/) and do not let breaking changes be made outside of major releases. | ||
|
||
### Release Frequently | ||
|
||
Make frequent project releases to the community. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Again -- how? I think we need to write down how you release and when we plan to do it. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This should say "see releasing", but since it doesn't exist we can't spell it out now and I don't want to boil the ocean. |
||
|
||
### Promote Other Maintainers | ||
|
||
Assist, add, and remove [MAINTAINERS](MAINTAINERS.md). Exercise good judgement, and propose high quality contributors to become co-maintainers. | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,5 +1,3 @@ | ||
## Reporting a Vulnerability | ||
|
||
If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security | ||
via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. | ||
Please do **not** create a public GitHub issue. | ||
If you discover a potential security issue in this project we ask that you notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/) or directly via email to [email protected]. Please do **not** create a public GitHub issue. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this whole doc :)