The title is so confident, because I wish someone had told me these things ten years ago.
The key is to actively offer to mentor newcomers.
I work for The Document Foundation as a generic LibreOffice mentor. I am able to introduce people to all the ways of contributing to the software. On the LibreOffice website, potential contributors are advised to schedule an interview with me. In our chat channels, I either initiate interviews right away or give out my email to newcomers seeking help on starting out. I recruit people through volunteer platforms.
In 2020 I gave a short presentation about the topic.
Something I discovered only after applying this approach for a while is that it achieves diversity and inclusion at a fundamental level: the mindset. The traditional way to get into FOSS requires one to be an independent learner. This creates a bubble.
TDF employs people responsible for coordinating volunteer work in all the teams (docs, QA, development, design). For QA and development, I keep scheduling discussions with the newcomers until they reach a certain level. For docs I usually just give an intro and for design I include one follow-up chat. The typical gap between chats is two weeks.
Most people prefer text chats, so that is what I use by default. I also do regular public screensharing sessions of bug triaging in our Jitsi. These help with QA onboarding, but have other benefits as well, because anyone can join to collaborate.
In 2021 I had over 120 interviews and over 230 follow-up chats.
Volunteer platforms like VolunteerMatch allow us to reach people, who would otherwise not be introduced to the FOSS contributor community. Many countries have a local web platform or several and I also use a Finnish one, which really took our local team to a new level.
As the approach is like a simplified school system, I am able to push contributors out of their comfort zone to advanced topics quite quickly. A productive newcomer in QA might after a few weeks get into a technique that took me two years to fathom.
From the mentor’s perspective, this all becomes a calendar management routine. I take care to schedule the next meeting immediately at the end of the last instead of deferring to later as it saves a lot of fussing and overhead. While I was a volunteer when I started experimenting with this, I think it would be unreasonable to do this in a volunteer role in a large project like LibreOffice. The reaction times need to be quick and the time zone differences mean that meeting slots have to be provided from morning to evening. Sometimes the only possible time is during the weekend.
Finally, as there is no real obligation to join a meeting (I’m just a random guy, not their boss), people regularly skip them without advance warning. During some weeks I might get ten no-shows and sometimes a person might skip up to three meetings in consecutive days. Dealing with this would be harsh for a volunteer, but I think it’s fine for a paid employee.
Having one person as the go-to contact for mentoring is convenient in many ways, but I’m sure distributing the first contact responsibilities can produce a similarly effective outcome. Likewise, smaller projects might be able to do this purely with volunteer mentors.
