---
# System prepended metadata

title: 'Mentoring: how and why'

---

# Mentoring: how and why

## The problem

[Contributor's churn and effort prioritization](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/MCP.3A.20move.20compiler.2F.20crates.20to.20stable.20Rust.20compiler-team.23358/near/210004024) towards goals such as:
- eliminating roadblocks
- more issues mentoring
- active working groups to attract prospect contributors

Prioritizing "hard" issues such as reducing compiling times or simplifying `./x.py` to avoid scaring away newcomers is an inefficient way of spending the limited time of existing contributors. The people we alienate are not motivated enough to stay anyway.
Building Rust is not like building any Rust project, an additional complexity should be expected and not frowned upon. Rather, we should improve the onboarding experience by improving the documentation.

Counter-point: faster compiler times and a easier understanding of the dreaded `./x.py` are not only roadblocks because of limited people's patience or [actual time slots they can allocate](https://old.reddit.com/r/rust/comments/irhj4o/blog_post_rust_in_2021/g52e0j7/) but has technical repercussions in other areas (such as an openbsd packaging). [And not only for newcomers](https://matklad.github.io/2020/09/12/rust-in-2021.html).

[Experiences when trying to recruit someone](https://rust-lang.zulipchat.com/#narrow/stream/233931-t-compiler.2Fmajor-changes/topic/MCP.3A.20move.20compiler.2F.20crates.20to.20stable.20Rust.20compiler-team.23358/near/210018632) to work on a compiler feature:
- All of them were puzzled about build timesof rustc.
- All of them complained about the imagined complexity of even a small change to the compiler.
- None of them even asked about a mentorship program, were seemingly unaware of it.

So the keypoint is to keep lowering barrier to entry, every "one time" contribution from a lot of people amounts in the end to hundreds (or thousand) of manhours you don't have to do yourself.

# The mentoring

Contributor's churn (see "the problem") and [thin time to dedicate to mentoring](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring) is a problem and a roadblock to onboarding new people.
We need to dedicate energies to train and mentor people, this is so important that [we should prioritize it in stead of doing additional work](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring/near/220982985). It's an investment in the future of the project.

[People showing up and asking to be spoonfed](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring/near/220997854) are more likely to disappear, because they don't have a strong motivation in the first place. People silently working and figuring the basics on their own are more likely to stick. Training anyone is a wasted effort of contributor's time, unless you have an upfront investment from the newcomer (example: a University internships).

[People go but also come back](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring/near/221003368). They prefer to start in the shadow, interfacing in private with existing core contributors before interacting in the open (possible reasons: being not confident and intimidated by exposing themselves to the public "judgment"). The mentoring process should become more organized.

[Mentoring is an investment with no certain return in all cases](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring/near/221008120). Regardless of being mentored or not there are people that:
a) show up, look around, ask questions and go away (and you have wasted time on them) or
b) you don't even see them because they work on their own in silence and then drop the ball

but the result is the same: they don't make it to their first PR because the compiler feels overwhelming (fact: some members of the `#t-compiler/wg-prioritization` bounced back to assigning priority labels to rust issues because of that).

The rustc dev guide is a work in progress and still not enough to get you the proper context to start. A mentorship program is a much needed complement.

[Also experienced hackers from other compiler projects](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring/near/221021472) are confused on there things are and struggle to build a mental model (example: figuring out how [the `#[global_allocator]` works](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring/near/221021472)).

There's also a different vocabulary between rustc and Rust itself or other parts other than the compiler. [Types and functions are sometimes non-descriptive](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring/near/221029638) and one cannot get a hint at a glance about what they are. The [internal docs](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mentoring/near/221029720) help but only if you're already "into it".

Introducing documentation such as the [lecturing series](https://internals.rust-lang.org/t/compiler-lecture-series/9227) is a good idea. Also initiatives like the [mentors list](https://rustbeginners.github.io/awesome-rust-mentors).

