# Contributor Survey Meeting

This is a very long meeting with a lot of discussion.
Not all discussion is recorded, and most of the info in the links is not
repeated. There is a links section with overviews.

## Links

- [Zulip Stream](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/planning.20meeting.202020.2E09.2E04)
+ [archive](https://zulip-archive.rust-lang.org/238009tcompilermeetings/37326planningmeeting20200904.html)
- [compiler-team issue](https://github.com/rust-lang/compiler-team/issues/318)
- [HackMD](https://hackmd.io/b-FKKh9DSnah-lj1NVKaAw) with survey overview.

### Various summaries

- **@oliver**'s summary: https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/planning.20meeting.202020.2E09.2E04/near/209098757
- **@Joshua Nelson**'s summary of **@Lokathor**'s user story: https://zulip-archive.rust-lang.org/238009tcompilermeetings/37326planningmeeting20200904.html#209238939
- **@Joshua Nelson**'s retrospective: https://zulip-archive.rust-lang.org/238009tcompilermeetings/37326planningmeeting20200904.html#211796942

## Announcements

- **@mark-i-m** is [stepping down from the Rust project](https://internals.rust-lang.org/t/until-we-meet-again/12985).

## Discussion

- Should we focus more on frequent contributors, new contributors, or contributors with only a few past PRs?
+ **@nikomatsakis**: the hardest thing is to retain folks after the first PR or two
+ **@mark-i-m**: there is only a small population that will ever become long-term contributors to begin with and the challenge is to get as many of them as possible
+ **@wesleywiser**: a lot of the work we need to do is completely infeasible for people to do one-off. We need to make the ramp from one-time contribution to regular contributor smoother.
+ **@matklad**: the more re-occuring contributors we have, the more mentors for first-time contributors
+ Seems to be a consensus that helping people become regular contributors is the biggest challenge.
- It would benefit all groups to streamline the contributing process
+ Make the compile/debug/edit cycle faster
+ `incremental = true` helps, but not enough
+ people are expecting "compiles in 5 minutes on a normal machine"

The following discussion is (mostly) organized by the group of contributors.

### Never had a PR merged

- currently for e-mentor issues, the person contributing has to contact the assigned/reviewer to get mentoring instructions. if we could have mentoring notes if possible on these issues, it would be easier for people to contribute
+ even short notes by experts are very helpful
+ **@nikomatsakis**: writing too much is sometimes counter productive, both because it never gets written and because people don't have to experiment and learn
- A common theme is "PR reviews are slow"
+ often people have a weekend to spare and are looking for something to work on that fits within that
+ matters more to frequent/intermittent contributors (editor's note: not sure I agree with this)
+ when contributing to no-rustc/std, e.g. cargo, often PRs sit there untouched forever
- Lack of E-mentor issues; people can't find something to work on
+ This is something T-compiler needs to do directly; it's not enough to have a project group
+ tracking and regularly creating E-mentor issues would be helpful
+ **@DPC**: I think it would be better to first look at existing e-mentor issues before adding more to the list
+ **@nikomatsakis**: E-mentor shouldn't be someone *willing* to mentor, it should be 'there are mentoring instructions'
- **@matklad**: We renamed E-mentor to E-has-instructions in RA for exactly this reason

### Contribute < 1 PR / month

- Churn in the contributing process
+ Documentation that moves
+ Changes in bootstrap
+ editor's note: renaming `library/` and `compiler/` also counts I think
- **@mark-i-m**: This group is mostly feeling growth pains
+ Hard to find work
+ Hard to find the status of an issue
+ Not clear how to join teams or working groups
+ Some other repos are not actively maintained
- **@pnkfelix**: each of these bullets seems like something we should add to `CONTRIBUTING.md`
- Some working groups are opt-in and some are by-invitation, adding to the confusion.
+ Joining a group is both an honor and a commitment
+ The people reading T-compiler/meeting is probably smaller than most team members expect.
+ Membership seems like it deserves a separate discussion.
- **@DPC**: what if instead of having E-mentor/E-easy, we have a place for people to ask for work? Then they won't have to search the issue tracker for old issues, instead people familiar with the teams can give them something easy.
+ General consensus this is a good idea, but unclear what the right platform is

### Contribute >= 1/month

Primary pain point is ergonomics.

- Compiler is the most frequently contributed-to codebase.
- Improving the rustc-dev-guide helps frequent contributors the most.
+ The dev-guide seems to be in good shape, but it's always good to have more content.
- Work done to help new contributors will also help frequent contributors
+ Various people found this surprising
- Compile times are a giant issue
+ Prevent people from becoming frequent contributors
+ Most people don't have a machine fast enough to build the compiler in < 1 hour
+ Biggest but also hardest problem
+ Are people aware of the right `config.toml` settings?
+ This would be helped by more stand-alone libraries.
+ People tend to use `x.py check` + CI
- Those that don't tend to have fast computers, and don't use slow ones at all for building rustc
- CI only helps for refactoring; anything that requires *running* the compiler is extremely painful
+ 15 minute turnarounds are too slow; frustrating, waste contributor time, merge conflicts
+ This spawned a separate topic in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/improving.20bootstrap.20times.20for.20contributor.20fun.20and.20profit.
- PRs lack context of why they are created
+ **@Joshua Nelson** suggested `S-waiting-on-help`

Meta: There needs to be someone assigned taking meetings notes; historically they just don't happen.

### User story: **@Lokathor** specifically avoids making PRs to rust-lang/rust

Blog post: <https://hackmd.io/RHyLd-27QXOR5AHa-oa6Fg?view>

(editor's note: see retrospective below)

#### Summary

- Compile times are very bad, especially building stage 1
- `git` is hard to use, especially rebasing
- `x.py defaults` are meant for CI, not contributors.
- Review latency is bad.
- dev-guide is organized poorly; but more than that, lots of info seems to only live in the heads of T-compiler
- Would be great to build `libstd` without only `cargo build` (editor's note: see also the following links, all of which ended up getting rejected)
+ [moving /library to a separate workspace](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Moving.20.2Flibrary.20to.20a.20new.20worksapce)
+ [building rustc with beta libstd](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Building.20rustc.20with.20beta.20libstd)
+ [move compiler to stable channel](https://zulip-archive.rust-lang.org/233931tcompilermajorchanges/35996MCPmovecompilercratestostableRustcompilerteam358.html)
+ [RIIR contributor entry point](https://zulip-archive.rust-lang.org/131828tcompiler/32334RIIRcontributorentrypoint.html)
- It's hard to find mentors.
- Using CI is very common
- First-time builds are a major issue, not just incremental builds
- `S-waiting-for-help` would help new contributors the most.
- New contributors don't know rustbot exists (editor's note: this has mostly been fixed by [homu#101](https://github.com/rust-lang/homu/pull/101) I think)

#### Retrospective

See [comment by **@Joshua Nelson**](https://zulip-archive.rust-lang.org/238009tcompilermeetings/37326planningmeeting20200904.html#211796942). TL;DR there have been a lot of improvements but there is also a lot of work left to do. The hardest issues are still review latency and compile times.

**@Joshua Nelson** discussed changing the triage process with WG-triage, but no changes have been made.

### Discussion that doesn't fit a category

- Using GDB is extremely painful because `--verbose` doesn't give you enough info to replicate what bootstrap is doing
+ `--on-fail=print-env` seems to have recently broken

### Action Items

- Create a place where people can ask for work
- RIIR contributor entrypoint
- Figure out how to improve compile times
- Add `S-waiting-on-help`
- Rename `E-mentor` to `E-has-instructions`