Supporting Mentees in Your Open Mentorship Program¶

Joey Salazar came to Outreachy from an unusual angle. She was already certified in CCNA and Linux+, had worked as a junior developer on BIND, and had been involved in standards organizations like ICANN, IETF, and W3C. She wasn't a student looking for her first break. She was someone with industry experience who wanted to go deeper and work on software that mattered, with people who could help her grow in ways her previous roles hadn't.

When she saw the Outreachy project description for adding Git protocol support to Wireshark, she knew immediately she wanted in.

"As a junior developer, I've been using Git since the first year of my studies, and as a DNS privacy advocate, I'm familiar with research and articles that used Wireshark."

The project connected directly to things she already cared about. She applied, got in, and spent three months working alongside the Git and Wireshark communities on something genuinely complex.

By the end of it, she had a clearer sense not just of what she'd built but of what she wanted next. That clarity is one of the things a good mentorship program can give a mentee that no amount of technical training can manufacture.

This chapter is about how programs and mentors create the conditions for that kind of growth.

Setting realistic expectations¶

The gap between what mentees expect when they start and what the experience actually involves is one of the most reliable sources of early difficulty in mentorship programs. Some mentees arrive expecting a structured course with clear right answers. Others expect near-constant mentor availability. Others underestimate how much independent work the role requires and how long it takes to feel genuinely useful in an unfamiliar codebase.

None of these expectations are unreasonable. They're just often wrong. Setting expectations early is one of the simplest and highest-impact things a program can do.

What mentees should know before they start¶

The learning curve is real and expected. The first two to three weeks of an internship often feel disorienting. The project is unfamiliar, the community's communication norms are different from anything the mentee has encountered before, and the pace of progress feels slower than expected. This is normal. It is not a sign that the mentee is wrong for the program.

Independent work is most of the job. A mentee who expects their mentor to direct every hour of their day will be disappointed — and so will their mentor. The internship is structured support, not constant supervision. Mentees who thrive are the ones who can work through problems independently: trying things, documenting what they tried, and asking specific questions when they're genuinely stuck rather than at the first sign of difficulty.

Progress is not always visible. Some weeks produce clean commits and merged patches. Others produce mostly understanding of why a previous approach didn't work, of how a particular part of the codebase is structured, or of what the community actually means when it says a patch needs to be "rebased". Both kinds of weeks are productive. Mentees who only count the weeks with visible output will underrate how much they're learning.

The stipend is support, not payment for results. Mentees, especially those coming from contexts where every dollar of income matters, sometimes feel that the stipend creates an obligation to produce at a professional level. It doesn't. The stipend exists to make participation possible. The expectation is good-faith effort, honest communication, and genuine engagement with the work. Not perfection.

Asking for help is part of the role. In some educational and professional contexts, asking questions signals weakness. In open source mentorship, it signals engagement. Mentors expect to field questions.

Navigating communication across cultures and time zones¶

Open source mentorship is almost always cross-cultural and often cross-continental. A mentee in Nigeria, a mentor in Germany, and a coordinator in the United States. Coordinating across that geography is manageable with the right practices and genuinely difficult without them.

Time zone management¶

The basic discipline of time zone management sounds obvious until you watch how often it breaks down in practice. A meeting scheduled for "Monday at 3pm" with no time zone specified means different things to everyone. A mentor who sends a message on Friday afternoon their time and expects a response before end of day is not accounting for the fact that their mentee's weekend has already started.

Practical practices that help:

Always specify time zones when scheduling. Not "3pm" but "3pm UTC." Use a tool like World Time Buddy or Every Time Zone to find windows that work for both people without requiring either to be awake at an unreasonable hour.

Be explicit about response time expectations across weekends and holidays. Holidays vary by country. What is a working day in one place is a national holiday in another. Ask at the start of the internship and update the communication plan accordingly.

Batch questions where possible. A mentee who sends one message with three related questions gives their mentor something they can respond to in one sitting. A mentee who sends three separate messages over the course of an hour creates three separate interruptions. The former is a better use of everyone's time.

