If you are fixing 20 typos, they are much more likely to get accepted as 20 separate issues.
Say we like 18 of them, but think the other 2 are more a matter of taste:
- If they are all separate requests, we can just slam through all 20 and be done with it. Accept, accept, close, accept, etc.
- If they are all in one, now we are having a debate about if it is a regional thing or if colloquial language has a place in technical documentation. At that point, it is faster to just make the fixes separate from the pull request.
If you are working on larger changes, you should definitely discuss this with the community way before opening a pull request. That process will clarify what should happen in your specific case.
If it involves API or implementation changes, are those changes that the core team wants to make? Do they know the motivation? Have they been consulted at all about how this fits with other ongoing work? Do these discussions demonstrate that everyone works together well? Etc.
Over a decade working on this project I have found that the realities of developing software as a team are always the same, independent of whether the software is free. Collaboration requires communication and pre-planning. Someone has to make decisions about prioritization. The end result is better when you get along well with your colleagues. Big projects just do not work without strong personal relationships! (At least in my experience!)