doc: split COLLABORATOR_GUIDE.md

[trivikr]

I was going through COLLABORATOR_GUIDE.md as part of my onboarding as a NodeJS Collaborator (#19067)
Noticed that with 783 lines it's pretty long to read and can be split.

I followed PR of @joyeecheung which had split CONTRIBUTING.md in #18271 as a reference

The edits in COLLABORATOR_GUIDE.md in this PR can be viewed in my private branch at https://github.com/trivikr/node/blob/split-collab-guide/COLLABORATOR_GUIDE.md

cc @nodejs/documentation

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

doc

[Trott]

I understand why we did this for CONTRIBUTING.md. The case for COLLABORATORS_GUIDE.md is a little less clear to me.

For CONTRIBUTING.md, it's unlikely that anyone is going to want more than one or two sections of that, and by keeping it short and splitting things out, we may increase the likelihood that a drive-by contributor will actually read the relevant section.

COLLABORATORS_GUIDE.md, on the other hand, is a comprehensive-ish guide for people deeply involved in the project. What does splitting things up get us in that case? Possible downsides include:

• not knowing what file to look in for information (Related: I just opened a PR to move stuff out of the miscellaneous hodgepodge onboarding-extras.md doc and into this file specifically so people only have to remember one place to look for stuff.)
• not being able to use "find text" in a browser to search the entire document
• not being able to print the entire guide from one page

What are the upsides that outweigh these downsides?

Thanks for doing this, by the way. Anything that tries to improve this document is appreciated. I'm not opposed to this. I would love to be persuaded to be all for it, though.

[trivikr]

@Trott As a contributor, I've contributed to node core in two bursts before and after the split of CONTRIBUTING.md and found the documentation post-split very helpful.
As a new Collaborator, splitting of COLLABORATOR_GUIDE.md helped me in understanding the guide better. It was just done to improve my understanding and can be discarded if it doesn't help.

About the downsides:

not knowing what file to look in for information

In my work projects, we usually simplify the documentation with minimal specific instructions and use top-down approach while revisiting any documentation. This way we get to know if anything has changed in those steps, and can catch issue - if any - when the steps have been updated.
This does take more time then directly jumping into the specific instructions for the thing you want to do, but documentation remains simple and issues are caught early on.
For this specific PR, the user can search for keywords in /doc/guides/collaborator_guide/ in their workspace/IDE, but it won't be possible to do it over Web.

not being able to use "find text" in a browser to search the entire document

As discussed in the first downside, this is a problem while browsing the documentation on the web.
But may be Collaborators are experienced, and will know which section to visit?

not being able to print the entire guide from one page

I agree that this is also a downside, but the individual files in /doc/guides/collaborator_guide/ can be printed instead. These files will talk about specific responsibilities of Collaborators, like Accepting Modifications or Landing Pull Requests.

[lpinca]

I agree with @Trott in particular with this point

• not knowing what file to look in for information

I often find myself juggling between the documents searching for the right one. I prefer to have all information in one place. I don't care if the document is huge, if it is well structured, it is not a problem.

[apapirovski]

The collaborator guide has an index at the top with pretty good structure. Creating more files doesn't do anything to bringing additional order to this document and it's more than likely to result in new collaborators only selectively reading what they consider relevant (whereas everyone should read the full document at least once).

[trivikr]

Closing this issue as there are enough points supporting not going ahead with this split.