Give your mentor enough context to actually help. When a mentor and mentee are across time zones, a vague message can cost a full day. When a mentee runs into a problem, it is helpful to describe the problem specifically: what you were trying to do, what you tried, what happened, and what you expected to happen instead. A mentor who has everything they need to respond can do so in one message. A mentor who has to ask several follow-up questions before they understand the problem cannot. The more context you provide upfront, the faster the exchange moves.

Use async communication as the default, not the exception. Open source communities are built on async work. Mailing lists, pull request comments, issue trackers — these are the primary communication channels, not secondary ones. Mentees who learn to communicate effectively in async formats are building a skill that will serve them long after the internship ends.

Cultural differences in communication¶

Culture shapes how people communicate in ways that are easy to underestimate until they cause a problem. A few of the most common friction points in cross-cultural mentorship:

Directness. Some cultures value direct, explicit communication — saying exactly what you mean without softening. Others consider this rude and expect feedback to be framed with context and care. Neither approach is wrong. The problem arises when a mentor from a high-directness culture gives feedback to a mentee from a low-directness culture, or vice versa, and neither realizes the mismatch is cultural rather than personal.

Asking questions. In many educational systems — particularly across parts of Asia, Africa, and Latin America — asking questions of someone senior is culturally uncomfortable. It can feel like an imposition, or like an implicit admission of inadequacy. A mentee who has internalized that norm will not ask questions even when they need to, and will instead spend hours on something a five-minute conversation would have resolved. Mentors who understand this create an explicit permission structure — "I want you to message me whenever you're stuck for more than an hour" — rather than assuming that the offer of help is enough.

Silence as communication. In some contexts, silence means agreement. In others, it means discomfort or disagreement. In others still, it is simply a thinking pause. Mentors who interpret a mentee's silence as confirmation that everything is fine, when it actually signals confusion or discomfort, will miss problems that a direct check-in would have surfaced.

Formality. Some mentees will address their mentor with formal titles and careful language throughout the entire internship. Others will shift to informal communication immediately. Programs and mentors that establish communication preferences explicitly at the start reduce the chance that formality or informality is misread.

Building independence and confidence¶

The goal of mentorship is not a mentee who can complete the project they were assigned. It's a mentee who has developed the capacity to contribute independently after the program ends. Those are related outcomes but not the same one, and programs that optimize only for the former often produce mentees who feel lost the moment the structure is removed.

Independence in open source contribution is not the absence of help. It's knowing when to ask for it, who to ask, and how to ask in a way that the community can respond to usefully. It's being able to read a codebase you've never seen before and find a starting point. It's knowing how to write a commit message that communicates intent, not just action. It's being able to give a code review, not just receive one.

These skills develop through practice and through explicit attention from mentors who are watching for them and naming them when they appear. A mentor who tells a mentee, "That commit message was really clear — I could understand exactly why you made that change without reading the diff", is doing something more valuable than the compliment itself: they're teaching the mentee what good looks like in this context.

Mentees who feel safe to make mistakes, ask questions, and share incomplete work stay in the community. Those who don't leave, often before anyone realizes they were struggling. The conditions that build confidence are not complicated:

Early wins. Give mentees a small, completable task in the first week. Something concrete enough to finish and submit. The experience of having a contribution accepted, even a small one, changes how a mentee approaches the rest of the program.

Visible progress. Help mentees see how far they've come, not just how far they have to go. A mentor who notes that the mentee is now doing things independently that required hand-holding four weeks ago is giving the mentee evidence of their own growth.

Public recognition. When a mentee's work gets merged, gets cited in a discussion, or solves a problem the community was having, say so publicly. Mentees who see their contributions acknowledged by the broader community develop a sense of belonging that no private encouragement can fully replicate.

Permission to be wrong. A mentee who has never had a patch rejected, a design questioned, or an approach pushed back on has not been given a real mentorship experience. They've been protected from one. Feedback on work, delivered respectfully and specifically, is how mentees learn what good looks like. Programs that sanitize the experience to avoid discomfort produce mentees who are unprepared for the reality of open source contribution.

Building toward autonomy¶

