> bug ridden garbage
> expect to be treated kindly
Do you see why the first might make someone doubt the second?
> expect to be treated kindly
Do you see why the first might make someone doubt the second?
If you don't know what you're doing and you don't know that you don't know what you're doing, then yes it's likely what you produce will be both bug ridden and garbage.
It takes time and patience to refine it into something good. It doesn't mean you shouldn't try.
If you, or anyone else -- colleague, stranger, whatever -- submitted bug-ridden garbage, I'd spend time and energy to review your contribution, give you constructive feedback to the best of my ability, and hope for the best.
Hell, most _production_ software is bug-ridden garbage. I've written lots of bug-ridden garbage. I'm just calling a spade a spade.
If this turns you off contributing to open source, I don't know what to tell you. It's just reality.
Or an accurate depiction of reality.
Far from it. In fact, the best thing about a correctness-oriented language like Rust is that you can immediately tell when stuff does not compute (the compiler will error out with a useful diagnostic, or else it will be in a small 'unsafe' block with easy to check safety conditions). Which makes it way easier to be less judgmental about all sorts of stuff.
Whenever people say that a skillful programmer can write well-working C++, I don't disagree, but in my experience it continues to fail on projects with more people involved.
If your project has size N=1, and you're skillful it's not an issue, if you have N=2 or N=3, you might still be able to review everything and find very competent contributors.
But for bigger N, at some point you'll have average or below average skilled contributors in the project, you won't be able to review all contributions.
A strongly typed language, strict compiler, standard formatter, and standard linter however can scale in this way.
Rust offers all of these.
You can treat people kindly without having to agree with their opinions, or taking their PRs. If you are already going to reply or interact with them, it costs the same to be kind as it does to be a jerk.
I think that having your PR rejected, no matter how "kindly" you phrase the rejection, is not going to feel good.
So "treating them kindly" and "rejecting their PR outright" is a contradiction. Sometimes you just have to tell someone their PR isn't going to work out; that it doesn't just need a few tweaks, but rather a start-from-scratch approach that's 100% different. Flowery language aside, that's going to sting.
The "game day" analogy is maybe not a great one, but I get what they're saying: Sometimes you can't afford to spend the time that would be required to educate everyone on exactly how to change their PR so it would be appropriate. Where truly "treating people kindly" would take more of a time commitment than writing the code yourself the correct way, where it would really mean training a junior developer up to mid-tier or senior developer level? It's just not compatible with getting the work done you're responsible for. You can't spend all of your time coddling every potential contributor.
So sometimes you just have to say, "Sorry, no, this PR just won't work." Where that's the kindest thing you can say given your constraints. Maybe that's all you mean by "kindness," but the person receiving that comment probably won't see it as very kind. Rejection simply never feels good.