# DRAFT RustcContributor Program (for discussion only)

Feature Name: rustc_contributor_program
Start Date: 2022–06–30
RFC PR: N/A (yet)
Rust Issue: N/A (yet)

---

Summary
The RustcContributor Program is the next iteration of what we previously called the Rustc Reading Club. This program is built upon the experience we've gained in delivering RRC and the retrospective we completed with the cohort. The predecessor program, the Rustc Reading Club is complete and now we are ready to launch the next phase based upon what we've learned.

## Motivation
The Rustc Contributor Program has two goals. First, to produce confident new contributors to rustc. Second, to deepen understanding of rustc for mid-level contributors. To support both of these goals, the program has two different components: RustcContributor::new and RustcContributor::grow these are explained below. will gain some experience with rustlang tooling and processes and practice contribution tasks. After completing ::new they will be ready to join a RustcContributor::grow cohort which is the second component of the program. The selection process needs more discussion and input from the complier team. A starting point for the discussion for the first month would look like the following.

## Guide-level explanation (need compiler team input)

- Before the program starts:
- take applications for a month
- assemble an initial cohort list
- recruit 1 instructor
- recruit 2 to 4 mentors for office hours

#### Week 1: Onboarding and installing things - instructor led for 90 mins via Zoom
- how to use your cloud desktop and get rustc running
- introduce rustc-dev-guide
- introduce rustc module/area
- install and setup additional environment: rr
- Q&A time permitting
- attend office hours when needed

#### Week 2: Setup and demo pernosco - instructor led for 90 mins via Zoom
- practice running rr traces
- practice setup for instructor to retrieve rr trace and upload to pernosco
- practice UI and access to pernosco
- Q&A time permitting
- attend office hours as needed

#### Week 3: Introduce selected rustc crate/module - instructor led 90 mins via Zoom
- present selected rustc crate/module
- opening a PR, what to expect “bors”, r+, etc
- Q&A time permitting
- attend office hours as needed

#### Week 4: How to complete a code review - instructor led for 90 mins via Zoom
- assign sample code reviews to submit
- practice
- Q&A time permitting
- attend office hours as needed

#### Week 5: Present and discuss solutions - instructor led for 90 mins via Zoom
- cohort practice tasks learned
- Q&A time permitting
- attend office hours as needed

#### Week 6: Retrospective - instructor led for 90 mins via Zoom
- cohort asks any remaining questions
- instructor led brief introduction to ::grow

#### Post Program
- join the next RustcContributor::grow cohort.
- PM manages adding ::new participants and filling out with other applicants

## Reference-level explanation
Support for RustcContributor::new and RustcContributor::grow will require support from the compiler team in addition to the financial support received from the Rust Foundation.

### Rust Foundation Support

* Compute accounts for all participants
* Unlimited upload pernosco accounts for instructors
* RustcContributor Challenge Coins

### Roles to recruit for

* Technical support -- 1 person or perhaps person per task
* Set up cloud desktop (oli)
* Set up pernos.co account
* Create the zulip stream (somebody from infra, other zulip admins)
* Make a rust team entry (anyone can do this by opening a PR to rust-lang/teams)
* Candidate application reviewers for the RustcContributor::new cohort
* `RustcContributor::new` (twice per year: spring/fall, each for 6 weeks)
* first time:
* content creation -- 1-3 people (oli/lqd/jackh726)
* each time:
* instructor -- 1 person -- 90 min/wk
* office hours -- 2-4 people -- 60 min/wk
* `RustcContributor::grow` (approx 4 per year, each for 8 weeks)
* each time:
* instructor -- 1 person -- 90 min/wk
* office hours?
* Program manager to...
* create calendar invites
* record, post recordings
* recruit

### Goals for the meeting

* [ ] Overview of the way the program will work
* [ ] Felix, Wesley to introductory blog as compiler-team co-leads on Inside Rust
* [ ] What kind of "decision" do we need here? (RFC, MCP, etc)?
* [ ] Suggestions for the people for each role

