Mentoring

From OpenHatch wiki
Jump to navigation Jump to search

This may eventually be a splash page with mentee-facing information about the mentoring program, but for now, it's a planning document.

Brief Summary of Goals[edit]

The mentoring program is meant to help those who are interested in open source transition from one-off event to more regular participation in open source.

Our Students' Needs[edit]

  • More instruction/repetition on the skills we teach at our events (IRC, version control, issue trackers, etc.)
  • Help finding good projects (learning which ones exist, how to evaluate them, benefiting from our community's informal knowledge about which projects are most welcoming/responsive, etc)
  • Help understanding community norms and structures that may be otherwise invisible (how long is normal for someone to respond to you and is it okay to ping them again, how FOSS projects functions without deadlines and assignments in an academic sense, development environment setup is frequently difficult it's not just you, FOSS can be harder for reflective learners than active learners, etc)
  • A social network to increase feelings of belonging and enjoyment of participation. (Peers at a similar level of experience, role models who they can identify with and who feel approachable, a source of positive feedback for their work not just from the projects they're contributing to, a sense of shared values, a place to turn when they feel discouraged or like an impostor).
  • Help finding "easy wins" to increase feelings of competence and belonging. (An easy win may be fixing an issue for a specific project we've helped them find, but could also involve helping others, or doing setup sprints or user feedback or other contributions that rely on and require their new-ness.)
  • Help setting achievable goals. (Many students want to apply for GSoC/OPW but are intimidated, most aren't sure what they can contribute to a given project at their experience/skill level, many are confused/concerned about what kind of time commitment they're making, etc.)

Proposed Structure[edit]

Mailing List[edit]

In order to facilitate a community of peers and not just mentor-mentee relationships, we will create a private mailing list through which mentees can talk to each other. Part of their mentorship agreement will be to post at least once a month to this list, although hopefully they will post more often. Usage guidelines, including a code of conduct, will be given to students. These guidelines will not discourage off-topic conversation, as off-topic conversation can help list members connect with each other. Depending on how well people take to the list, I may or may not come up with a list of ice-breaker type prompts.

Hangouts & IRC Meetups[edit]

We will arrange monthly IRC meetups. These will be a chance for mentees to converse in real time.

Goal-setting Process[edit]

Mentees will work with their mentor to define one or more goals they want to meet as part of the mentorship program. Many students will likely choose "Apply to Google Summer of Code" (or a similar program) as their goal, but additional goals can include:

  • Getting contributions merged. (Specific projects and kinds of contributions may vary - specificity is encouraged in goal-setting!)
  • Help 3 newcomers to a project.
  • Learn a particular skill such as git branching, resolving merge conflicts, or to achieve basic use a specific open source project such as R.
  • Write an article about getting started in open source (and get it published on the OpenHatch blog, opensource.com, etc).
  • Attend an in-person open source meetup.
  • Make their own project open source and accessible to newcomers.

Students will be considered to have "graduated" when they successfully complete their stated goals.

Pairing[edit]

As part of achieving their goals, students will be encouraged to pair with their mentors and with each other. We will aim for one pairing experience per mentee per month, ideally starting early in the mentorship program.

How Structure Meets Needs[edit]

* More instruction/repetition on the skills we teach at our events (IRC, version control, issue trackers, etc.)

This should be achieved, informally, through pairing and discussions with their mentor and perhaps also via the mailing list. However the program as currently defined does not inherently or systemically reinforce/extend our instruction.

* Help finding good projects (learning which ones exist, how to evaluate them, benefiting from our community's informal knowledge about which projects are most welcoming/responsive, etc)

This should be achieved, informally, through discussions with their mentor and perhaps also via the mailing list. However the program as currently defined does not inherently or systemically reinforce/extend our instruction.

* Help understanding community norms and structures that may be otherwise invisible (how long is normal for someone to respond to you and is it okay to ping them again, how FOSS projects functions without deadlines and assignments in an academic sense, development environment setup is frequently difficult it's not just you, FOSS can be harder for reflective learners than active learners, etc)

This should be achieved, informally, through discussions with their mentor and perhaps also via the mailing list. However the program as currently defined does not inherently or systemically reinforce/extend our instruction.

* A social network to increase feelings of belonging and enjoyment of participation. (Peers at a similar level of experience, role models who they can identify with and who feel approachable, a source of positive feedback for their work not just from the projects they're contributing to, a sense of shared values, a place to turn when they feel discouraged or like an impostor).

This is the main purpose of the mailing list and IRC meetups. Discussion prompts may be needed to direct the community towards these characteristics.

* Help finding "easy wins" to increase feelings of competence and belonging. (An easy win may be fixing an issue for a specific project we've helped them find, but could also involve helping others, or doing setup sprints or user feedback or other contributions that rely on and require their new-ness.)

The program is not currently set up to provide this.

* Help setting achievable goals. (Many students want to apply for GSoC/OPW but are intimidated, most aren't sure what they can contribute to a given project at their experience/skill level, many are confused/concerned about what kind of time commitment they're making, etc.)

This is the main purpose of the goal-setting portion of the program.

Selection[edit]

How Mentors Are Selected[edit]

I'm planning to run a pilot of the mentorship program this fall with just myself (and potentially also Asheesh, as needed) as mentors. People who are interested in being mentors in future iterations of the program should contact Shauna.

How Mentees Are Selected[edit]

Students interested in the program will fill out an application. This allows students to demonstrate a significant interest while allowing us to determine if they're a good fit for the program.

Diversity[edit]

It's unclear how popular this program will be, but if there is more demand than we can meet, we may want to prioritize mentoring under-represented students.


Action Items[edit]

  • Create application form for mentees.
  • Create announcement to send to past students.
  • Create mailing list & usage guidelines for mailing list.
  • Create website (or sub-page of campus.oh.org or oh.org) to host application and FAQ?
  • Create metrics for measuring success.

Further reading[edit]

Planning post

Mentoring in Floss Resources