In-person - preparation

!!! Example "TL;DR" 1. Triage issues/tasks for the day 2. Prepare a quick pitch for your project (not needed for Git/general mentors) 3. Be prepared for an intense yet rewarding 4 hours - bring coffee/tea, and your best mentor/cheerleader/support attitude

Before the sprints¶

Selecting issues¶

Make sure your sprint is successful with careful planning ahead of time. As part of preparations, project leads/mentors will need to triage and prepare issue queues and identify what they want to work on in the sprint.

If you want to go the extra mile, choose one or more of the following strategies:

• Tagging issues with your mentored-sprints or PyCon-2023 in your project's repo makes them easier to find.
• Tagging issues for newcomers - they should be actionable, self-contained items folks can work on.
• Reserving easier, newcomer-appropriate issues for sprint newcomers ahead of time.

Make sure to find diverse issues: documentation, code, design, checking tutorials, working on social media packs or policies. There is no limit to the type or number of items you bring on the day, the more, the better!

As the day progresses, keep track of the issue numbers you’re working on. Track if they are assigned, who is working on them, and if they are done. Your issue queue might manage this, but it is always useful to keep track of stuff in case multiple folks end up working on the same item.

On the day of the sprints¶

Project mentors¶

1. Aim to be in the room 10 minutes before the start time - this will help up avoid distractions.
2. Introduce yourself and your project (if applicable).
3. Share the issues you triaged with the contributors.
4. There is a scheduled break - make sure to take it!

Please come prepared to give a 1-2 mins intro to the project you will be mentoring on. You do not need slides, but we want to give you time and space to make sure you introduce yourself and the project.

General and Git mentors¶

1. Introduce yourself - you do not need a pitch but be prepared to say hello (this is useful for folks to know who to ask help for)
2. Most of the help you will be providing on the day will focus on Git questions (merge conflicts, Git flow, rebasing) as well as debugging setup environments.

If you find that the room is too quiet and very few people are asking for general help, feel free to jump into a project table and support the mentors and attendees there.

Three ways to make it easier for newcomers to contribute¶

Helping new contributors get set up makes a huge impact.

• Researchers have found that the most significant barrier to open source code contribution is getting a local environment set up. Newcomers who spend a long time getting set up find it frustrating and demotivating. Gitpod is a great tool to help streamline the process. ( it can also make an excellent contribution for intermediate contributors).

• Show them where they can help - When preparing for your sprint, project leads should collect issues that need addressing for each project. To make it easier for people to find places they can share their expertise and enthusiasm, one recommendation is to group the issues by type of work, or expertise needed. Mozilla’s advice for newcomers on participation basics recommends that new people should "find a project they are interested in." We take care of this by inviting projects and encouraging attendees to check projects in advance.

• Learning-by-doing - The idea is that you reserve appropriate issues in the time leading up to the event. These types of issues will give contributors experience with whatever workflow you’re using while taking care of tasks that are relatively quick to resolve.

Helping newcomers commit changes to your project gives them a successful experience in your community and increases the likelihood they will come back for more. Furthermore, ownership and effort increase the perceived value of concepts, things, and projects to us. The feeling of knowing code you’ve checked, written, or influenced is being downloaded (tens or hundreds of) thousands of times a month can be a huge motivator.

Everyone has something to contribute¶

Be insistent that contribution sprints are for EVERYONE and make EVERYONE welcome, coder or not, independent of their background, skills, and experience. EVERYONE can contribute. Always communicate in advance that there are tasks for non-programmers (documentation, UX, manual testing, etc.). Everyone can help each other - when possible, encourage folks to work in teams of 2 or 3!

Motivate, support, say thank you!¶

Make sure to acknowledge and thank contributions - no matter how big, small or unexpected!

Make sure there is noise on social media. People are proud to be part of the action, both the team and the listeners out in the community, but there’s often no time or thought of it during the event itself; a post-sprint shoutout is always great. When doing so, use our official hashtag: #MentoredSprints