The Rust project has a burnout problem

I am not sure what to do about the burnout problem. The way he described it is very on point though. Since everyone working on the project is overloaded there is a great feeling of things only get done if you do them.

Most of my open source work was in the pre-GitHub days when we used mailing lists, not pull requests, to build community. I do think there was something better about that for the project itself as it encouraged a lot more discussion and community building. PR's and Issues become silos and are not great for general discussion. I think they also encourage drive-by contributions which honestly are intoxicating initially but once you see people are not coming back become defeating.

When I was a schoolteacher, the way I expressed this is that you have to do the job in such a way today that you're capable of doing it again tomorrow. This did not go down well and I am no longer a teacher.

But it didn't start off that way. I shepherded it -almost entirely alone- for a decade, before I found a dedicated, motivated team that I trusted to take it over.

They have done wonders for it. Most of its explosive expansion has taken off, under their watch.

Walking away from it was the best thing that I could do for it. The last thing these folks need, is a "Benevolent Dictator," peering over their shoulders, and giving suggestions.

During the gestation decade, I had to be a not-so-benevolent dictator, many times, as people tried to take it over, change it to suit narrow sub-demographics (at the expense of everyone else), and even change its entire raison d'etre. I got a ton of pretty vicious hate mail and there are people that still hate me (I cry myself to sleep over that, every night), after a decade. In one instance, I had to wait until one nasty old bastard popped his clogs, before I could spread it to the entire Pacific Northwest.

During that time, I learned how not to behave. A lot of that hate, was because I'm actually pretty good at slapping back, but I really needed to learn diplomacy. Even when they are nasty, and we are right, we often need to just swallow our pride, and let the dervishes whirl.

I don't miss working on it, and I'm really glad the new team are doing so good with it. I suspect there's very little of my original code in it, but the team mindset is still very much what I established.

I am about to release a project that actually uses that infrastructure as a feeder to my backend.

Every team I've worked with that was feeling exhausted about code contributions actually needed to focus on better documenting guidelines but most importantly, improve CI. Catching silly mistakes is the textbook definition where automating stuff can help the most. This should improve reviewer's peace of mind and speed things up because people will work by themselves to fix things before asking for a review.

I don't know what's the CI situation in the Rust project but if it's anything like what I'm used to, it probably needs improvement. Adding more human-hours to reviewing things isn't sustainable.

Software in general has a burnout problem. I am regularly stumbling around like a zombie by friday afternoon, and that's just for my actual, paid job. If you added maintenance of a large open-source project like Rust ... I don't see how I would manage it, at least without letting my health -- and probably my family -- suffer for it.

I know that some people are fortunate enough to be paid for their open-source work, but that doesn't mitigate the burnout from software engineering itself. Add to that baseline stress the fact that your customer is "the internet" and feedback is often coming from "whoever is currently angriest," and it seems wildly unsustainable.

> “it won’t get done if i don’t do it” and “i need to review everything or stuff will slip through” is exactly the mindset of my own burnout from rust.

I've already caught myself getting into this mindset a few times.

For one particular issue, I got a bit mad because it felt like I was the only one trying to move a critical issue forward, and other people were treating it as a distant priority. In that case, what helped was moving away from the issue for a few days, and seeing other people pick up speed and make progress on it in the meantime. Having supportive colleagues is super helpful.

I don't know how much this will be a problem in the coming year. I'm hoping we can strike a healthy balance.

https://brson.github.io/2017/04/05/minimally-nice-maintainer

> rotate responsibilities. don’t have the same person assigned to the majority of PRs.

Every time I release something new, someone hates it.

It was hard for a bit, but I've been doing this for years.

Honestly you just gotta tune out the noise and prioritize what you want.

Open source project is a bit harder because you have to collaborate more than I have to collaborate with my gamer fans, but still, stop people pleasing and prioritize yourself.

Isn't this a characteristic of active contributors of many (or I daresay, most) large open source projects?

I am not an active contributor to any big OS project but whenever I stumble across the Github issues sections for one of them, they are full of "by when can we expect to see this fixed?" kind of questions.

It seems to have a disproportionately high, relatively to society, percentage of white, male, strongly LGBT-oriented personalities, who usually have a female Japanese cartoon character, or maybe a furry, as their profile picture on GitHub.

Which is fine, whatever, but I worry that it suffers from groupthink and excludes different minds. Maybe it's hostile to plain people that just want to focus on programming? I suspect that people like Torvalds wouldn't survive long, and that's a shame.

And if you want to be really critical: Maybe the leadership is happy that specific people are leaving? Maybe burnout is a tool? Maybe it's a way of social control and censorship?

I personally hope that Rust finds more mainstream support and funding, because I'd love to work full-time in Rust for many years to come.

I just wish they had python syntax, I'm not smart enough for {};

Sometimes the right answer is to immediately say "your PR is not up to project standards, it won't be reviewed, please revise it yourself if you want it accepted". It's not a job of a maintainer to educate every wannabe-contributor.

* Do not allow questions on GitHub issues, it's a poor place for conversations. I find Discourse or some other forum (or mailing list) a better place to do that, which allows community participation (and you can automate moderation using something like https://github.com/pierotofy/issuewhiz)

* People owe you nothing, just as you owe them nothing; you don't have to fix an issue or merge a pull request because somebody opened one.

* Try review and merge contributions, but on your own timeframe. If people have urgency, kindly invite them to get a paid support agreement.

* Don't engage in quarrels; you always have the option to ignore or ban the offenders.

* Document FAQs.

You can see with D, Rust, haskell, and whatever else, the transition to working on an ecosystem with easy to use and polished tools, IDEs, debuggers, autocompletion just never happens. The languages that get heavy use like C++, java and python solved the chicken and egg problem of having an ecosystem at some point where there was an actual workflow instead of just a hacked plugin and a command line.

The authors is pointing the best remedy, encourage and promote health work habits.

Oh, but I suppose that's not compatible with the "no one left behind"-type rust manifesto.

Consider: this attitude of nod and a wink “can’t name names” strongly contributes to burnout in every community i’ve seen it in. Rust has it in absolute spades, but i’ve seen it eat other groups alive too. Maybe we can stop doing it.

But if I don't work overtime how can I rewrite everything in Rust?