How I recruit and mentor contributors and how you should, too

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.


Thanks for sharing! This is awesome :slight_smile:

Thanks for sharing your practices and thoughts! Very valuable!

Thanks for sharing! This was insightful.

Really insightful! Wondering if you or the organization you volunteered for, created roadmaps for people based on their level of expertise and how did you go about measuring their progress? Just curious.

1 Like

Before my current approach was fully formed, I did actually create a roadmap for QA contributors. In practice these days, I don’t wait for the newcomer to get even a hundred triagings under their belt before moving to the advanced technique of bisecting. I already jump to it after they’ve done a couple of dozen basic ones. In the meetings I gradually explain the various details and metadata related to bug reports. Even people with QA work experience need time to adjust to our style of working.

In development, it helps that we have a tried and true system of mentored easy hacks. They are available in three categories of difficulty.

Regarding tracking of progress, we do monthly reports on QA, development and other interesting areas. So in the monthly reviews of commits, the activity of new contributors becomes apparent and the automatically produced stats give further insights. The reviewing is also useful for me as it helps me put potential collaborators in contact with each other etc.

We have a GrimoireLab dashboard providing a real-time picture of what is happening.

TDF offers membership for active contributors and we have a membership committee that is also regularly checking what people are up to.