[DOC] - Clarification for which branch to open labs blog post PRs against.

[steppi]

Currently the README contains the following language

Quansight-website/README.md

Lines 149 to 151 in a3742d0

	Note that Labs blog posts are a bit of an exception. Categorically they are
	content changes, but the content lives in the Git repo -- so technically they are
	code changes, and they follow the process for code changes.

and the process for code changes states the following

Quansight-website/README.md

Lines 206 to 210 in a3742d0

	### Code changes (GitHub) 💻
	Code changes move through three stages, each of which corresponds to a branch in
	git: a feature branch (PR), then the `develop` branch, then `main`. When your
	code gets merged to the `main` branch, Vercel deploys it to the public website.

and following these instructions, I opened the PR for a blog post against the develop branch here, #892 ¹. This PR has since been approved and merged.

After this PR got merged, I then noticed that I'd missed the following instructions:

Quansight-website/README.md

Lines 53 to 54 in a3742d0

	7. Create a pull request to the `main` branch. Make sure to add the `type: content 📝`
	and `labs 🔭` labels to the PR.

which seem to contradict the above instructions. I also found that many labs blog post PRs have been opened against main, but the particular one I checked as a reference happened to be opened against develop.

I have the following questions.

1. Is the proper process for labs blog posts to open PRs against develop or main?
2. Can we update the README to consistently reflect the proper process?
3. What is the best way to get my post which has been merged into develop added to main and deployed? Is there anything in particular I need to do? I was thwarted when trying to follow these instructions:

Quansight-website/README.md

Lines 234 to 239 in a3742d0

	```sh
	git checkout develop
	git pull
	git checkout -b release-YYYYMMDD
	git push -u origin release-YYYYMMDD
	```

because there were merge conflicts between develop and main that I didn't feel qualified to resolve.

Should I just create a new PR that cherry-picks the squash-merged commit from develop and target it against main?

Footnotes

1. I had actually originally opened a PR against main here, https://github.com/Quansight/Quansight-website/pull/891, but closed
   it and opened a new one against develop because I thought that was the proper process. ↩

[gabalafou]

I think the issue is that the README is too long.

The instructions for writing a blog post are in the top section of the README: How to publish a new blog post 📝

If you wade too deep into the middle of the README, you could get yourself in trouble. The workflow for creating a blog post is different from the workflow for making other kinds of changes to the website.

I can look into slimming down the README, but I need a place to put some of the info that I take out, and I'm not exactly sure where it should go... I'm afraid that if I create a CONTRIBUTING file, then folks looking to write a blog post might go directly there first. I don't want to call it ARCHIVE either because some of the info will still be relevant. I'll think about it some more. In the meantime, if you have any suggestions, please let me know.

[gabalafou]

This small change might also help: #908