### Current filled roles of different people

* Doc Jones
* visionary, owns the program
* Felix, Wesley
* leads of Rust compiler team
* stakeholders, potential instructors
* we want them to help with recruiting and organizing other volunteers
* getting the team on board
* Niko
* potential instructor
* spirit animal :eagle: :fish:
* Tyler Mandry
* foundation board member but also an open source contributor
* stakeholder
* other roles as id'ed by Tyler

## comments, thoughts etc from the meeting

### nikomatsakis

> What is our output goal from this meeting? I think we should find some people who are keen to work on fine-tuning the content of each week, but probably not try to do it live except for broad strokes. Actually, what I think we should get out from this meeting is a rough draft of: "these are the skills we expect people to have by the end of `RustcContributor::new`". My sense is that new is meant to leave you with familiarity with tools and things, and a very high-level sketch of how rustc works, but no domain knowledge about any *particular part* of rustc. Then grow is meant to help with the domain knowledge over time.

One other question: I suspect each week should have some kind of activity. I remember Doc we spent a lot of time debating the merits of different kinds of things (e.g., adding fake bugs, etc). I guess I mean that just *exploring the tools* will work better if we have some *task* to complete with the tools, even if it's just answering some questions about how things work (which may be better, and more repeatable).

So I find pernosco really key but I wonder if it should be as central to our process yet. I think for most people `RUSTC_LOG` is more common, and even when using pernosco, I find I need the logs to "get my place". I think we should *start* with logging, for sure, and learning about some of the options to control the output, and then maybe show pernosco as a good way to "get context" (e.g., what was the stack when a particular log was output, and can I go back from that to other points in the log)

- wesleywiser: This point resonates with me. I've literally never used pernosco before so I probably wouldn't be able to help much with questions related to the tool.
- oli: same
- pnkfelix: egad all my pernos.co advocacy has fallen on deaf ears.
- nikomatsakis: uneducated barbarians, the lot of you (not felix)
- in all seriousness, [see this topic](https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/debugging.20failed.20PRs) for more thoughts about pernosco and challenges for widespread use (I was proposing we try to get pernosco runnable on any PR; I still like the idea but...)

### pnkfelix

#### testing

One item I do not currently see in the curriculum is discussion of rustc's test suite (i.e. how to run it, how to interpret its output, how to construct tests, etc). I suspect this could be a 90 minute lesson on its own, if done thoroughly; but my real question is: How *soon* should it occur in the currculum?

#### scheduling

Are there any firm deadlines/dates that we need to be aware of here?

### Doc
- niko reply: There is a section in the doc called Goals for the Meeting.
- pnkfelix:

### Tyler

What's the biggest thing you get out of this that you can't get from reading the rustc guide? How do we make that as good as possible?

Should we aim to introduce a few different parts of the compiler?

Maybe Pernosco is actually something existing contributors want to learn about – possible topic for RustcContributor::grow?

Success metrics? Retention, area of involvement, survey

### what skill level do we expect people to have at the end of this program?

e.g., to get something from the issue tracker and make progress on their own? be self-sufficient? or is it a onboard and maybe you know some people to talk to, but still need a lot of help to fix issues?

Doc: in RRC, we combined skill levels, found that didn't work. Want to prepare people who've not had experience with tools so that they can start the next `RustcContributor::grow`. The tooling is the goal initially. Introduction in the environment and being somewhat self sufficient. Grow will focus on the various modules people want to provide some insight into. For example, in RRC we went through the name resolver. That was a big one, prob not a good idea to try and tackle.

Goal:

* learn the tools in new
* learn about areas in grow

### How do we brand? should we be excluding std, clippy, etc?

Yes, we hope to expand, but compiler was obvious starting point.

Niko: Maybe we should just call it `RustContributor`...?

Wesley: this material could be really good for stdlib and other things, too

