feat(docs): Add a contributing and release guide

docsite/docs/contributing/_category_.json

@@ -0,0 +1,6 @@
+{
+  "label": "Contributing",
+  "position": 4,
+  "link": { "type": "generated-index", "description": "Contribution guidelines for react-native-macos" },
+  "collapsed": false
+}

docsite/docs/contributing/contributing-overview.md

@@ -0,0 +1,10 @@
+---
+sidebar_label: 'Overview'
+sidebar_position: 1
+---
+
+# Contributing
+
+Thank you for your interest in contributing to React Native! Feel free to file or issues or open PRs into React Native macOS. 
+
+Because React Native macOS is a fork of React Native, we follow some rules to keep our commit history happy and our diffs with upstream manageable. The rest of this guide will focus on explaining our diffs, along with a guide for how to drive a release for those working on the repo. 

docs_archive/DiffsWithUpstream.md → docsite/docs/contributing/diffs-with-upstream.md

@@ -1,3 +1,8 @@
+---
+sidebar_label: 'macOS Tags'
+sidebar_position: 2
+---
+
 # How React Native macOS differs from React Native
 
 React Native macOS elected to implement our fork via inline diffs of existing React Native code. This means additions and changes of extra code to support macOS, usually in the same file as the existing iOS or JS implementation.

docsite/docs/contributing/versioning.md

@@ -0,0 +1,16 @@
+---
+sidebar_label: 'Versioning'
+sidebar_position: 3
+---
+
+# Versioning
+
+React Native macOS uses [NX Release](https://nx.dev/features/manage-releases) to control it's versioning. Our minor releases are synced to upstream releases of React Native, but our patch versions may differ. For instance, `react-native-macos@0.78.5` corresponds to `react-native@0.78.2`. You can find out how we sync our releases by looking at our packages' [react-native peer dependency](https://github.com/microsoft/react-native-macos/blob/8f8fd013d2a36cf2635dbcef76970119f7672b51/packages/react-native/package.json#L105).
+
+## How to push a new patch release
+
+If you have a PR you'd like to be included in a new release, you can add a [version plan](https://nx.dev/recipes/nx-release/file-based-versioning-version-plans#file-based-versioning-version-plans) to it. 
+
+```shell
+yarn nx release plan --message 'fix some bug' --only-touched=false patch
+```

docsite/docs/releases/_category_.json

@@ -0,0 +1,6 @@
+{
+  "label": "Releases",
+  "position": 5,
+  "link": { "type": "generated-index", "description": "Release guide for react-native-macos" },
+  "collapsed": false
+}

docsite/docs/releases/minor-release.md

@@ -0,0 +1,32 @@
+---
+sidebar_label: 'Sync to a new minor release'
+sidebar_position: 3
+---
+
+# Sync to a new upstream React Native patch release
+
+Let's assume that React Native macOS is currently at `0.76`, and React Native `0.77` just releasd. We now need to merge all the commits up to `0.77`, and cut a new release branch.
+
+Roughly, the steps look like so:
+
+1. Find the commit that upstreams' `0.77-stable` branched off from `main`. You can use [git merge-base](https://git-scm.com/docs/git-merge-base) to do this, or manually inspect the commit history in the React Native repo.
+2. Merge that commit, which will result in a lot of merge conflicts. Resolving these merge conflicts is the bulk of the work. There's a couple of ways to go about this:
+    1. Resolve all merge conflicts in place there and listing that in your PR notes
+    2. Resolve enough conflictsto make a commit with git diff markers and do the rest as followup to make it easier for reviewers.
+3. When your PR is approved and ready to be merged, make sure to choose the option "Create a merge commit", as this preserves commit history and ensures git (and Github) accurately list hwo many commits ahead or behind of React Native we are: 
+    - ![Github ahead behind](../../static/img/github_ahead_behind.png)
+
+
+
+
+Some gotchas:
+
+1. We ** do not ** want to just merge `upstream/0.77-stable` into our `main` branch, as the release branches contain commits that do not belong on `main` (bumping version numbers, local fixes, etc). This is why we look for the merge base
+2. It is common while doing the merge to take some particularly hairy commits (ex: a new iOS prop or feature that needs to be ported to macOS) and cherry-pick them into a separate PR so that the merge is easier or more reviewable. 
+3. After you create your PR for review, you will need to rebase it often as either:
+    - `main` moves forward because other PRs merge (such as the commits you cherry-picked into separate PRs)
+    - You create commits to address feedback, and want to fold those back into the big merge commit, or separate discrete and well named commits
+3. It is necessary to rebase and not just merge the main branch as you normally would because we merge the whole PR as a merge commit, therefore all of your commits will be added to the git history. it would be better to have commits named `feat: port X feature to macOS` rather than `port stuff` / `pr feedback` / `undo`. Therefore, before you merge the PR, it's good to do one final rebase to clean up your branches git history. 
+4. when you run `git merge <commit_hash>` and have all the merge conflicts locally, that’s a good spot to just copy/paste the output of the merge conflicts section of “git status” into your PR notes.
+5. GitHub chokes on these big PRs, but the [Github Pull Requests VS Code extension](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github) does not.
+

docsite/docs/releases/overview.md

@@ -0,0 +1,21 @@
+---
+sidebar_label: 'Overview'
+sidebar_position: 1
+---
+
+# Contributing
+
+This guide is intended for contributors driving a new release of React Native macOS, not the average contributor. It describes the steps needed to publish new minor and patch releases. 
+
+We assume your local git repository is setup with the following remotes, where `<user>` is your personal fork:
+```shell
+> git remote -v
+facebook        git@github.com:facebook/react-native.git (fetch)
+facebook        git@github.com:facebook/react-native.git (push)
+origin          git@github.com:<user>/react-native-macos.git (fetch)
+origin          git@github.com:<user>/react-native-macos.git (push)
+upstream        git@github.com:microsoft/react-native-macos.git (fetch)
+upstream        git@github.com:microsoft/react-native-macos.git (push)
+```
+
+For an older version, of this guide, see [docs_archive/GitFlow](https://github.com/microsoft/react-native-macos/blob/85494dbbfc80621268a30c92df39f25d9fcfc98b/docs_archive/GitFlow.md)

docsite/docs/releases/patch-release.md

@@ -0,0 +1,22 @@
+---
+sidebar_label: 'Sync to a new patch release'
+sidebar_position: 2
+---
+
+# Sync to a new upstream React Native patch release 
+
+Let's assume that we are trying to release a new patch release of `0.76.x`. Let's also assume that the latest commit in React Native's `0.76-stable` branch is the release commit we want to sync to. If not, `git merge` to an earlier commit. 
+
+
+Roughly, run the following commands to:
+- Sync to the latest commit in React Native's 0.76-stable branch.
+- Merge that branch into yours
+- Add a version plan
+
+```shell
+git switch -c 0.76/release upstream/0.76-stable
+git merge facebook/0.76-stable
+yarn nx release plan --message 'Sync to upstream React Native 0.76.x release' --only-touched=false patch
+```
+
+Remember to update the peer dependency in `packages/react-native` for React Native macOS to the version you have merged to.