Docs: Improve scoping of two potentially overlapping Triage sections

[benjaoming]

• Improve the scope of the two Triaging sections
• Fixes wrong :doc:`team` referencing Write the Docs via intersphinx
• This is a bit meta-level: Since I'm going over dev docs right now, I wonder how exactly this PR lands: It's a PR without an issue, so it's not actually triaged. Some projects prefer that an issue is always opened for discussion, some prefer that contributors have a shortcut by simply opening a PR. I believe that this is resolved, we keep things as they are, adding a bit more incentives on the triaging process.
• Do not allow any :doc: or :ref: to resolve to intersphinx mapping without :external: prefix
• Ignore :external: role in rstcheck

[benjaoming]

It seems these two warnings are new

/home/circleci/project/docs/user/localization.rst:52: WARNING: unknown document: custom_domains
/home/circleci/project/docs/user/single_version.rst:28: WARNING: undefined label: custom_domains:canonical urls

Probably used to be resolved via intersphinx... will have a look...

[humitos]

Looks good to me 👍🏼

One comment. Please, do not force push new commits if there is a review already done in the PR because that forces the reviewers to review all the files again since GitHub interprets as all the content is new. If there is a way to solve this problem involving force push I'm happy to know how, but I didn't find it. If you want to rebase/change history/etc you can do that immediately before merging the PR

[benjaoming]

Please, do not force push new commits if there is a review already done in the PR because

This is done so that I - as a PR Author - can ensure that the commit history is nice and clean before a merge. There are several alternatives to the same goal:

1. A maintainer asks the PR Author to rewrite the commit history
2. A maintainer chooses squash/rebase and the branch is rewritten before a merge -- but without any manual choices or interventions
3. Author uses the !fixup notation from the beginning -- I think in this case, it will be quite explicit for the maintainer that a squash is expected before a final merge. Github.com doesn't support anything out of the box for this yet
4. A rewrite on the author's initiative (what I just did) - the author rewrites the history themselves in anticipation of a merge. This can be done repeatedly, but should be avoided when there are open reviews - it should especially also be avoided if others are using the PR branch.

Of course, there is also the option of keeping all the commits and merging the classic way.

that forces the reviewers to review all the files again since GitHub interprets as all the content is new.

This is not really true, you can see all comments and what segments of the code they belong to. All comments in this PR were outdated.

Personally, I like to take a pragmatic approach and not see any of these as a mandatory option, as it raises the bar for contribution and makes it too easy for developers to have discussions 😄

[humitos]

@benjaoming

that forces the reviewers to review all the files again since GitHub interprets as all the content is new.

This is not really true, you can see all comments and what segments of the code they belong to. All comments in this PR were outdated.

I'm not talking about the comments, but the changes themselves. If you force push, when I go to "File changed" tab, GitHub shows me all the files again, instead of only the last changes since I reviewed this PR last time. So, I lost all the files I marked as "Viewed" and I'm not sure what changes from the last time I review the PR.