RFC: increasing diversity of our contributor pool

As some of you know, part of our funding proposal to CZI was for funds to increase participation of underrepresented groups at our code sprints (and in our contributor pool more generally). Due to the global SARS-CoV-2 pandemic, the fall 2020 code sprint in Seattle is postponed, and it is unclear whether a spring 2021 sprint will be possible / whether people will feel comfortable enough with air travel to make the journey. This issue is for brainstorming ways to recruit and retain a diverse pool of contributors, without relying on (subsidies to attend) in-person code sprints. @britta-wstnr and I have been chatting a bit about this; here is a summary of our ideas so far:

1. Prominent public statements that we welcome all new contributors. Locations might include the main homepage, the GitHub README, the MNE-Analyze email footer, and/or including a slide and verbal statement in any MNE-Python-related talks/trainings done by core devs.
2. Designated "ambassadors" who are willing to work directly with new contributors a little bit more than the usual PR review. Ambassadors should be willing to exchange a few emails or videoconference with new contributors to answer questions, give guidance, even do a little screen sharing or pair programming as appropriate.
3. Designated "mentors" who would commit to a certain number of hours/week for a defined period, and get matched with an "intern" to work one-on-one with during that period. It may or may not be possible to provide stipends for the mentor and/or the intern for this option.

The goals for new contributors are flexible and expected to vary depending on the new contributors' past experiences and current interests, but generally will include some of:

• developing comfort and fluency using git / GitHub
• understanding Python package installation (i.e., different ways to install MNE-Python and its dependencies, upgrading, etc)
• learning best (or "good enough") practices for scientific programming & scientific software development (documentation, testing, deprecation cycles, etc)

Please weigh in here if you have alternatives or additions to suggest, want to express support or lack of support for any ideas already mentioned, or have other related comments to share. We are very much open to other ideas. Also please tag anyone you think should see this but who might not get auto-notified without an @-mention.

This is an open-ended RFC about recruiting and retaining contributors rather than a scoped code change. Start by reviewing the proposed homepage, GitHub README, MNE-Analyze email footer, talks, ambassador, and mentor ideas, along with the existing discussion. Done is not defined; the issue needs a decided direction and concrete ownership before implementation can begin.