I think point 2 is really important. I've worked with a lot of new hires, especially college interns, and some of them are deathly afraid of coming in on the first day and messing something up. I always put together a getting started page on whatever wiki we happen to be using that details how to get the development environment up and running on the first day. Since the development environment changes as our code matures (new libraries to build against, new repos to check out, etc) following the wiki never seems to just work for someone unfamiliar with the dev environment and they encounter problems or just have questions. Whenever someone has a problem or a question the solution should be documented in the wiki, so we have the new hire update the getting started wiki as they go along. This gets them a little more comfortable making changes (since they see the whole building didn't burn to the ground after making a wiki update) and gets them in the process of documenting any problems or questions.

Curious whether you really mean _everyone_ -- including non-technical roles like Sales? I notice that for instance Sales seems reasonably well document [1] so, maybe so?

[1]: https://about.gitlab.com/handbook/resellers/

Yes, everyone == every single person employed by GitLab Inc.

wow that's great. How do non technical people can update it? Do you teach them Git?

Exactly. Or at least teach them to use GitLab, which is a good motivator to make the product easy to use.