Felix: like going through college, later courses are more specific. you can imagine sample projects, things to review, that involve cross-cutting work (e.g., lang items). Some features require changing stdlib (like how iterator works). Example where you need to look at all the pieces to get it.

Doc: those ideas are exactly where I would like to see it go. But because we're doing this for the first time I'd like to see some iteration with the compiler team before we expand it.

general agreement that we should start with compiler and grow, some dickering about how to do it

### Dates?

Want to run the first iteration of `::new` in October

### guiding folks to where their skills are needed

tyler: Probably a lot of people want to be rust contributors generally, don't know where to start, i'm thinking of it as a away to guide people into different areas that can match their interest/skill-levels with needs of project. we have a guide you can read, but a bit advantage of this is having people you can talk to.

doc: expanding is where we want to go, we will generate videos/content that can be consumed by anyone at any time. we get that benefit out of conducting the program. I'd point to petrochenkov's name resolver tour, or felix's pernosco demo. that'd probably be redone.

niko: I think we should have a group of 2 folks to develop initial curriculum?

niko: but you also mentioned a kind of "Career counselor" role of helping people figure out what's next.

oli: feels like this brings structure to what is already happening (often poorly).

doc: our of RRC we had 2 people volunteering to contribute to name resolver, but we didn't have a mentor for them to get them started, ok, here's priority, what needs to get fixed. Not just mentors

oli: brings us to the point of connecting mentors with the parts of the code they are expect in. I've seen people show up recently around the name resolver on Zulip but I couldn't help them.

doc: that's the goal -- we have e.g. a tour of name resolver, but it's expert level. so we could have somebody break it down, present it for others. I see 3 levels of volunteers we really need

- experts to do the deep dive video
- instructors, without them we don't have a program
- support: technical support to set things up, mentors, support group

### what kind of buy-in etc do we need

MCP seems good

wesley: reach out to people who will want to fill in the roles, want to avoid everybody saying "seems great but I don't have time to do this". We would need a good explanation for what people are signing up for, what RustcContributor::new and grow is. new sounds like it could be anyone. grow otoh requires knowing a part of the compiler.

doc: you still have the setup for the compute

nikomatsakis: I expected it to be open to anyone who wants to join.

tyler: cloud compute we could tout, right?

doc: we talked about having compute available for everyone in the program, including grow participants.

### how do we measure success?

Retention of new volunteers? we have a problem that people come in, excited, maybe they get some mentorship, but then they disappear.

Sometimes they have their own reasons, but other times they're not feeling supported or engaged in the project, and they feel they are on the outside looking in. I think this is something this program could help change.

doc: I expect to do a retrospective with each cohort at the end of each session. That was super helpful. It was painful to have people excited and us not being able to really faciliate that. That's also top of mind. We have two people who could be contributing to the name resolver, and possible future instructors, but that didn't happen.

niko: when we pick the places to do grow, we need to think about "places that are actually unblocked to receive contribution", a lot of things are blocked on lang team discussion etc in name resolver for example.

tyler: we should reach out to them after N months since `new`, too, to see how it's going.

wesley: yeah, we have some areas (bugs, diagnostics) that are low friction, and others that require more sign-off (libs, lang, types, etc). I don't know that doing the work over however long it takes people to do it....if it is then going to take 6 months to lang this change, that'll be discouraging.

doc: I wanted to reduce gap between end of new and beginning of grow, so people can make that transition. I don't know the ideal gap, but prob not more than 2 weeks? Maybe 2 weeks is a good target?

### plan for next steps

* Step 1: Draft plan, review with this group
* need to include:
* the expectation of what people can do ("able to contribute, but don't know specifics of the compiler; know how to build/get-diagnostics/run-tests")
* mentors: set up zoom, hang out whether folks are there to see if they show up, try to have 2 so they don't get too bored
* Step 2: Identify likely candidates for each role
* Step 3: Review with people we expect would be good to fill the roles
* Step 4: Open the MCP or RFC
* Step 5: Wesley/Felix to write blog post making the announcement