-
Notifications
You must be signed in to change notification settings - Fork 70
Outreach mentor checklist
This page lists some of the tasks a Kata Containers outreach mentor should undertake.
By participating in a Kata Containers Outreach project you agree to be bound by the "mentors golden rule":
Mentors Golden Rule:
Keep asking the students if they need help, and if they do, help them!
Note: These are ideals only.
-
Lots of experience with Kata Containers and the community.
-
Minimum of two mentors per project.
-
Mentors in different timezones to each other
To maximise coverage time with students.
-
Mentors able to cover at least half the day in the students timezone.
When? | Category | Type | Task | Notes |
---|---|---|---|---|
week -1 | team | required | Identify code areas for students to work on | |
week -1 | team | required | Create a wiki page to record meeting updates (see the NDSU 2023Q1 page for an example) | |
week -1 | team | required | Identify potential list of tasks for students to work on (GitHub issue list ideally) | |
ℹ️weekly | team | required | Chair the weekly meeting and keep the meeting minutes wiki page updated | |
week 1 | team | required | Send contact details of all mentors to students | |
week 1 | team | required | Add GitHub and Slack usernames for all students to the outreach wiki page | GitHub user and Slack usernames only |
week 1 | team | required | Add all GitHub users to the outreach team | |
week 1 | team | required | Arrange a weekly status updates meeting (Zoom / MS Teams) at a suitable time for all students | |
week 1 | team | recommended | Arrange a second weekly meeting for presentations or simply to have extra talk time. | Helps keep project on track. Can be optional. |
week 1 | team | required | Talk students through the student checklist | Identify students without required skills |
week 1 | team | required | Ask each student what they particularly want to get out of the project | |
week 1 | team | recommended | Identify any upcoming public/personal holidays, exam weeks, end of term travel, etc | |
week 1 | team | essential | Work with students and teacher/professors to identify SMART task(s) for each student or group of students | |
week 2 | code | required | Ensure students have installed rust | Any problems? |
week 2 | code | required | Ensure students have installed Kata and created a Kata container | Any problems? |
week 2 | code | required | Discuss progress learning rust | Students should have attempted to write some rust code by this stage |
week 3 | familiarisation | recommended | Play with agent-ctl
|
Build it too |
week 3 | familiarisation | recommended | Play with kata-ctl
|
Build it too |
week 3 | rust | optional | Read This Week in Rust | Sources: https://github.com/rust-lang/this-week-in-rust |
ℹ️midpoint | team | required | Review progress | Discuss contingency plans if necessary |
ℹ️final week | team | required | Ask students for feedback on the overall project (good and bad!) | Add it to the ideas page |
final week | team | optional | Ask students if they would consider writing a blog post on Kata, the community, etc. |
The students will have a lot to learn potentially, so build up slowly to the "main" (bigger) tasks:
-
Encourage the students to read/write/learn rust from day 1!
Keep giving them this message. The only way to learn rust is to write it.
-
Help them to find a tiny, self contained
good-first-issue
to work onEven a typo spelling fix is good!
-
Once they have landed their first PR, help them to find a small rust issue to work on.
-
Once they have landed their first rust PR, they can move on to larger tasks.
They should now feel more comfortable with GitHub, the CI, the review process, rust tooling, the rust language, and Kata.
-
Recommend the students start using git from day 1!
Many students will need a lot of help to understand
git(1)
and GitHub.git
and GitHub combined are a complex system. The students will need to understand concepts such as fork, clone, local clone, branch, remote and rebase.Since editors with built in "git integration" hide important details from the user, recommend they use git on the command-line!
As an example, they could use git to keep track of notes on the progress they make by creating a git repo and adding a single markdown file into it.
Ensure students know of at least two other senior project members who can help if / when mentors are unavailable:
- Project members in the
#outreach
Slack channel. - Also, students should look at: https://github.com/kata-containers/community/wiki/Areas-of-interest
If the students are struggling, the following can help to keep them moving:
-
Arrange 1-on-1 meetings to discuss progress.
-
Form the students into larger groups.
-
Ensure the whole group of students are talking to each other (ideally daily) to discuss progress and problems (in their time zone).
-
Point the students at reference material and code examples, if possible.
-
If necessary, de-prioritise some of the functionality:
- This will make the task simpler, and thus more achievable.
- Get the students to raise a GitHub issue for the missing functionality so that others can work on this in the future.
-
Worst case, get them to change to a simpler task.
Ideally, they would complete the simpler task (which will raise their confidence), and then they can work on a second simpler task.
- Any opens/problems/concerns/worries?
- Round robin "status update" from each student:
- Achievements since the last meeting? Ideally "yes" 😄
- Any problems? Note: This should always be "yes" as we'd like to understand the issues faces and how they overcame them! Plus, it encourages the students to talk about (minor) issues as it will hopefully encourage them to raise any big issues later!
- Discuss plan for next meeting.
- Offer to present to students on particular topics of interest.
- Questions to ask students:
- What have you learned?
- What went well?
- What did not go so well?
- What would you do differently next time?
- What advice would you give to the next outreach students?
When? | Category | Type | Task | Notes |
---|---|---|---|---|
week 1 | read | strongly recommended | Talk through the project overview and onboarding presentation | |
first few weeks | contribute | strongly recommended | Present on how to run and write new unit tests | |
any time | code | recommended | async rust presentation | Most of the new code uses asynchronous rust, which requires a different programming paradigm |