Added generic maintainers and admins responsibilities. #11
Conversation
|
@CEHENKLE care to take a look? |
dblock
force-pushed
the
maintainers
branch
5 times, most recently
from
0ea27d2 to
f45ebe6
Compare
dblock
changed the title
Signed-off-by: dblock <[email protected]>
dblock
force-pushed
the
maintainers
branch
2 times, most recently
from
0aa0722 to
9ec23de
Compare
Signed-off-by: dblock <[email protected]>
Signed-off-by: dblock <[email protected]>
MAINTAINERS.md
Outdated
| Prioritize security above-all. For example, maintainer's Github keys must be password protected securely and any reported security vulnerabilities are addressed before features or bugs. | ||
| ### Prioritize Security | ||
|
|
||
| Prioritize security above-all, including your own. Maintainer's Github keys must be password protected securely and any reported security vulnerabilities are addressed before features or bugs. |
There was a problem hiding this comment.
Prioritize security above-all, including your own.
That reads a little oddly. It makes it sound like you want maintainers to risk life and limb, which is not, I think, our intention :)
There was a problem hiding this comment.
:)
Changing to "security is your number one priority" to take from the AWS playbook.
| @@ -27,16 +29,25 @@ Review pull requests regularly, comment, suggest, reject, merge and close. Accep | |||
|
|
|||
| ### Triage Open Issues | |||
|
|
|||
| Review issues regularly and triage by labelling issues. For example, add "help wanted" to good issues for new community members. Request for more information from a submitter if an issue is not clear. Create new labels as needed by the project. | |||
| 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.
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.
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.
|
|
||
| ### Maintain Overall Health of the Repo | ||
|
|
||
| Keep the main branch at production quality at all times. | ||
| 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.
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.
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.
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.
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.
| | Henri Yandell | [hyandell](https://github.com/hyandell) | Amazon | | ||
| | Admin | GitHub ID | Affiliation | | ||
| | --------------- | --------------------------------------- | ----------- | | ||
| | Henri Yandell | [hyandell](https://github.com/hyandell) | Amazon | | ||
|
|
||
| ## Admin Responsibilities |
Signed-off-by: dblock <[email protected]>
|
@CEHENKLE I pushed a change for the security sentences. Can you please suggest any deltas between this and what you'd be OK merging? |
|
For HowTo's we're doing #14 |
Signed-off-by: dblock [email protected]
Description
Added generic maintainers responsibilities, inspired by opensearch-project/OpenSearch#800.
Check List
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.