The tab on develop looks good. Why is the information then duplicated on a second page?

Because the codespaces.md file will hopefully be opened automatically when codespaces is fired up (which we can't do with rst files)

Is that a usual thing for codespaces? Seems strange to pop open an editable file that is part of the repo.

Regardless id just have the markdown file have a link to the canonical instructions and not repeat info.

I'm less worried about the duplicate text between the tabs. I think reading a unified top-to-bottom flow is nicer than reading it broken up.

Is there anything we can do about the navigation on the left? I am not sure what the right order is, but having "Contribute" below the MEP docs and near the bottom seems less than ideal. Looking at this whole section I think the bigger problem is less the repetition, but more the disjointedness as you read through the sections in the order on the left....

Regardless id just have the markdown file have a link to the canonical instructions and not repeat info.

If the goal is to make it easy for people to get started, I'm in favor of it being as obviously self documenting in-line as possible.

Here's a second take.

I made the codespaces.md file simpler to just link out to the actual contributing guide and reorganized the build instructions a little bit. I think I've addressed most comments but happy to have more feedback. Cheers!

Relevant artifact: https://output.circle-artifacts.com/output/job/b7e3320f-aab1-4533-8fd7-98b239eaf25f/artifacts/0/doc/build/html/devel/contribute.html#contributing-code

Here's another take: https://output.circle-artifacts.com/output/job/279bd963-85a5-45e1-89a6-d8bc05a913d5/artifacts/0/doc/build/html/devel/contribute.html#contributing-code

The codespaces.md file is now just a list of links, and all the docs are in the Contribute page. I think this is much simpler and better!

@story645 the nested numbering is a bit tricky, let me know what you think of this version.

@story645 the nested numbering is a bit tricky, let me know what you think of this version.

I see what you mean. Bullets or even spaces - so it's 3 short paragraphs- is also fine. I think it'd be better for the three steps in code spaces are clearly visually separated but I don't care much how.

And yeah I also like this version much much better.

@meeseeksdev backport to v3.8.x
@meeseeksdev backport to v3.7.x

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

git checkout v3.7.x
git pull

1. Cherry pick the first parent branch of the this PR on top of the older branch:

git cherry-pick -x -m1 0849036fd992a2dd133a0cffc3f84f58ccf1840f

1. You will likely have some merge/cherry-pick conflict here, fix them and commit:

git commit -am 'Backport PR #26201: DOC: Add documentation on codespaces usage'

1. Push to a named branch:

git push YOURFORK v3.7.x:auto-backport-of-pr-26201-on-v3.7.x

1. Create a PR against branch v3.7.x, I would have named this PR:

"Backport PR #26201 on branch v3.7.x (DOC: Add documentation on codespaces usage)"

And apply the correct labels and milestones.

Congratulations — you did some good work! Hopefully your backport PR will be tested by the continuous integration and merged soon!

Remember to remove the Still Needs Manual Backport label once the PR gets merged.

If these instructions are inaccurate, feel free to suggest an improvement.

I don't feel like doing that backport close to 3.8 release.