Blog | Linux Foundation

Behind the scenes of running Linux kernel Mentorship Programs

Written by Shuah Khan | Apr 4, 2023 4:13:03 PM

Image created with Bing Image Creator. tux the linux penguin, sitting at computer terminal programming shell scripts, with younger baby penguins observing digital art

We run the Linux kernel Mentorship programs three times a year, mentoring 25 people each session. In this blog, I will give you a behind-the-scenes view, starting from the project creation, application screening, mentee selection, running the session, and guiding mentees to the finish line.

Project definition

Clearly outlining the project is the important first step. The project details should include the scope, summary of the project, required skills necessary to complete the project, and the skills and outcomes mentees can expect to learn during the program.

Mentees will need a couple of weeks to get up to speed before they can begin contributing to the project. It is important to scope the project work so it can be completed within the duration of the mentorship program. Considering the learning curve, consider how the work can be divided and fit into the program time.

Another important aspect is deciding on graduation requirements for the project. This could vary depending on the nature of the project. A minimum number of patches and feature contributions is an example. 

In addition to a set number of patches, the criteria should take other measures, such as completing assignments during the program and demonstrable learning by mentees. This would include writing a blog at the end of the program as a final report. This blog is handy when mentees are invited to present their work at the Linux Foundation Mentorship Showcase.

Develop a screening process

The next step is identifying and developing the screening process. What does the screening process look like, and how do we assess who has the right skills to be accepted into the program? It is important to have a plan for each project's minimum acceptance criteria. It can be as simple as accepting everybody who completes the screening tests.

As a first step, derive the assessment criteria from the required skill set. For example, C and Shell proficiency are important to become a Linux kernel developer. There are several other criteria to look for besides the core technical skills. Here is a list of overall skills to look for to assess who is a good fit to be an open source developer.

  • Communication skills
  • Ability to go beyond the assigned skill test
  • Research skills in finding resources
  • Openness to receiving feedback and acting on it.

An open-ended skills test is a good way to assess the above. Communication skills are very important to function as an open source developer. I look for clearly stated goals in cover letters and resumes to assess what a mentee might want from participation. In addition, I include coding and patch generation assignments to get a feel for their technical and communication skills. Generating a complete patch with a commit log describing what the patch does and how feedback on the patch is received is a good indicator of communication and the ability to work with the community.

Including questions regarding a desire to participate full-time or part-time during the application and screening process is a good idea. This information will come in handy and save time during the selection process.

All Linux kernel Mentorship Projects require applicants to complete A Beginner’s Guide to Linux Kernel Development (LFD103) to understand how to work with the community. In addition, these tasks should test and teach a few skills to prepare them for the actual project work. Assessment tests could vary from project to project, depending on the project scope and work.

In addition, if the project is for fixing Linux kernel bugs, the screening tests are designed to assess basic debugging skills and serve as a primer to learn available Linux kernel features, scripts, and tools to debug. This approach to screening promotes learning during the application process. Based on my feedback, mentees appreciate this type of screening as they learn even if they don’t get selected.

Selection process

Selecting becomes straightforward once we have a good screening process and selection criteria. Even with a good screening and selection process and criteria, selecting suitable mentees can still be time-consuming and laborious, especially if a project receives many applications. The Linux kernel Mentorship projects usually receive 250+ applications for each session.

I usually have a good idea of the capabilities of each applicant by the time the selection process starts. By this time, I would have reviewed the code and patches from each applicant who completed the screening tests and other task assignments.

Project kickoff

I accept all mentees that complete the screening tests and assignments. This number can be as high as 25. There are a few challenges in mentoring this large number, and they require careful planning to minimize the overhead. We’ll get into this when I discuss how I run the project.

Once the selection process is complete and mentees are accepted, I will send them a welcome email outlining the expectations during the program and graduation requirements. 

I set the expectation that mentees should contribute a minimum number of patches to graduate. 5 to 10 patches depending on the complexity spanning documentation, testing, and other kernel areas, is a good number. For example, if the project is for fixing Linux kernel bugs, I ask mentees to pick two areas to focus on based on their interest within the first two weeks of the program. This process is flexible and accepts a patch even if it is still in review and a subsystem tree. In addition, it takes into account other demonstrable learning by mentees.

Running the project

As mentioned earlier, mentoring many people requires planning to reduce mentoring overhead. Holding 1-hour group office hour sessions twice a week is a good way to reduce time and promote group discussions among mentees so they can learn from each other. I encourage them to connect over chat and discord channels to connect and learn from each other. This approach has proven to be very successful.

The office hours are focused primarily on answering questions, sharing resources, and demonstrating tools and debugging techniques as needed. During the first two weeks, I help and guide mentees as they decide on their focus areas. These sessions are interactive and promote participation from all the mentees. Mentees share resources and patches they are working on during the group sessions. Mentees send patches to upstream mailing lists and the linux-kernel-mentees mailing list so other mentees can review their patches. Reviewing patches helps with learning the skill of reviewing, which will be beneficial in the long run as they continue contributing to the project.

I make a call on if two sessions a week is necessary as the program progresses. Based on the feedback, I might drop it down to one weekly session.

Learn, Leverage, Contribute: It’s the Open Source Way

I don’t do this alone. I have help from the community to leverage existing learning resources from Linux kernel documentation, and LF Live: Mentorship Series. I use all the resources I can find to provide enhanced learning opportunities. If resources are missing in some important areas, I reach out to experts in the Linux kernel community to host interactive webinars as part of the LF Live Mentorship Series. Hosting a webinar is an overhead commitment for experts and mentors with limited bandwidths to share their expertise.

The end game, or is there one?

At the end of the program, Mentees complete their work, final reports, and blogs to graduate. But Mentoring doesn’t end when mentees graduate; it continues with reviewing slides as they prepare for the LFX Mentorship Showcase. A few graduated mentees continue to co-mentor with me, and the cycle begins next session again.

About the Author: Shuah Khan is a Linux Foundation fellow and an upstream kernel maintainer and developer.

Resources