Mentoring suggestions

Last updated on
18 February 2021

This page provides some suggestions about how to be a good mentor.

Shorter, memorable URL for this page: drupal.org/core-mentoring/mentor-instructions

Focus on the outcome: returning contributors

A contribution day is for people who know what Drupal is and have worked with it in some capacity. We need a lot of different kinds of people to participate and contribute in different ways, not just via code. Yet, the most important thing to remember, for both mentors and contribution day participants, is to have fun.

Sometimes, trying new things and trying to understand new things can be confusing and frustrating. Contribution participants may feel that they are under pressure to contribute something. They may feel that they failed if they do not make what they think is a meaningful contribution.

It is important for both mentors and contribution participants to remember that contribution is a process. Drupal is compiled of lots of little tasks. We are all here to learn. So, have fun, try new things, and build on the knowledge that you have.

The most important outcome is that people will want to contribute again.

Celebrate small successes like posting a comment with a question, posting a screenshot, or posting a broken patch. Talk to new contributors and reflect with them on all they had to learn in order to do that so that they recognize that they have done something meaningful.

When a new contributor learns, has fun, and can see a result of their work (e.g., a comment on an issue), then they are more likely to continue contributing at home or attend another contribution day.

Get acquainted

Whether you are mentoring in person or online, it is helpful and welcoming to get to know the person or people you are mentoring:

  • At an in-person event: Put your name and drupal.org and chat user names on a name tag -- event badges are often not visible. Ask participants to do the same.
  • At an in-person event: See if there is some way to recognize mentors from the crowd.
  • In-person: Ask everyone you are mentoring to say "hello" to you in the designated chat channel.
  • Get to know people: Ask people their name, where they are from, and "What do you do with Drupal?" (an open question that is less intimidating than "Have you done ... before" or "do you know ...").
  • Introduce people to seasoned contributors working in their area, either in-person or in chat.

Set expectations

Ask new contributors why they are attending the contribution day and what they want to get out of attending the contribution day. They may want to contribute to Drupal Core by doing something they are already skilled at doing, or they might be at the contribution day to learn something new while contributing at the same time.

With that information, you can help them find something relevant to work on and match them up with others at the contribution day. Some hints on selecting a first task:

  • Ask the participant about his/her skills, experience, and interests.
  • If the participant is hesitant, vague, or unsure, try specific questions, like, "Do you have a local installation of Drupal that you can use for testing?" Or "Have you applied a patch before?" (Start with basic things and work up. We don't want to scare people away by asking them if they've done things they've never heard of.)
  • Search for issues together from the Novice issue tag or one of the "Needs..." tags. If you are at an in-person event, you can both look at their computer screen. If you are in text chat, you can start a thread where you can paste an issue search thread, and then look down the list and suggest possible issues. (See also Setting up for new contributors, which has more information on novice issues triage.)
  • Before deciding on an issue-based task with a participant, check the latest comments in the issue and make sure the task is still relevant. If an issue is tagged Novice, but does no longer meet the criteria of a good novice task, remove the Novice tag.
  • For returning contributors, if you have time and not too many people to mentor, consider reviewing an issue the participant has worked on in the past, and have them address your feedback.
  • Regardless of the participant's skill level, start with a simple, straightforward task. (E.g., no matter how experienced they are, don't assign them manual testing that involves mail sending, or an upgrade path test, or a patch review, etc.)

Also, with that information, you might want to talk with them about what reasonable expectations are for what they might accomplish at the contribution day. When their expectations are reasonable, they are more likely to have a better experience.

Check in regularly

  • Start by helping people find an appropriate task (see section above), suggesting they read the issue summary thoroughly (if it's an issue), and pointing them to documentation on how to get set up and how to do the task. The participant checklist may also be helpful.
  • As the day progresses, check in with open-ended questions, like "What are you working on?" and "How is it going?" rather than "Are you done with...?". "What are you working on?" is an open-ended question that creates an opening for the person to ask you questions or tell you that they are unsure about something. It is more respectful of the person's time and skills.
  • If someone is getting frustrated with a task, help them find a simpler one.
  • If someone completes a task well and is enthusiastic, help them find a more challenging one.
  • Make sure that any work that is done related to an issue ends up with a comment on the issue.
  • Give people a chance to remember or figure out a command, documentation url, etc... themselves, but if after 10 or 30 seconds, it hasn't come to them, provide the answer as well as how you got the answer.

You don't have to know everything

Being a good mentor does not mean knowing all the things. It is impossible for one person to know—or do—all the things. As a mentor, it is okay for you to ask for help or say, "I don't know."

Good mentors share what they know and how they know it and are open about what they do not know.

New contributors are often afraid to make comments on issues or change the status of an issue. They think that special permission is needed or that they should only post a comment when they know all the things.

It is important for people who are contributing to see that they do not have to know all the things. Seeing mentors say, "I don't know, but the way I would find out is by doing..." is really empowering for new contributors. They see that others they respect do not know all the things, and they learn how to further their understanding by finding out alongside their mentor.

Tell contributors that it's okay to post comments and questions to issues, even if they have doubts.

Talk in the open

It important that you do not talk in private (private chat or away from the table). When you speak publicly (at the table or in the designated chat channel), other people can learn from the conversation. In addition, others overhearing the conversation can clarify or correct a point so that you can learn, too. Open source your conversations!

Talking in public shows that asking questions is okay. Explain that it is safer to say the wrong thing in public because there are people who will correct it.

If you do not know the answer to a question, talk out loud and work with others to find the answer. Again, it is okay if you do not have a response to every question as it highlights to other contribution participants there are others in the community who are in the same boat—you can all learn something new, together!

Review first-time contributions

When someone you are mentoring completes a task (or is about to click Save to complete an issue update/comment), and especially if it is their first contribution, it is important for the mentor to review the contribution and provide constructive feedback. Pointers:

  • Read through the step-by-step instructions with the new contributor, and make sure all the steps were followed.
  • If the contributor added a comment to an issue, make sure the comment was constructive. See Issue etiquette (the pointers in the Being Constructive section are also quite helpful for mentors to keep in mind in providing constructive feedback).
  • If the contribution involves coding, review the code for coding standards, usability standards, accessibility standards, documentation standards, etc. If you find things that need improvement, point the new contributor towards guidelines in the area that needs attention.
  • Think about how you would have completed the task, vs. how the new contributor completed the task. If there are differences, figure out a constructive way to help the new contributor think about how they could improve their contribution.

Help improve this page

Page status: No known problems

You can: