Mentoring an outreach program participant is a great way to help bring up the next generation of open-source contributors and support the Zulip community. The experience of watching your mentee’s skills develop can be truly rewarding, and we encourage you to give it a try.

Signing up to mentor means committing to being reliable source of support on your mentee’s open-source journey over the course of the program. By signing up, you’re committing to dedicating roughly 3-5 hours a week to the program.

Mentors generally have weekly calls with their mentees to answer any questions and help make sure that everything is on track. You are also expected to help program administrators keep an eye on your mentee’s progress, and flag any concerns you might have.

Mentors can refer to the excellent GSoC Mentor Guide for detailed guidance, including GSoC’s expectations, and best practices that can apply to any program.

Who can mentor

In order to mentor with Zulip, you need to have spent significant time working on Zulip yourself. You need to be familiar with what it takes to get work integrated, so that you can help your mentee with this process. We encourage anyone who has successfully completed a mentorship program with Zulip as a participant to give mentorship a try!

Note that you do not need to have any expertise in the part of the codebase that your mentee is working in. We have seen many successful mentor-mentee relationships where the mentor was new to the parts of the codebase that were the focus of the project.

You also do not need to be a currently active contributor to Zulip. Our expectations and patterns of getting work done have been quite consistent over time, and it should be easy for you to catch up on anything that’s changed since you were actively involved.

Supporting your mentee

At the start of the program, please read our guide for program participants to understand Zulip’s expectations for your mentee.

What exactly you focus on in your mentorship will vary from week to week, and will depend on what your mentee needs. It might be any combination of:

  • Helping your mentee plan, chunk, and prioritize their work.

  • Manually testing UI changes and helping find bugs or identify corner cases needing further discussion.

  • Providing early feedback on visual and technical design questions.

  • Helping your mentee figure out how to test their changes.

  • Helping your mentee break their PRs into coherent commits.

  • Doing code review of your mentee’s work.

  • Helping with the technical design of projects and making sure they’re aware of useful and relevant reference materials.

  • Pair programming with your mentee to share useful tricks.

  • Emotional support when things feel like they aren’t going well.

It might seem challenging to review code if you’re not an expert on your mentee’s focus area. Don’t let yourself be intimidated! Reviewing changes to code your don’t fully understand is a common experience in software development, and you can still provide valuable feedback.

If you don’t understand something about the changes being made, there is a good chance others would also find it confusing. Asking your mentee for an explanation will itself be valuable feedback on what parts of the PR need to be commented or rewritten in a more clear way.

Establishing communication patterns

Over the course of the program, you will interact with your mentee both synchronously (e.g., on calls, pair programming, and/or via chat in the development community), and asynchronously (in the development community and on GitHub).

It’s important to ensure that there are regular opportunities for synchronous interactions, which are the best way to resolve some types of questions and concerns, and will help your mentee feel supported.

Please schedule at least one synchronous interaction opportunity with your mentee per week. A weekly call is highly recommended, as calls can be especially helpful for getting a feel for how your mentee is doing, and lowering the bar for asking questions and sharing concerns. A good pattern might be a weekly call, plus 1-2 other regular time slots when you and your mentee check in in the development community.

Managing challenges

We rely on you to proactively flag your concerns to Zulip’s program administrators as early as possible. Situations you should bring up include:

  • Lack of communication from your mentee, e.g., missing a scheduled call, missing multiple check-ins, lack of response to PR reviews, etc.

  • If your mentee’s rate of progress on their projects is not commensurate with the hours of work they are supposed to be dedicating to the project.

  • If you are not seeing improvement in response to the feedback you give.

  • If your mentee seems to be struggling, deeply frustrated, or otherwise is not having a good experience with the program.

  • Any significant questions or concerns raised by your mentee that you cannot resolve, which for some reason your mentee cannot raise directly.

  • If it turns out that cannot dedicate sufficient time to support your mentee for all or part of the remaining duration of the program. As long as Zulip’s program administrators are informed, we can make sure someone else covers for you.