support develop to main rename on nebari repo

docs/community/maintainers/release-process.md

@@ -47,24 +47,16 @@ For example, the first Nebari CalVer release was `2022.10.1`. If a hotfix releas
 
 We use the following guidelines to manage `git` branches by assigning certain roles to particular branches.
 
-- [`develop`](https://github.com/nebari-dev/nebari/tree/develop) - Represents the active development branch and is the _default_ branch on the GitHub repository.
+- [`main`](https://github.com/nebari-dev/nebari/tree/main) - Represents the active development branch and is the _default_ branch on the GitHub repository.
 
-- [`main`](https://github.com/nebari-dev/nebari/tree/main) - Represents a production-ready state of the code-base, with an appropriate tag to match the most recent release.
 
-- `release/YYYY-MM-releaseNumber` - Represents the branch for the upcoming release and only briefly exist while actively preparing for the release.
+## Release Tags
 
-### Process
-
-Although this process is captured in the [release checklist template](https://github.com/nebari-dev/nebari/issues/new?assignees=&labels=type%3A+release+%F0%9F%8F%B7&template=release-checklist.md&title=%5BRELEASE%5D+%3Cversion%3E), it's worth making clear how branches are managed.
+- `YYYY-MM-releaseNumber` - Represents the tag for a particular release.
 
-- Active development occurs against the `develop` branch.
-- When it's time for a release, the Release Captain will create the release branch `release/YYYY-MM-releaseNumber` and prepare the branch for the release. At times, this might mean cherry-picking commits that are needed for this release and at other times, this might mean merging `develop` into this release branch.
-- As soon as this release branch is ready, the Release Captain can open a pull request against `main`. From here, all of the changes that are included in the release should be visible in the "Files changed" section of the pull request.
-- Once CI passes, all manual tests are successful and the team is happy with the changes, the Release Captain can complete the release checklist and cut the release.
-
-#### Hotfixes
+### Process
 
-In the event that a patch or hotfix release is needed, release process is the same as outlined above. The only difference is that the commits that are merged into the hotfix release branch will need to be cherry-picked from the `develop` branch.
+The release process is captured in the [release checklist template](https://github.com/nebari-dev/nebari/issues/new?assignees=&labels=type%3A+release+%F0%9F%8F%B7&template=release-checklist.md&title=%5BRELEASE%5D+%3Cversion%3E).
 
 ## Related packages
 

docs/community/maintainers/reviewer-guidelines.md

@@ -62,7 +62,7 @@ Only maintainers can merge pull requests. Please follow these guidelines:
   - If the contribution is made to the `nebari-dev/nebari` repository, then you'll need to trigger the Kubernetes tests
     by commenting `/bot run tests` on the PR.
   - If the contribution is made to the `nebari-dev/nebari-docs` repository, then make sure to check the Netlify build and preview.
-- In case of merge conflicts, ask the PR submitter to rebase on `develop`.
+- In case of merge conflicts, ask the PR submitter to rebase on `main`.
 - Squashing commits or cleaning up commit messages of a PR that you consider too messy is OK.
   Remember to retain the original author’s name when doing this.
 - When you want to reject a PR: if it’s very straightforward, you can close it and explain why. If it’s not,