Outreachy report: April 2026

Program activities

As mentioned in my last report, we approved a total of 347 initial applications. Therefore, 347 applicants moved on to the contribution phase. Of those, 217 applicants recorded starting at least one contribution on our website — a conversion rate of 62,5%. 196 of those 217 submitted a final application — in other words, 90,3% of applicants who recorded a contribution finished their application journey. Lastly, 14 interns were selected as interns for 13 different projects and with 7 different communities.

And here’s a comparison with previous cohorts:

Incidents we faced during the contribution and selection periods:

• 2 communities withdrew their participation. Reasons:
  • They weren’t prepared for the influx of the contribution phase;
  • They didn’t have the mentoring or coordination capacity anymore.
• 2 communities made changes to projects they offered. Reasons:
  • Changes in mentorship capacity;
  • Changes in scope.
• 1 community reported a code of conduct incident.
• 1 community requested an extension of the selection period.

Approving 14 interns for the May 2026 cohort means a reduction of 44% in internship spots compared to the previous cohort. We contacted several mentoring communities with earmarked funds to encourage them to participate in this cohort, but as mentioned in the previous report and shown in the statistics above, communities are facing a significant reduction in their mentorship capacity.

Our May 2026 internships will start on May 18.

Open Mentorship Handbook

I was connected to a group of Software Engineering researchers writing papers on mentorship practices in open source. Throughout April, I became one of their mentors and the co-author of a paper about a Brazilian mentorship program based on Extreme Programming practices, in many ways derived from Outreachy and Google Summer of Code, led by Outreachy alums and mentors: Big Open Source Sibling (BOSS). My main contributions were the contextualization of the program in a bigger open mentorship ecosystem thanks to my expertise as a program manager of Outreachy; and my insights as an adviser of early implementations of the program (originally called “Big Open Source Sister” — changing the last S to “Sibling” was my suggestion so the name would be more gender neutral while keeping their very cool acronym). We submitted this paper as an experience report to the Women in Information Technology track of Congresso da Sociedade Brasileira de Computação (CSBC 2026), and it was accepted! Our paper will soon be published in the conference annals.

This mentoring experience (how fitting!) allowed me to expand the program design axis of the Open Mentorship Handbook through a more academic lens. I interviewed several key personnel (program idealizers, organizers, mentors) during this period and produced a significant amount of studying materials. Here are some insights we’ll incorporate:

• Programs should be upfront about the skill level they require from applicants. Several of the more established and notorious programs (Google Summer of Code, Outreachy, Major League Hacking, LFX) expect applicants with a medium to high level of familiarity to open practices and technical expertise; we can no longer consider them ladders for people very early in their open contribution path. Programs who seek to build that capacity are increasingly rare; BOSS was designed to address such gap.
• Programs of this nature are usually initiated through employing the social network of organizers as mentors. In this case, since they didn’t have a process or an intermediary to build a trustful relationship with more mentors outside their social networks. The introduction of mentors from beyond their social bubble required them to create a process for teaching mentors how to mentor according to their standards. This difficulty in understanding how to become a good mentor was also shared by Outreachy mentors we interviewd. This highlights how important the section about the nature of mentoring will be.
• Expanding and keeping program capacity beyond idealizers was much harder on them as everyone was working on it on a volunteer capacity. Ties to employment or any sort of compensation for organizers help programs become more consistent. Early seasons of BOSS were heavily documented; later seasons were not. Tracking the immediate and long-term outcomes of alums is a tremendous challenge for them, which also impacts their chances at establishing a continuous stream of funding.
• Programs can either pick a single host a third party community or project to concentrate their efforts, request that applicants submit their own projects, or host several third party communities and projects. BOSS preferred the very first approach as it allowed them to build their mentees’ capacity in a more controlled environment (i.e. they were a bridge to a specific community) — all contributions from their “little siblings” were reviewed and, eventually, merged. Mozilla Open Leaders and Open Life Science adopt a “bring your own project” methodology (i.e. incubators). Outreachy and Google Summer of Code follow are community facilitators.
• Programs are a structured, timed approach to open mentorships. They may or may not require mentors to follow specific mentorship principles and practices (e.g. amount of mentoring hours, submission of feedback forms, adoption of one synchronous mean of communication).
• Programs may offer a structured path for accepted mentees to follow. BOSS had online and recorded classes about technical and non-technical topics related to the phase they were currently in. Outreachy used to sent bi-weekly emails with blog prompts and invitations to intern chats — topics were tied to their expected progression in the program.

I plan on having a section for case studies, and BOSS researchers have agreed to write it. Other programs I want to approach are rOpenSci and OLS (Open Life Science). I would also like to interview people at Quansight and Collabora as both companies have established seasonal open mentorship programs as well offered as internships.

Such observations entice me to create a taxonomy for open mentorship programs, similar to the way I’ve been creating one for mentorships itself:

So I can later on get to more details on how open mentorships are a significant subtype of mentorships. It’s important to establish a common language before diving into more specific open mentorship topics so the reader can have a good idea of what and how many actors and factors may be involved in the making of an open mentorship. Taxonomies are also an incredible tool to (1) transfer knowledge (2) train intelligent systems. Future research on open mentorship practices may be positively impacted by its availability.

Additionally, I established that Zensical is the way to go to publish it:

Reasons why I picked it:

• Open source
• Follows docs-as-code philosophy
• Established as the evolution of MkDocs from its most popular theme creators^[1]
• Offers an incredible ease of configuration
• It’s transferrable (i.e. rendered HTML pages can be hosted anywhere, anytime)

My mission this month: push everything I’ve been writing to the public repository and consolidate our very first draft of the whole handbook. I’ve been doing it offline because (1) I want things to reach a state I feel proud to display in public (2) I’ve been writing in a flow, without revisions (3) it’s a lot of work to curate what can be publicized (since I got access to confidential information from other programs) and what cannot. Extracting general lessons from more private places is a problem I didn’t expect to have, but I’ve been fortunate enough to be trusted by a lot of other program managers!