Documentation for maintainers (#2932)

Signed-off-by: Carlisia <carlisia@vmware.com>

site/content/docs/main/code-standards.md

@@ -1,8 +1,23 @@
 ---
 title: "Code Standards"
 layout: docs
+toc: "true"
 ---
 
+## Opening PRs
+
+Some PRs do not require a CI build. Those will be changes to documentation, to the website, and any other change that doesn't involve code, such as releases, typo fixes.
+
+To bypass the CI build, use anyone of these labels (any one of them will do the job):
+- Design: any design document
+- Website: any change to the website that is not documentation
+- Documentation: documentation for releases or any markdown file in the repo 
+- changelog-not-required: use only when the PR is not addressing any of the above cases. This is for changes in the code that is not introducing any change in behavior for the software. 
+
+There is no need to use more than one label.
+
+Please add the label BEFORE creating the PR/draft. This will make the CI check pass. If you forget, it's ok: adding it after will make the CI fail, but it will still let us merge. The only minor downside is that it will have a red checkmark for failure.
+
 ## Adding a changelog
 
 Authors are expected to include a changelog file with their pull requests. The changelog file

site/content/docs/main/maintainers.md

@@ -0,0 +1,29 @@
+---
+title: "Instructions for Maintainers"
+layout: docs
+toc: "true"
+---
+
+There are some guidelines maintainers need to follow. We list them here for quick reference, especially for new maintainers. These guidelines apply to all projects in the Velero org, including the main project, the Velero Helm chart, and all other [related repositories](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#code-repositories).
+
+Please be sure to also go through the guidance under the entire [Contribute](start-contributing/) section.
+
+## Reviewing PRs
+- PRs require 2 approvals before it is mergeable.
+- The second reviewer usually merges the PR (if you notice a PR open for a while and with 2 approvals, go ahead and merge it!)
+- As you review a PR that is not yet ready to merge, please check if the "request review" needs to be refreshed for any reviewer (this is better than @mention at them)
+- Refrain from @mention other maintainers to review the PR unless it is an immediate need. All maintainers already get notified through the automated add to the "request review". If it is an urgent need, please add a helpful message as to why it is so people can properly prioritize work.
+- There is no need to manually request reviewers: after the PR is created, all maintainers will be automatically added to the list (note: feel free to remove people if they are on PTO, etc).
+- Be familiar with the [lazy consensus](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#lazy-consensus) policy for the project.
+
+## Creating a release
+Maintainers are expected to create releases for the project. We have parts of the process automated, and full [instructions](release-instructions).
+
+## Community support
+Maintainers are expected to participate in the community support rotation. We have guidelines for how we handle the [support](support-process).
+
+## Community engagement
+Maintainers for the Velero project are highly involved with the open source community. All the online community meetings for the project are listed in our [community](http://localhost:1313/community/) page.
+
+## How do I become a maintainer?
+The Velero project welcomes contributors of all kinds. We are also always on the look out for a high level of engagement from contributors and opportunities to bring in new maintainers. If this is of interest, take a look at how [adding a maintainer](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#maintainers) is decided.

site/content/docs/v1.5.0-rc.1/code-standards.md

@@ -1,8 +1,23 @@
 ---
 title: "Code Standards"
 layout: docs
+toc: "true"
 ---
 
+## Opening PRs
+
+Some PRs do not require a CI build. Those will be changes to documentation, to the website, and any other change that doesn't involve code, such as releases, typo fixes.
+
+To bypass the CI build, use anyone of these labels (any one of them will do the job):
+- Design: any design document
+- Website: any change to the website that is not documentation
+- Documentation: documentation for releases or any markdown file in the repo 
+- changelog-not-required: use only when the PR is not addressing any of the above cases. This is for changes in the code that is not introducing any change in behavior for the software. 
+
+There is no need to use more than one label.
+
+Please add the label BEFORE creating the PR/draft. This will make the CI check pass. If you forget, it's ok: adding it after will make the CI fail, but it will still let us merge. The only minor downside is that it will have a red checkmark for failure.
+
 ## Adding a changelog
 
 Authors are expected to include a changelog file with their pull requests. The changelog file

site/content/docs/v1.5.0-rc.1/maintainers.md

@@ -0,0 +1,29 @@
+---
+title: "Instructions for Maintainers"
+layout: docs
+toc: "true"
+---
+
+There are some guidelines maintainers need to follow. We list them here for quick reference, especially for new maintainers. These guidelines apply to all projects in the Velero org, including the main project, the Velero Helm chart, and all other [related repositories](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#code-repositories).
+
+Please be sure to also go through the guidance under the entire [Contribute](start-contributing/) section.
+
+## Reviewing PRs
+- PRs require 2 approvals before it is mergeable.
+- The second reviewer usually merges the PR (if you notice a PR open for a while and with 2 approvals, go ahead and merge it!)
+- As you review a PR that is not yet ready to merge, please check if the "request review" needs to be refreshed for any reviewer (this is better than @mention at them)
+- Refrain from @mention other maintainers to review the PR unless it is an immediate need. All maintainers already get notified through the automated add to the "request review". If it is an urgent need, please add a helpful message as to why it is so people can properly prioritize work.
+- There is no need to manually request reviewers: after the PR is created, all maintainers will be automatically added to the list (note: feel free to remove people if they are on PTO, etc).
+- Be familiar with the [lazy consensus](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#lazy-consensus) policy for the project.
+
+## Creating a release
+Maintainers are expected to create releases for the project. We have parts of the process automated, and full [instructions](release-instructions).
+
+## Community support
+Maintainers are expected to participate in the community support rotation. We have guidelines for how we handle the [support](support-process).
+
+## Community engagement
+Maintainers for the Velero project are highly involved with the open source community. All the online community meetings for the project are listed in our [community](http://localhost:1313/community/) page.
+
+## How do I become a maintainer?
+The Velero project welcomes contributors of all kinds. We are also always on the look out for a high level of engagement from contributors and opportunities to bring in new maintainers. If this is of interest, take a look at how [adding a maintainer](https://github.com/vmware-tanzu/velero/blob/main/GOVERNANCE.md#maintainers) is decided.

site/data/docs/main-toc.yml

@@ -91,5 +91,7 @@ toc:
         url: /faq
       - page: ZenHub
         url: /zenhub
-      - page: Support Process
+      - page: Support process
         url: /support-process
+      - page: For maintainers 
+        url: /maintainers

site/data/docs/v1-5-0-rc-1-toc.yml

@@ -91,5 +91,7 @@ toc:
         url: /faq
       - page: ZenHub
         url: /zenhub
-      - page: Support Process
+      - page: Support process
         url: /support-process
+      - page: For maintainers 
+        url: /maintainers