Big Open Source Sibling (BOSS)¶
Case study created by translating excerpts from our joint paper Promovendo a Participação de Mulheres e Grupos Minorizados em Comunidades de Software Livre: Um Relato de Experiência com a Metodologia BOSS and consolidating original research yet to be published.
Metadata¶
Classification¶
- Structure model: Formal and rigid
- Compensation model: Voluntary
- Support model: Transient
- Disciplinary model: Interdisciplinary
- Mentorship model: One-to-one, hierarchical and peer-to-peer
- Instrumental model: Project-oriented
- Modality: Online
Overview¶
Big Open Source Sibling (BOSS)'s methodology was designed by professor Carla Rocha while teaching courses "Software Development Methodology" and "Software Product Engineering" to undergraduate Software Engineering students at Universidade de Brasília (UnB). Her design was inspired by practices of Extreme Programming (XP) and agile methodologies led by Alfredo Goldman, Fabio Kon e Paulo J. S. Silva at Universidade de São Paulo (USP) under the course "LabXP".
The expansion of this teaching methodology into an online open mentorship program was born from a partnership between Carla Rocha and Software Engineering alumni, based on their experiences with communities such as PyLadies and Django Girls, and similar open mentorship programs such as Outreachy and Google Summer of Code.
Each edition of Big Open Source Sibling is built around a different thematic axis. The first iteration, focused on Brazilian free and open source software (FOSS) projects, was awarded by GNOME Foundation in the GNOME Community Engagement Challenge. Subsequent editions also explored topics related to game development and programming marathons.
Structure¶
Big Open Source Sibling strives for training novice contributors and building the technical foundation required to thrive in the technology field. Mentors are called big siblings and mentees are called little siblings.
The program has four main stages:
- Stage 1: Welcome to BOSS;
- Stage 2: Overcoming challenges;
- Stage 3: Community bonding;
- Stage 4: What's next?
Stage 1: Welcome to BOSS¶
Little siblings are introduced to their respective big siblings. Program organizers host weekly workshops to train little siblings on topics such as Git and local environment configuration in preparation for subsequent stages. Each big sibling have one-to-one meetings with their assigned little sibling once a week to map their interests, expertise, motivations, ambitions, areas of improvement and struggles.
Duration: 4 weeks
Success metrics:
- Little sibling has correctly configured their local environment;
- Little sibling has concluded all Git exercises;
- Little sibling is present in all communication channels;
- Big sibling has mapped their assigned little sibling's interests, expertise, motivations, ambitions and struggles.
Stage 2: Overcoming challenges¶
Little siblings are introduced to technical concepts required to contribute to a specific FOSS community through weekly workshops. For example, to contribute to a chatbot boilerplate, little siblings must understand concepts such as intents, utter, stories, natural language processing, custom actions in Python and boilerplate architecture. Lessons are accompanied by code examples and assignments with a limited scope to be developed through pair programming sessions among little siblings. Big siblings continue to support little siblings through one-to-one meetings and asynchronous communications.
Duration: 4 weeks
Success metrics:
- Little sibling has ran the FOSS project in their local environment;
- Little sibling can modify the FOSS project to a specific given context (e.g. create a chatbot for a given context);
- Little sibling participates in workshop discussions;
- Little sibling employs pair programming practices to submit proposed assignemnts;
- Little sibling comfortably shares their struggles with their assigned big sibling;
- Little sibling comfortably shares their achievements in workshops;
- Little sibling understands the importance of technical documentation in the FOSS ecosystem;
- Little sibling has set clear goals and expectations about their program participation.
Stage 3: Community bonding¶
A maintainer of a FOSS project guides little siblings through their contribution process through a selection of good first issues. The maintainer presents techniques to reproduce bugs, discuss possible solutions and walk little siblings through activities such as testing, opening a pull request, communicating with the community, adjusting contributions according to feedback and reviewing merge requests.
Duration: 2 weeks
Success metrics:
- Little sibling had their pull requests accepted;
- Little sibling feels confident in their abilities to contribute to other FOSS projects;
- Little sibling feels motivated to contribute to other FOSS projects;
- Little sibling understands the benefits of contributing to FOSS projects.
Stage 4: What's next?¶
Little siblings attend one or more onboarding workshops facilitated by other FOSS projects and continue their open source journey.
Duration: 2 weeks
Success metrics:
- Little sibling attends at least one workshop;
- Little sibling expresses interest in continuing to contribute to FOSS projects;
- Little sibling feels more confident in pursuing their career goals.
Results¶
Challenges¶
In the first season of BOSS, mentors were selected for their proximity to program organizer personal circles, not their previous mentorship experience. This resulted in a gap between organizer expectations around mentorships and actual mentorship execution. The second iteration of the program introduced an open call for mentors and a period of mentorship training ("mentoring mentors").
The increased number of participants in season two didn't translate into significantly more new commits. That occurred due to an increase in encouregement for participants to work in pairs.
The voluntary nature of the program requires organizers, mentors and mentees to maintain their participations during "third shifts" (periods of free time between professional work and school and/or domestic work). All groups reported exhaustion after a sustained period of engagement, and this influenced dropout rates in all seasons.
Due to changes in the organization team, documentation of the journey of little siblings in subsequent seasons is scarce. Changes to measurement processes of success metrics (e.g. changes to questions, evaluation cycles) make it difficult to compare earlier seasons to later seasons. We recommend that Big Open Source Sibling should conduct a longitudinal study to track medium to long-term outcomes of their participants.
