# rust project burnout @ RustWeek 2025

- [organizing thread](https://rust-lang.zulipchat.com/#narrow/channel/486433-all-hands-2025/topic/Session.20about.20Burnout/with/517349315)
- ["working on rust kinda sucks"](https://hackmd.io/5n97FexORfiOjhFShK9HpA?view)
- [follow-up zulip thread](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/.28editable.29.20list.20of.20ways.20contributing.20to.20rust.20is.20frustrating/near/438985936)
- [blog post](https://jyn.dev/the-rust-project-has-a-burnout-problem/)

## stories
- feel ignored
- felt pressure is not proportional to the consequences
- "felt like i had to have something to show for it"
- people are not in control of outcomes
- switch between crickets and everyone giving bad feedback at once
- working purely through text is alienating
- feels good to meet people, esp. in person but also via video
- "talking to people wins again"
- foundation staff has gotten death threats
- no feedback loop for social problems, little positive feedback
- only person working on one particular thing
- if it's tedious, mark it as a good first issue
- feel forced to "poke holes" in new ideas
- time-critical things feel bad
- "feel stuck" because no one else will do it
- hard to know when to step away
- "actively say yes" instead of having to say no
- council and foudation solve this with terms; compiler team co-leads;
- people around you are burned out
- "teams as a whole are burned out"
- "quiet weeks"
- cargo explicitly said they don't have capacity - that's great, we should do that more
- absent team leads
## what is going wrong?
- code review is rough on both sides
- very long latency
- what to do if you don't get a review?
- 2 weeks is already a long time
- can we get triagebot to set `S-waiting-on-{author,review}` automatically?
- https://github.com/rust-lang/triagebot/issues/1994
- can we suggest people break large PRs into multiple smaller ones?
- interpersonal conflict
- feel obligated to review every change
- competing priorities for maintainers
- implementing / mentoring / triaging / reviewing
- teams have long meeting backlogs - sucks if you want to discuss your issue
- "not prioritizing is prioritizing"
- extremely rough onboarding for new maintainers
- make this a project goal?
- culture of mentorship
- need to be more deliberate about recruiting
- people notice they are not keeping up with reviews and take themselves off the list
- triagebot limits should help
- we should reflect reality in the queue
- should look at libs - went from 2 to 10 reviewers by asking all at once
- we have the same high standards even for changes that don't need it
- anyone who's ever contributed should be able to merge to rustc-dev-guide
- same for forge
- same for triage
- for rl/r, there isn't anything easy
- "no one wants to waste their time"
- nothing before an RFC
- "we start with a proposal"
- can we make an official process for brainstorming?
- https://medium.com/@ElizAyer/organizational-boundary-problems-too-many-cooks-or-not-enough-kitchens-2ddedc6de26a
- we should get rid of internals.rlo
- we could use rl/rfcs issues for early discussion
- experts are not getting assigned to review their area
- unclear who is still there
- terms solve this too
- have to consent to be committed
- [zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/392734-council/topic/explicit.20team.20membership.20term.20durations/with/518931131)
## what can we do differently?

- we should pin an issue for new contributors
- link to https://rustc-dev-guide.rust-lang.org/#what-should-i-work-on
- learn from GSOC: have a big spreadsheet tracking everything
- we should tell existing contributors *not* to grab easy things
- "good first issue" vs "good second issue"
- help mentors and mentees find each other
- add back an experts map? need to update it regularly
- maybe triagebot can suggest this on prs to rl/team
- could generate this automatically from git history
- have a pinned zulip thread
- maybe triage team can be involved?
- can suggest people join triage team
- make it easier for people to triage issues; should be giving away triage rights like candy
- [discussion of how people can join wg-triage](https://rust-lang.zulipchat.com/#narrow/channel/242269-t-release.2Ftriage/topic/procedures.20for.20joining.20the.20team.3F/with/518933906)
- can we have a feedback mechanism for people in the project to report internal issues?
- check-ins
- compiler-team allows members to opt-out of reviewing fcps
- unclear how crucial any given FCP is - we should expect the fcp author to write this up
## Notes
* jyn is leading the session because of experience with being burntout
* things that are not great about being involved in Rust:
* Some technical (e.g., RFC process)
* Some social
* Opens up to the crowd on the question "what are some sources of burn out?":
* people feel not empowered to do their
* interpersonal conflict
* code review (on both sides)
* long latency on reviews
* 2 weeks can be quite a while to sit with your changes without review
* Not enough capacity from maintainers
* need to make choices between review, working on things, mentoring others
* especially hard for newcomers to know what to do
* In particular it's hard for people to know what the consequences of their changes are
* No true on-boarding path
* Perhaps we need to improve our onboarding process instead of letting people figure it out on their own
* It helps to have someone mentor
* We need to be more deliberate about bringing people on board
* capacity is a real problem
* Backlog is to be expected but it is a problem when there are people actively working on things but blocked on something relatively small (e.g., review)
* from the maintainer perspective it can also be an issue
* Triage bot is gaining the ability to limit the number of open reviews and maybe that will help?
* Libs team helped things by recruiting a _batch_ of people because it's easier for people to volunteer to be 1 of 10 vs 1 of 3.
* High standards for even somewhat inconsequential changes
* Try to provide more places where changes can just be merged without the need for review
* We're probably be more restrictive on who can merge to e.g., forge
* Finding work:
* We have lots of people who would work on things if they knew what to work on
* Should we pin an issue for new contributors to push people towards the existing resources
* Google Summer of Code has a resource for finding things
* But how do we put together that resource
* We should encourage experienced contributors to not take on "good first issues".
* Some tags need adjustments (e-hard is _really_ hard and so everything kind of lands in e-medium)
* There's unfortunately not a ton of easy issues
* Helping mentors and mentees to find each other:
* Have some _very easy_ place to maintain a list of people who are experts and willing to mentor in a specific place
* expertise is hard to define and this will surely get out of date.
* git history can be useful here perhaps?
* mentoring can be a way to "socially" spread who is an expert in an area
* We could have a Zulip thread where people can just ask these types of questions
* More stories on burnout:
* waffle:
* caring about a specific lang thing
* caught in a circular dependency where the reviewer and reviewee where both waiting on each other
* demoralizing to be waiting
* wasted time in internals.rust-lang.org
* jyn: we should get rid of internals
* being a single person working on a specific thing
* feeling nervous about going on a camping trip because there was no one else to work on this thing
* somewhat solved by getting more people involved
* The actual consquences of not actually doing what was needed were smaller than the _perceived_ consequences
* project goals and grants
* pressure when you have a grant but can't show anything for it.
* social problems require hard work to solve
* often times you don't get good feedback about whether work to solve those problems is actually working or even appreciated
* issues on platforms like r/rust-lang
* mod team needs to be made aware of issues
* being able to talk about problems with other people can be a very useful tool
* if you're feeling alienated by the processes, talking with others can be very useful.
* There's often people who care one particular thing
* These people feel the need to be solely responsible for that one thing
* It would be nice if there were less of these "single issues" and the ability to spread the exisitng workpool around less issues
* It's hard to recruit others to care about your "one thing".
* our processes officially start with a proposal
* but there's lots of things that actually need to happen before, but there's not a ton of official processes happening before hand
* There's an issue where someone might have a solution proposal and some maintainer needs to take the time to poke holes in their solution
* We should figure out better ways to put the burden on the proposer to show that their idea is sound
* Taking on work that needs to be done
* Status quo: you have to actively step away
* Possible future: you have to actively commit to coninue
* We don't have a mechanism for checking-in
* We have some positions in the project that are term limited - it could be nice to have more "terms" for things so that people have an oportunity to contemplate whether they want to walk away or continue
* We can also more proactively move people to alumni because they can always come back
More stories:
* "I feel most burnt out when other people around me are burnt out"
* Entire teams can be burnt out
* Shot out to Cargo for previously stating when they felt that they didn't have enough capacity.
* Go has done this in the past
* Clippy will probably do something like this:
* Clippy will go on a short break with no new features to get "our house in order"
* Clippy seems healthy - why?
* Perhaps this can be attributed to onboarding being actively worked on in Clippy