Increment Version to 1.5.0 and add new guidelines to MAINTAINERS_GUIDE.md and CONTRIBUTING.md

CONTRIBUTING.md

@@ -90,10 +90,10 @@ 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 will review all contributions as quickly as possible. 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 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.
 
 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.
 
 If we accept the PR, a [maintainer](MAINTAINERS.md) will merge your change and usually take care of backporting it to appropriate branches ourselves.
 
-If we reject the PR, we will close the pull request with a comment explaining why. This decision isn't always final: if you feel we have misunderstood your intended change or otherwise think that we should reconsider then please continue the conversation with a comment on the PR and we'll do our best to address any further points you raise.
+If we reject the PR, we will close the pull request with a comment explaining why. This decision isn't always final: if you feel we have misunderstood your intended change or otherwise think that we should reconsider then please continue the conversation with a comment on the PR and we'll do our best to address any further points you raise.

MAINTAINERS_GUIDE.md

@@ -14,6 +14,9 @@ Maintainers should create new issues as needed.
 ### Review Pull Requests
 
 * 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.
 
 ### 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>)

RELEASE_GUIDE.md

@@ -63,7 +63,8 @@ NOTE: The version number below is in semantic format, for instance, `1.2.0`.
 
 3. Maintainer needs to comment on Automated Issue: Once the maintainer has commented, the workflow uploads OSB to PyPI and OSB Docker Hub Staging account. Once the workflows are finished publishing OSB to PyPI and OSB Docker Hub staging account, the maintainer who pushed the tag should visit both PyPI and Docker Hub staging to perform the following steps to verify that the artifacts have been properly uploaded.
     1. Check the progress of release here in the Jenkins console:: https://build.ci.opensearch.org/job/opensearch-benchmark-release/
-        1. If failed, inspect the logs.
+        1. For a more detailed look at what's happening, you can take the Build ID (which is the number highlighted in blue beneath "Stage View") and substitute it into this URL: https://build.ci.opensearch.org/blue/organizations/jenkins/opensearch-benchmark-release/detail/opensearch-benchmark-release/<Build ID>/pipeline/
+ 	 2. If failed, inspect the logs.
 
     2. Verify PyPI:
         1. Download the OSB distribution build from PyPI: https://pypi.org/project/opensearch-benchmark/#files.  This is a `wheel` file with the extension `.whl`.
@@ -98,7 +99,6 @@ NOTE: The version number below is in semantic format, for instance, `1.2.0`.
 
 What’s changed?
   * Read here: https://github.com/opensearch-project/opensearch-benchmark/releases/tag/1.2.0
-  * This version includes several enhancements and fixes contributed by OSCI participants
   * Documentation: https://opensearch.org/docs/latest/benchmark
 Wow! Where can I get this?
   * PyPI: https://pypi.org/project/opensearch-benchmark

version.txt

@@ -1 +1 @@
-1.4.0
+1.5.0