Stream: t-compiler/wg-learning

Topic: Where to get started for newcomers chapter


Chris Simpkins (Mar 26 2020 at 13:38, on Zulip):

This exchange with @centril led to an idea.

I think that it would be helpful to have a chapter in the first part of the Guide that points newcomers to "easy" entry points in the compiler. Ideally this would indicate areas that are both educational AND helpful, but we would err towards the educational side as a quickstart self-onboarding guide to both begin to learn rustc and contribute to its development simultaneously. IMO, this shouldn't only be about pointing to open "easy" issues or issues tagged as open to mentorship. It would be helpful to identify general areas of the source that a newcomer can feasibly touch, provide a brief explanation of what is "easy" to touch, and how to write a test around what a new developer touches. Beyond that, we could add the https://github.com/rust-lang/rust/labels/E-easy URL to point directly to E-easy tagged items and information on how to interact with expertise for assistance as you undertake your first "easy" contribution to rustc. There are open issues that offer mentorship and we might be able to formalize how that relationship works in the Guide (e.g., appropriate communication with your mentor- i.e., how not to annoy the hell out of your mentor which is always at the top of a newcomer's mind... :grinning: ).

Thoughts?

Santiago Pastorino (Mar 26 2020 at 13:40, on Zulip):

I like this idea :)

mark-i-m (Mar 26 2020 at 14:03, on Zulip):

Some thoughts: sometimes fixing/improving diagnostics _can_ be easy (sometimes it's really hard; see estabank's PRs). Also, I've found refactoring to be a good way of touching multiple parts of the compiler.

Chris Simpkins (Mar 26 2020 at 15:21, on Zulip):

Are there any details about mentorship available out there somewhere?

Chris Simpkins (Mar 26 2020 at 15:38, on Zulip):

mark-i-m said:

Some thoughts: sometimes fixing/improving diagnostics _can_ be easy (sometimes it's really hard; see estabank's PRs)

Maybe this isn't the best area for this chapter then?

Also, I've found refactoring to be a good way of touching multiple parts of the compiler.

How would a newcomer approach this in a fresh clone of the repository when they open it in their editor for the first time? Where is this welcomed, and importantly, where is it not? I think that those are the style of questions that we need to address. I am very much in this phase of the learning curve myself and these are the questions that I ask when I look at the source.

Chris Simpkins (Mar 26 2020 at 15:45, on Zulip):

I think that we can safely assume that a newcomer wants to (1) learn; (2) attempt to be helpful; (3) not waste their time on something that will never be acceptable in the project. And (3) is a big barrier early on because it assumes more detailed understanding of the project than they have.

mark-i-m (Mar 26 2020 at 22:47, on Zulip):

How would a newcomer approach this in a fresh clone of the repository when they open it in their editor for the first time? Where is this welcomed, and importantly, where is it not? I think that those are the style of questions that we need to address. I am very much in this phase of the learning curve myself and these are the questions that I ask when I look at the source.

@Chris Simpkins Not sure if this is the best approach, but I look at the C-cleanup issues on the compiler repo. Some of them are rather hard. But some are things like "remove all uses of X". Another option is to look through https://oli-obk.github.io/fixmeh/ until you find something that looks easy.

mark-i-m (Mar 26 2020 at 22:47, on Zulip):

Often after you start, you will hit some roadblock and you can hop on zulip/t-compiler and ask for help...

mark-i-m (Mar 26 2020 at 22:48, on Zulip):

Sometimes this will lead to a deadend or you will find out that some design work needs to be done. In this case, you're PR is not useful, but you've at least learned some basics of how to modify the code and possibly a bit about the design of somethign

mark-i-m (Mar 26 2020 at 22:50, on Zulip):

For example, my last 8 merged PRs are of this sort: https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Aclosed+author%3Amark-i-m

mark-i-m (Mar 26 2020 at 22:50, on Zulip):

You can take a look through the PR thread and see that I leaned heavily on eddyb...

Chris Simpkins (Mar 26 2020 at 23:12, on Zulip):

Thanks Mark! I will see if I can pull something together to explain all of this in the Guide.

Santiago Pastorino (Mar 27 2020 at 15:34, on Zulip):

another interesting idea I'd like if we can promote more is #t-compiler/help-wanted

Santiago Pastorino (Mar 27 2020 at 15:35, on Zulip):

I think that stream is under used and probably unknown by a lot of people due to lack of advertising

Santiago Pastorino (Mar 27 2020 at 15:35, on Zulip):

but the idea is that people that are working on things can ask for help about things they know how to solve but prefer that others can take the opportunity as a learning experience

Santiago Pastorino (Mar 27 2020 at 15:36, on Zulip):

at some point I had a list of things that I would have happily shared and helped people do the work

Santiago Pastorino (Mar 27 2020 at 15:36, on Zulip):

that's why I've started that stream

Santiago Pastorino (Mar 27 2020 at 15:36, on Zulip):

but didn't properly advertise it I guess

Chris Simpkins (Mar 27 2020 at 17:42, on Zulip):

These are very helpful suggestions! I will try to turn these into some documentation for a section in the Guide. Please keep these ideas coming! Thanks

mark-i-m (Mar 27 2020 at 20:51, on Zulip):

Oh I was unsure of what that stream was for

mark-i-m (Mar 27 2020 at 20:51, on Zulip):

Hmm... yeah, that maybe should be advertised more

Last update: Apr 03 2020 at 16:20UTC