Working in an open source project has the result that sometimes developers with no experience in the codebase attempt to "learn the code" on their own.
There is a reoccurring trap I've seen, where new developers try to:
understand everything before doing anything.
These tend to be developers who only ever worked on their own projects, or at least smaller codebases, where this may work out OK.
My impression is that they try to read the code a bit like it's a book, hoping that somewhere near the end they will have an "ahah" moment where they will understand it and start writing new code and being productive.
(I'm simplifying a bit here).
This always seems to end badly.
Rather than questioning their approach, they complain the code is confusing and needs more comments.
(Whether or not to include comments is a big topic. For purpose of discussion we can assume the code is reasonably well-commented.)
Not to suggest the code is perfect either, but some developers manage to learn it and become productive.
To me the approach is flawed to begin with, but asking since this is such a common assumption/mistake.
When developers have already tried and failed to enter a large codebase by reading over the code:
What steps might an open-source project take to help new developers avoid common pitfalls based on (often poor) assumptions?
Note on the "volunteers for open source" aspect (added for clarification)
You might think that the volunteer part of the question isn't important and that any new developer on a large codebase would run into these problems.
While this may be true in some cases, there is a difference that volunteers aren't employed by the organization, they can do what they like, how they like - and may do a significant amount of work on their own without asking for guidance, further, they are free to ignore all advice too. Even if their work is rejected for example, they may continue to develop it, start a fork etc....
This typically isn't the case a developer employed to work on closed source software.