The arc of a good mentorship moves deliberately from high support to high independence. In weeks one and two, the mentor is closely involved — directing tasks, reviewing everything, and checking in frequently. By weeks ten and eleven, the mentee should be identifying their own next steps, managing their own time, and reaching out to the mentor with specific questions rather than waiting for direction.

That arc doesn't happen automatically; it has to be designed. Mentors who consciously pull back their involvement as the mentorship progresses — stepping in when needed but otherwise letting the mentee drive — are building independence. Mentors who maintain the same level of involvement from week one to week twelve, however well-intentioned, are keeping the mentee dependent.

Dealing with Challenges, feedback, and conflict resolution¶

Difficulty in mentorship comes in many forms. A mentee who falls behind schedule. A community member who is harsh when reviewing a contribution. A misunderstanding that festers because neither person is comfortable naming it. None of these are unusual. All of them are manageable if they're addressed early and directly.

When a mentee is struggling¶

Struggling is not the same as failing. A mentee who is struggling but communicating about it is still doing the work. A mentee who has gone silent, stopped submitting contributions, and isn't responding to messages is in a different situation that requires different attention.

For the mentee who is openly struggling:

Acknowledge it directly. "I can see this section has been difficult. That's not unusual. This part of the project has a steep learning curve. Let's figure out where you're getting stuck."
Separate the problem from the person. The challenge is the code, the process, and the unfamiliar tooling — not the mentee's capacity or worth.
Adjust scope if needed. A narrower, completable project is better than a broad one that leaves the mentee feeling like they failed. Scope adjustment is not giving up. It's good program management.
Connect them to other resources. The mentor is not the only source of help. The mailing list, the community chat, documentation, and other contributors — helping a mentee build a wider support network is itself a mentorship act.

For the mentee who has gone silent:

Reach out proactively. Don't wait for them to come back. A direct, non-judgmental message: "I noticed you've been quieter this week. How are things going?" is almost always enough to open the conversation.
Don't assume the worst. A mentee who goes silent may be dealing with something outside the program — health, family, internet access, or financial stress. The first step is asking, not assuming.
Involve the coordinator early. If a mentee is unreachable for more than a few days, the coordinator should know — not to escalate, but to have another person try to make contact through a different channel.

Receiving feedback¶

Mentees who can receive feedback well grow faster than those who can't. This is a skill, and like any skill it develops through practice and through having mentors who give feedback in ways that make it receivable.

A few things mentees can do to receive feedback more effectively:

Pause before responding. A response written in the first thirty seconds after reading critical feedback is almost never the right one. Give it time.

Ask clarifying questions before deciding the feedback is wrong. "Can you help me understand what you mean by X?" is a better first response than defending the original approach.

Distinguish between feedback on the work and feedback on the person. Almost all feedback in open source is about the work. Even when it feels personal, it usually isn't. Reading it that way is a response to the discomfort of criticism, not to what was actually said.

Close the loop. When you've acted on feedback, say so. "I made the changes you suggested — does this look better?" tells the reviewer that you heard them and took them seriously.

Conflict resolution¶

Conflict in mentorship relationships is uncommon but not rare. When it happens, the most important thing is that neither person has to navigate it alone.

If a mentee has a problem with their mentor, they should have a clear path to raising it. That path should not go through the mentor. Programs need an independent contact who mentees can reach out to without fear that doing so will damage their internship.

If the conflict is between the mentee and a community member, the program needs to have a clear process for handling it. The mentee should not be expected to manage this on their own. Mentors and coordinators who receive reports of community member behavior should take them seriously, investigate, and act.

Safeguarding mentees¶

Safeguarding is a topic that belongs at the center of how programs are designed, because the harm that happens when it's absent is lasting, and because the people most likely to be harmed are the ones the program is most explicitly trying to serve. Safeguarding in the context of open mentorship means creating conditions where mentees can participate fully without experiencing harm. That includes:

An environment free from harassment — sexual, racial, or otherwise —, discrimination based on gender, nationality, disability, religion, or any other characteristic
Protection from the abuse of power dynamics inherent in the mentor-mentee relationship
Access to clear processes for reporting problems and confidence that those processes will be acted on

The harm to the individual is obvious. The harm to the community — losing contributors who were systematically driven out rather than choosing to leave — is less visible but just as real.

