MAINTAINING.md

[CEHENKLE]

I mentioned this in another issue, but I wanted to capture some thoughts on the 'what' of maintaining. I'm thinking of this as a sister document to "CONTRIBUTING.md" that explains tactically what maintainers should be doing.

To start the conversation, here are a couple of sections I'd find useful:

• Branching (collaborative feature branching- when to branch)
• Labeling (We should have a list of the labels and when to use them)
• What should should you look for in a review
• Number of reviews needed before committing
• Documentation (how do we make sure it's happening?)
• Backporting
• Release Process (when and where do we notify people)

What else would be useful?

Thanks,
/C

[dblock]

I think the release process should be a separate RELEASING.md, e.g. https://github.com/ruby-grape/grape/blob/master/RELEASING.md

[setiah]

• Labeling (We should have a list of the labels and when to use them)
• What should should you look for in a review
• Number of reviews needed before committing
• Documentation (how do we make sure it's happening?)
• Backporting

We should document what "a PR lifecycle" should look like somewhere. This would also capture some the questions you've raised. I see a few PRs out there without corresponding issues. Some Initial thoughts on the process -

1. First, the developer should create a Github issue explaining the problem, steps to reproduce, potential fix(es).
2. Then, create PR and tag the created issue in the PR description
3. Next, ,aintainers label the PR correctly (if not already done), review it and decide if there is need for another pair of eyes on the PR. e.g. Some PRs may warrant someone from an area of expertise to review it. It could also be based on complexity, security, or breaking changes.
4. If all looks good, maintainer merges the PR. If the PR changes some behavior that should be added/updated in end user documentation, the maintainer should add documentation pending label to the issue and keep it open. Remove the label once documentation PR is added and merged.
5. Similarly if the change requires backporting to previous branches, maintainer can label the issue with backport pending and request PR owner to open another PR for backporting. Remove the label once the backporting is done.
6. Close the issue after all pending labels have been closed.

[CEHENKLE]

I think the release process should be a separate RELEASING.md, e.g. https://github.com/ruby-grape/grape/blob/master/RELEASING.md

Hm....why don't we see how large that section becomes, and then we'll see if it merits its own doc? It may not even belong in OpenSearch (it may belong in the build repo).

To be clear, I'm not opposed, I'd just rather start in one doc and then break things out than have a bunch of docs each with one paragraph in them :)

[stockholmux]

What, if any, of this is project wide vs unique to OpenSearch proper? Personally, I like consistent processes across repos in an org.

[dblock]

What, if any, of this is project wide vs unique to OpenSearch proper? Personally, I like consistent processes across repos in an org.

Might belong in a .meta repo? Or we could rename OpenSearch to opensearch-min and create OpenSearch ;)

[AmiStrn]

I think a meta repo referenced by the readme's and website would be good.
Also, would this be a hood place to add some best practices for PR cadence and review comments?

[dblock]

There was a discussion about where to put org-wide things in #532 and I suggested opensearch.org, aka https://github.com/opensearch-project/project-website (also see opensearch-project/project-website#44). WDYT?

[CEHENKLE]

What, if any, of this is project wide vs unique to OpenSearch proper? Personally, I like consistent processes across repos in an org.

The approaching I'm taking for "stuff like this" is that I want to get it working in the main OpenSearch repo, then move to Dashboards, and then roll it out more widely to the rest of the plugins. I want to make sure we've put some weight on them before I push them out widely only because it's faster to iterate (and make things better) with one repo rather than 20+ :)

[dblock]

Should we close this now that we have https://github.com/opensearch-project/.github/blob/main/MAINTAINERS.md?

[stockholmux]

I'm with @dblock - seems like it's obsolete with MAINTAINERS.md

[peternied]

• I feel like this was largely addressed by Added generic maintainers and admins responsibilities. .github#11 and then iterated on in the .github project - I'm going to close this out. Please feel free to reopen if there is something missed from this issue, thansk!