gh-1309: Document how to selectively build RST pages

[MichaByte]

This PR adds a small section to documentation/start-documenting that informs the reader of how to build only certain documentation pages. I tested my instructions on Linux and Windows. Please let me know if any changes are needed!

Thanks,
Micha

---

📚 Documentation preview 📚: https://cpython-devguide--1562.org.readthedocs.build/

[StanFromIreland]

IMO this does not need a whole section, I've never built specific pages, by the time I've written the command make html would have finished anyway. I don't see much need for this here, especially such a large section.

A better place would be above in the .. tip:: explaining you can pass SOURCES="" with desired paths.

[StanFromIreland]

Suggested change

	It is also possible to build only certain pages of the documentation in order
	to save time during the build process. Following is an example for building two
	pages:
	To build only certain pages of the docs as HTML, run:

It can be simpler, like the previous introduction.

[StanFromIreland]

Suggested change

	See :ref:`using-sphinx-build`. When invoking ``sphinx-build``, pass the
	desired pages as the final parameter, like so:
	When invoking ``sphinx-build``, pass the
	desired pages as the final parameter, like so:

Do we need the reference here, if we really do IMO it is more natural to have it after i.e.

When ... parameter. See XXX.

[StanFromIreland]

Why not just add it as a note here?

[ZeroIntensity]

Stan, be aware that a lot of these changes are being discussed at the sprints in-person.

[StanFromIreland]

I assumed so, yet I am not there :-(, so all I can do is comment.

[ZeroIntensity]

Right, but some changes have already been informally approved elsewhere, so it's not particularly helpful to say things like "IMO this does not need a whole section."

I get that you're aspiring to be a triager or on the documentation team or whatever, but this isn't the way to go about it! Documentation reviews are the most helpful when they're about actually fixing typos or incorrect information, but wording and formality nitpicks (like you tend to suggest) are just noise that actually slow down documentation PRs.

I think you would really benefit from having a core dev mentor that walked you through this. Have you asked around at all?

[StanFromIreland]

Right, but some changes have already been informally approved elsewhere

Unfortunately I have no way of knowing this if it is not listed in the description.

but wording

It seems like quite an important thing in a documentation pr.

fixing typos or incorrect information

You must have missed quite a few of my reviews then.

Have you asked around at all?

Yes, several months ago.