The role of code of conduct¶

A code of conduct is the minimum structural element of a safe program. It names what behavior is and isn't acceptable, establishes who is responsible for enforcement, and provides a process for reporting violations.

Programs should:

Have a code of conduct that covers both program participants and community members they will interact with during the internship
Ensure mentees know where to find it before their first day
Ensure mentees know how to use the reporting process and who will receive reports
Ensure that reports are acted on, not filed and forgotten

Research on psychological safety shows that reporting systems only work when people feel safe speaking up and can report concerns without fear of negative repercussions. Fear of retaliation or being ignored is one of the main reasons people choose not to report problems. A reporting process that mentees believe will result in retaliation — or that they believe won't be taken seriously — is not a real reporting process.

Harassment in open communities¶

Open source communities have a documented history of hostile behavior toward contributors from underrepresented groups. It is an ongoing pattern that programs operating inside these communities have to actively work against.

Harassment in open source takes many forms:

Dismissive or contemptuous responses to contributions from newer contributors
Comments that target identity rather than work
Behavior in community spaces that makes certain people feel unwelcome
Direct messages that are inappropriate or threatening
Gatekeeping that systematically disadvantages people from particular backgrounds

Mentees are particularly vulnerable to all of these because they are new, they don't yet have established relationships in the community, and they may not know what is normal behavior and what isn't. Programs need to prepare mentees for this reality without normalizing it. That means:

Telling mentees explicitly what is and isn't acceptable community behavior before they encounter any of it
Normalizing reporting — making it clear that flagging a problem is the right thing to do, not an overreaction
Monitoring community interactions — mentors and coordinators who are paying attention will often see problems in public spaces before the mentee reports them
Acting when something is reported — the response to a report of harassment is not to ask the mentee to handle it themselves

Power dynamics and boundaries¶

The mentor-mentee relationship carries power imbalances that create specific risks. A mentor has influence over how the mentee's work is perceived, whether they receive positive references, and whether the internship is considered successful. A mentee who feels that their internship depends on maintaining a good relationship with their mentor is in a structurally vulnerable position.

Most mentors never abuse this position. But programs need to be designed as though some might — because the mentee has no way of knowing in advance which kind of mentor they have, and the cost of getting it wrong is borne entirely by the mentee.

Safeguarding guidance from the European Mentoring and Coaching Council identifies the power differential inherent in mentoring relationships as a core ethical concern, and recommends that programs establish clear boundaries around mentor-mentee contact, communication channels, and the scope of the mentor's role. In practice, this means:

Meeting in appropriate spaces. Program interactions should happen in spaces the program is aware of and that both parties are comfortable with. One-to-one communication that moves entirely off-platform and out of the program's visibility is a risk factor.

Clear scope of the mentor role. A mentor is there to guide the mentee through the project and the community. They are not a therapist, a financial advisor, or a friend in the sense that friendship creates obligations outside the program structure. When a mentee needs support that goes beyond the mentor's role, the mentor's job is to connect them to the right resource, not to fill that role themselves.

Independent reporting channels. Mentees who have a problem with their mentor need a place to report it that doesn't go through their mentor. This is non-negotiable. Programs that route all concerns through the mentor relationship have no functional safeguarding.

Mental health and wellbeing¶

The intensity of a three-month internship takes a real toll on mentees. Programs that treat mentee wellbeing as separate from program performance are misunderstanding the relationship between the two.

Mentees who are struggling mentally or emotionally don't produce their best technical work. Mentees who feel supported — who have someone checking in on how they're actually doing rather than just what they're producing — tend to deliver more and stay more engaged. This means:

Asking directly about wellbeing, not just progress. "How are you doing?" and "How's the project going?" are different questions. Both matter.

Normalizing difficulty. The internship is hard. Telling mentees this explicitly makes it less likely that they interpret difficulty as evidence that they don't belong.

Knowing when to refer. Mentors and coordinators who notice signs of serious distress should know who to refer the mentee to. The mentor is not a mental health professional and should not try to be one. But they can be the person who notices something is wrong and connects the mentee to someone who can actually help.

In the next chapter¶

How to support your program's mentors!