Personally, I became “maintainer” of a number of things by simply spending enough time working on them until I got familiar with the code and I felt confident in making changes.
The first issue I reported was about Unicode. I then learned (with the help of other coredevs, by reading the code, and by experimenting) how Unicode is implemented in Python, and then fixed a number of Unicode-related issues. While doing this I ran into issues with regrtest, learned how it worked, and improved that, and that also led me to learn more about unittest and fixing a number of unittest-related issues. Then I ran into problems with HTMLParser, and ended up updating the code to make it HTML5-compatible and able to parse every page without errors. Same with bpo and now GitHub.
I think other devs followed similar paths, even though many tend to focus on specific modules they care about and/or are already familiar with, possibly because of lack of time and/or interest.
In other words: have some issue → spend time understanding the code so you can fix it → fix the issue → fix related issues → you have now enough knowledge that you can become a maintainer.
I’m actually not sure the path “contributors → triager → committer/maintainer” is always right. Being a triager requires a different set of skill than being a committer, even though there is certainly some overlapping.
A triager needs to be familiar with the way we classify issues, the issue tracker and its fields/labels, what is considered valid/invalid, know who the “experts” are, and have at least a basic understanding of how our code base is structured and organized. In theory they don’t even need to be developers at all (as long as they defer to the right person for more specific decisions).
A committer might be very familiar with a single module/package and have an understanding how our workflow, without necessarily having to be particularly familiar with the issue tracker and the rest of the codebase.
In other words, some contributors could be promoted directly to committers/maintainers, whereas other might be promoted to triagers and never become committers (unless they want to and are qualified enough).
I addressed this in Triaging/reviewing/fixing issues and PRs.
The bystander effect? This is part of the problem, however I think issues are ignored simply because devs are not willing to take the responsibility of merging a PR on piece of code they are not familiar with (and that’s completely understandable). Improving tests/coverage might be somewhat helpful.
We could use CODEOWNERS to track maintainers, and automate from there. Teams could also be created for module/packages that have multiple maintainers so that we could directly @mention them and add the teams as reviewers to PRs.