Revise guidelines based on comments (#496)

Signed-off-by: Ian Hoang <[email protected]>
Co-authored-by: Ian Hoang <[email protected]>

CONTRIBUTING.md

@@ -90,7 +90,11 @@ You may type this line on your own when writing your commit messages. However, i
 
 ## Review Process
 
-We deeply appreciate everyone who takes the time to make a contribution. We aim to review all contributions promptly but cannot guarantee quick turnaround times. It is essential that contributions remain accessible for an adequate duration to allow healthy engagement by community members, other than maintainers. As a reminder, [opening an issue](https://github.com/opensearch-project/OpenSearch-Benchmark/issues/new/choose) discussing your change before you make it is the best way to smooth the PR process. This will prevent a rejection because someone else is already working on the problem, or because the solution is incompatible with the architectural direction.
+We deeply appreciate everyone who takes the time to make a contribution. We aim to review all contributions promptly but cannot guarantee quick turnaround times. It can take time for appropriate analysis, verification and testing, to understand the implications and ramifications of the proposed change, and for discussion with other maintainers and developers. Furthermore, it is essential that contributions remain accessible for an adequate duration to allow healthy engagement by community members, other than maintainers.
+
+Please note that there is a code freeze imposed starting a week before every release to ensure stability of the codebase and a smooth release process. If you are interested in getting a change into the next release, please submit your change well in advance, so that it is approved and merged in prior to the deadline for the freeze. We are in the process of implementing snapshot releases, so if your change does not make a particular release, the appropriate snapshot release can be used until the next official release is cut.
+
+As a reminder, [opening an issue](https://github.com/opensearch-project/OpenSearch-Benchmark/issues/new/choose) discussing your change before you make it is the best way to smooth the PR process. This will prevent a rejection because someone else is already working on the problem, or because the solution is incompatible with the architectural direction.
 
 During the PR process, expect that there will be some back-and-forth. Please try to respond to comments in a timely fashion, and if you don't wish to continue with the PR, let us know. If a PR takes too many iterations for its complexity or size, we may reject it. Additionally, if you stop responding we may close the PR as abandoned. In either case, if you feel this was done in error, please add a comment on the PR.
 

MAINTAINERS_GUIDE.md

@@ -15,8 +15,8 @@ Maintainers should create new issues as needed.
 
 * Maintainers should regularly review the backlog of pull requests. Pull requests only require one maintainer to approve. The maintainer reviewing the PRs should be a subject matter expert (understand the context and purpose of the PR) and drive best practices in clean code and architecture.
 * Only use GitHub's squash-and-merge to merge into `main`.  Else, the backport workflow can fail -- it does not handle multiple commits as with rebases.  Merges lead to an undesired merge commit.
-* Use the `backport 3` label for every PR, since main should be the image of `3` (This is not the case now, so we'll need to fix this by hand.). Add other branch labels appropriately, almost certainly `backport 2` will also be needed.
-* Close out the backport PRs in chronological order.  If you close out a PR on `main`, please close out the branch PRs as well.
+* Use the `backport 3` label for every PR, since main should be the image of `3`, at least until OpenSearch version 3 is officially released.  Add other branch labels appropriately; almost certainly `backport 2` will also be needed, since this is the current OpenSearch version.
+* Close out the backport PRs in chronological order. If you close out a PR on `main`, please close out the associated branch PRs as well. They get generated in a few minutes by the automated backport workflow. Once they are merged in, the backport branches can be deleted as well.
 
 ### Drive Releases
 * Maintainers drive releases. A week prior to the scheduled release, maintainers should announce a code freeze in the [#performance channel](https://opensearch.slack.com/archives/C0516H8EJ7R) within the OpenSearch Slack community. For more information on the release process, see the [release guide](<https://github.com/opensearch-project/OpenSearch-Benchmark/blob/main/RELEASE_GUIDE.md>)