The other extreme is a "bullshit job", work that you don't enjoy and which serves no meaningful purpose.
[0] https://www.bbc.com/worklife/article/20231010-the-acute-suic...
CI is good. more tests are good. but there's a limit to how much they can catch.
here is an example: there is an internal type checking API called [`resolve_vars_if_possible`](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/...). this needs to be called on the output of almost any call to `.normalize()`, or you will get an internal compiler error. the conditions under which you get an ICE are quite complicated; sometimes you need 6 or more items in the crate with `impl Trait` or type_alias_impl_trait or const generics involved. but it's very easy to see there's a bug just by looking at the code and seeing the missing `resolve_vars()` call.
how can we automate this? well, rustc has a mechanism for "internal lints", but they're somewhat annoying to write - you're basically writing a new compiler pass, and it needs to not have false positives. it's much easier to just catch this one instance. so the reviewer, who's already burned out, does this quick manual review instead.
And then that becomes a bit of a barrier to contribution -- it's a tradeoff
I often write an entirely new test harnesses for a feature, e.g. for https://www.oilshell.org, particularly using other implementations as "oracles". All of these run in the CI - https://www.oilshell.org/release/latest/quality.html
The good thing is that it definitely helps me accept PRs faster. Current contributors are good at this kind of exhaustive testing, but many PRs aren't
Even so, I do find myself simply adding test coverage from time-to-time -- that's an important job of a maintainer
1. writing in lowercase is freeing. it reminds me that grammatical rules are arbitrary, and by extension other rules. "you can just do things."
2. people who are pedantic about this when it's clearly intentional are probably not people i want to interact with anyway, so it's a good anti-asshole filter (https://siderea.dreamwidth.org/1209794.html)
You also need to close issues after a set amount of inactivity[2].
If there is a bug without a CVE, or a feature someone wants fixed that users don't want to submit a fix for themselves AFTER it has been discussed with the maintainer in an issue with a replication or strawman proposal and the owner has created a draft pr and asked you to work on it, it probably needs to come with a Patreon donation[3]. This can help alleviate maintainer burnout by allowing the maintainer to hire someone to make the contribution.
A software shop wouldn't operate without some kind of iterative plan. Large open source projects with single maintainers shouldn't either. Scheduling 1 or 2 hours a week for issue triage, hosted in an online meeting, and limiting WIP in terms of open PRs to be discussed during this triage meeting should allow for both community interaction and strong governance for the project and prevent burnout for the maintainer.
All of this can be placed into the Readme or Contributor guide and a CLA that contributors have to sign.
Otherwise, people can fork and maintain the project themselves.
If you want to prevent flame wars, or demotivating comments, something like a comment sentiment analysis app[4] might even be a good idea to add to your project. There are plenty of models available that you can delegate to for this in the wild, and it's worth automating moderation to prevent burnout.
Finally, really toxic users can and should be banned[5]. It's not worth it to deal with anonymous negative contributors all the time.
1. https://github.com/marketplace/actions/close-pull-request
2. https://github.com/marketplace/actions/issue-triage
3. https://github.blog/changelog/2023-10-03-sponsor-projects-th...
4. https://github.com/marketplace/comment-sentiment-analyzer
5. https://docs.github.com/en/communities/maintaining-your-safe...
https://github.com/orgs/community/discussions/13130
https://github.com/orgs/community/discussions/65343
The feedback is overwhelmingly negative, and has severely disrupted many people's workflow, but GitHub doesn't even acknowledge the problem.
https://arstechnica.com/gadgets/2018/09/linus-torvalds-apolo...
https://brson.github.io/2017/04/05/minimally-nice-maintainer
It seems like people making contributions to the C and C++ standards are also at risk of getting burnt out: https://thephd.dev/finally-embed-in-c23
> It was all worth it.
> …
> Or. That’s what I keep telling myself. Because it doesn’t feel like it was worth it. It feels like I wasted a lot of my life achieving something so ridiculously basic that it’s almost laughable. How utterly worthless I must consider myself, that hearing someone complain about putting data in C++ 5 years ago put me on the track to decide to try to put something in a programming language standard. That I had to fight this hard for table scraps off the Great C Standard’s table.
> What a life, huh?
Tailscale put it well: https://tailscale.com/blog/free-plan
> increased word-of-mouth from free plans sells the more valuable corporate plans
* 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.
[0] https://www.reddit.com/r/rust/comments/vyelva/why_are_there_...
I've seen brilliant colleagues for whom I have the utmost technical admiration completely fail to improve bad designs implemented by others, because the brilliant person was so dickish about how they communicated to others.
> Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
<3 i'm glad you enjoyed it
You gave an example of calling someone a dickhead and telling them to piss off, then said "I firmly believe all open-contribution projects need a Linus type of person", someone who will "be a bit of a dick when necessary"; if that isn't describing a "bouncer" role ... what is?
I'm not against showing people the door, I'm against the needlessly provocative and rude Linus style of doing that. You say "Meaningless question. I can prove that to you by turning it around: why choose a harder path? What is to gain?" then you say "I can protect people from my bad moods and bad days. I expect all people I interact with to do the same" - so I can ask the same question back - why choose the harder path when doing that? What is to gain? Obviously you can see it when it suits you, the intangibles of higher standards, trying to build something which is better than dog-eat-dog, might-makes-right, rudest-wins, flamewars everywhere world.
> "No idea why you fixated on me as some sort of an enemy but you have aimed wrongly. Severely so."
As I said repeatedly, you can run your personal project however you like, but you are here in a Rust discussion arguing that Rust shouldn't have problems of coordinating with people because you find it easy to swear at people and get rid of them, and all projects should be run like that. I am arguing against that.
> "The hell are you even talking about, and even bringing class / accent / nationality to the picture? It seems you just wanted to get stuff off of your chest and I was a convenient target. You're not even talking to me, again, you are talking to some fictional guy who does not exist."
I'm talking about the programmy world culture of "piss off dickhead, RTFM noob, I can say that because Linus did!" which permeates too much software development world. It's mistakes of correlation and causation thinking "Linus is clever and that excuses his bad behaviours, I'm clever so that excuses me behaving the same way" or "If Linus is successful and rude, if I'm rude I will be successful" or "If he can get away with it, I should be able to". Those patterns drive a kind of filter which is not meaningfully different from any other filter based on or only "the right people" can be involved - race, class, wealth, etc. being the traditional ones, and rude/smart/technical male being the common one in this scope.
Encouraging projects to be run that way, saying all projects should have someone being rude to people, is objectionable for similar reasons that the others are objectionable.
> "You conflate a very classic case of "fear of missing out" with "showing rude a-holes the door"."
And you conflate a case of "showing rude people the door" with "here's a place I can abuse people and get away with it, which is a good thing". This is showing a rude person the door without invoking flamewars (@dang): >>39037519
I'm not saying you have to behave like dang, I'm saying nobody is going to be quoting dang's epic flame putdown win over THIS asshole like people do with Linus' newsgroup posts, and that's a good thing.
Unsafe Rust is more complex to use than C in some ways. For example, an iterator for a slice, which contains two raw pointers, relies on the lifetime of the array it refers to lasting longer than the slice, and to encode this you need to use PhantomData [1]. Things like this make it look more arcane than plain C, simply because in C, this is implicit, and on the programmer to enforce.