26 ms·

> The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. Whether or not you a

> The fact is that most programmers do not have the patience, skill or experience to write half-decent code that isn't bug-ridden garbage. Whether or not you are right on this issue is this really the way to generalise about current / potential contributors? Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Edit: I’m making no point about quality or otherwise of contributions or whether maintainers should accept them. Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere.

iamthepieman 5y ago
"Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?" Because if they pass the bar knowing what it is then they also know that they're part of the club of developers who have the "patience, skill or experience to write half-decent code that isn't bug-ridden garbage."
xyzzy_plugh 5y ago
I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time. I've seen some truly impressive contributions over the years and the common element that stands out isn't the authors' skills or experience (even those can't always help you) but _patience_. Be kind, expect to be treated kindly, and just take your time. Breathe. If you receive feedback that bothers you, put it away. Sit on it and come back to in a week, or month, or whatever. Or walk away -- it's your choice. But the ones who are patient almost always succeed. And if it's the maintainers who lack patience, or they've dropped off the face of the earth -- just fork and move on with your life. That's the spirit of the whole thing, after all.
- klelatti 5y ago
  > bug ridden garbage > expect to be treated kindly Do you see why the first might make someone doubt the second?
  - xyzzy_plugh 5y ago
    I didn't give that feedback to a contributor. I didn't encourage maintainers to insult contributors. 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.
    - ghusbands 5y ago
      Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind, which will be visible in other ways and will turn some people away. It can help your outlook on the world and your impact on others to make an effort to think less negatively.
      - coldtea 5y ago
        >Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind Or an accurate depiction of reality.
      - zozbot234 5y ago
        > Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind 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.
        carlmr 5y ago
- oreally 5y ago
  'patience' that's why these projects never get many things moving forward and those higher up in the project's hierarchy seem to contribute way more. Also this is why younger, hungrier contributors should avoid these types of organizations and why these orgs will suffer sooner or later from certain bias. Ever heard of the quantity vs quality pottery story? You want to make mistakes and iterate on those to quality. Get the software working, then worry about styles and idiomatics. That seems lost on people nowadays.
  - mixedCase 5y ago
    That's what code review in a PR is for. Iterate all you need, and people experienced in the codebase will help you point out your mistakes so you can iterate some more until the maintenance burden you're shifting onto someone else is reasonable.
    - oreally 5y ago
      Sure you can do it in a PR. But this assumes that the feature is tested in isolation and not in conjunction with the rest the software. And the software really should be worked on as a whole.
- bluedino 5y ago
  > You need at least one of the three: patience, skill, experience. I had a boss who was a self-admitted terrible programmer. I witnessed some of the worst practices ever while working there. His quote was, "don't underestimate a persistent idiot (programmer) with a lot of time on his hands. He'll get it 'almost right', eventually"
OJFord 5y ago
Because you want to be able to make high quality contributions, you want to learn? If you don't have that desire and can't take critical feedback then it's not really a contribution that the maintainers want to be attempted, so that's fine. Nobody's saying the feedback is hostile or outright dismissive, and generally what I see (no experience with LKML specifically but I assume the same) isn't. It might get there if it's repeated, or the author shows no interest in improving just 'pls merge works for me' sort of thing - but by that point what's in it for the maintainers to be soft and encouraging, if there's no willingness or cooperation?
- klelatti 5y ago
  > bug ridden garbage This is what I was reacting to. Does this suggest that the feedback is likely to be constructive?
  - coldtea 5y ago
    The feedback can be very constructive despite the language. Or even because of it - as this kind of language can mean "I wont sugarcoat it, I'll say it like it is". It's up to the receiver of that feedback to be able to see this.
  - OJFord 5y ago
    I don't know about you, but I think I'm capable of polite conversation with someone whom I believe to be talking nonsense; or being friendly in discussing something I think is no good. (In fact, maybe I'm willing to offer an example.. :/ - https://github.com/posquit0/Awesome-CV/pull/372#pullrequestreview-812788398 https://github.com/posquit0/Awesome-CV/pull/372#pullrequestr... - could have been better perhaps, but I don't think it's too off-putting if the author has a legitimate change they want in, and surely they'd see the problem, I don't think it looks like gate-keeping pedantry? (NB the repo was unmaintained, I was recently added as a collaborator, so older issues/PRs with no maintainer response aren't a counter-example, I'm just in the process of sorting through them.)) The author of that comment was talking to us about low quality PRs, not a specific one, to an author of one, nor in feedback comments on one.
Etheryte 5y ago
As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, and from the offset it's often not so straightforward to figure out which one you're dealing with. It isn't constructive to think of a contribution as a gift, if anything, it's a Greek gift [0]: contributing to an open source project creates more work for the maintainers, both in reviewing the contribution and then later on maintaining it. If the contribution is good, it offsets those costs, but oftentimes it is not the case. Don't get me wrong, there are countless brilliant people out there who are doing great work more or less for free in the way of contributing. I'm also very grateful for good contributions. Those contributions are the exception though, not the norm. [0] https://en.wikipedia.org/wiki/Greek_gift_sacrifice https://en.wikipedia.org/wiki/Greek_gift_sacrifice
- DannyBee 5y ago
  "As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, " I've contributed to hundreds of projects, and maintained a ton, so i feel this pain, so please take what i say in that vein :) The question i usually ask when i see this is: "What is the thing you did that you think should have caused people's behavior to change?" Assuming you want this to be different, what actions are you taking that should have changed this? If they didn't, what did you learn and try? I'm not suggesting you will get to some perfect place where all contributions are great, but if you really want to improve them overall, you have to be doing things to improve the behaviors you see, seeing whether they work, and iterating, until you get the behavior you want out of most contributors.
  - andkon 5y ago
    Wowwww this is lovely! Have you written anywhere about what you've done on the projects you've maintained along these lines? I think we'd all benefit from hearing more about what you can do in a project to make contributors more capable and helpful. After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems like time well spent for everyone.
salamander014 5y ago
The fact is, most people can't write bug free code, that is also maintainable. It's a skill that takes years to hone. Even someone that is smart enough to understand all possible code paths and can prove it is bug free, doesn't automatically mean the code is written in a way that is easy to maintain. Also, open source goes both ways. Anyone can submit, but maintainers can deny. Their project, their right. Please remember, the bar has been set this high by successful projects. One of the reasons Linux became the world's most used OS kernel was because of the high standard Linus maintained for his project. (Not saying I agree with his colorful word choices, but in my opinion most of the time he was 100% right about the PRs.) That's why he calls himself benevolent dictator for life. The high standards must be maintained for the project to continue to be successful.
temac 5y ago
While the comment was overgeneralizing, the code will be rejected (actually, it won't even be rejected in a final way, just feedback will be given about how provide a better version that has chances to be integrated) if the code has actual problems (or at least perceived problems in the eye of the maintainer but in some case we are talking about concrete actual correctness problems that are not a matter of opinion but of pure logic), not just if there is an hypothetical risk that problems would be found if the code was reviewed. The efforts are mostly irrelevant if the result has serious problems. And the maintainers also spend some effort to provide the feedback. Which is fair if they say they are open to contributions: effort is provided by contributors, they provide efforts to review. What they can't do, is magically make contributors good enough. So anyone can attempt to contribute if they are ready to take seriously into account the feedback. In case of over-the-top maintainers who are not reasonable about what they want esp. if this is not about logic defects but about vague opinions, yes obviously you don't have to contribute to their project once you figure out they are chronically unreasonable.
jasode 5y ago
>Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? [...] Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere. I think you missed the gp's point of bringing up the example from the long history of Linux kernel contributions. It's a counterexample to your intuition that people won't attempt to contribute if there's a "hostile atmosphere" (scare quotes) to bad code. So even though Linus Torvalds and his trusted lieutenants constantly complain about terrible buggy code that wastes their time, Linux still attracts new contributors (and this means more "bug ridden garbage"). EDIT add specific example... I think this 2014 Linus Torvalds complaint about programmer's bad code from has the "unwelcoming atmosphere" you probably wouldn't like : http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html ... and yet people keep attempting to contribute to the Linux kernel project.
- stormbrew 5y ago
  .. Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through and it would still seem like there were no barriers. This is just survivorship bias.
  - jasode 5y ago
    >Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through Your comparison is flawed because you're leaving out the fact that the Torvald's Linux kernel was also a tiny niche project in 1991 and that atmosphere of harsh critique has been there from the beginning. And yet programmers kept contributing code to Torvald's small project in the 1990s and that evidence of behavior contradicts the gp's rhetorical question of: "Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?" Linux wasn't on a million devices in 1990s so mentioning that later fact is not relevant to its survival characteristics.
xyzzy_plugh 5y ago
Since you edited: I think you're misconstruing what I'm saying. I'm not selling an atmosphere. I'm writing a comment on this website. I don't have a project for you to decide to contribute to. I don't think anyone is suggesting that anyone's efforts should be dismissed impolitely -- but that's not what's being discussed here.
- klelatti 5y ago
  'Most programmers / contributors can only produce bug ridden garbage. Not you obviously!' Can you see the issue here?
coldtea 5y ago
>Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Isn't the parent's whole point to discourage them from contributing?
wyager 5y ago
> Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? I think most people who can make positive contributions are aware that they can do so. There are also a bunch of people who can't but think they can, which is fine, but they need to be understanding when their PR gets feedback or turned down outright. Contributing to someone else's project is both a gift and a burden for the maintainer, so contributors need to have humility about the net value of what they're contributing. If code isn't up to the maintainers' standards, the imposition on the maintainers may exceed the value to the project. If this isn't a risk a submitter can tolerate, it's unlikely that their contribution would be a net positive. Most communities have healthy expectations about participation in certain activities being contingent on a certain level of experience/skill so that participation does not impose an undue risk or cost on the community. Open source post-2010 has a very abnormal and unrealistic ideal of encouraging everyone to be involved at all points in the process at every skill and experience level. It's perfectly reasonable to have a feedback mechanism where you tell people to get good/lurk more/work on their backhand/etc. before engaging with the community at a certain level, so as to prevent the cost of managing their contribution from exceeding its value.
- klelatti 5y ago
  I think this is well put. If anyone suggests saying that someone or a group is only capable (for whatever reason) of producing 'bug ridden garbage' in any context, then I'd politely suggest that this isn't the best way to communicate the issue.
asimpletune 5y ago
I think I often see this disconnect, with developers on either one side or the other, and usually the distinguishing factor has to do with what their experiences have been. If you've ever maintained, like, anything - not even necessarily open source but even something at work (with users obviously) - for a significant period of time, long enough to see how a project evolves over time, you'd just... understand. People without that experience can at times be a little too demanding when they don't get exactly what they want the first time. At times the may even act out, often in ways that are actually harmful, like trying to get managers involved to override something, writing negative stuff about you or your project online, or in general getting fairly hysterical and creating a fuss. When you try to help them they get super defensive, often before putting in the effort to understand what it is you even said. So it's certainly the case that "bug ridden garbage" isn't optimal vernacular, but at the same, what I think can be worse is, as far as communication problems go, nitpicking project maintainer's communication whilst a.) not understanding that their underlying point remains actually true (I.e. "bug ridden garbage"), albeit not beautifully articulated and b.) not giving them the benefit of the doubt in terms of what their intent was. Now imagine this, but literally all the time, all day, every day, etc... it can wear you down a little thin. Basically, when someone doesn't understand something, which is why the code needs to be reviewed in the first place, some tend to kind of lash out while latching onto something else they do know, e.g. I know that "bug ridden garbage" isn't a graceful way to talk, so I'll attack that. Anyway, I'm probably not explaining this very well, and I think it's just something that people need to experience themselves. I've come to take people who are rough more as a compliment than anything, thinking, "this person thinks highly enough about me that they can just say what they really think, so I better not disappoint them by taking that trust and trashing it", obviously there are limitations, but this has helped me so much to learn from people smarter and more experienced than myself. I'll just say one last thing. From what I've seen, the people who do tend to get defensive and kind of nitpicky about maintainer communication tend to not succeed when they become project leads themselves, and they usually just change jobs. O and obviously the maintainers who have the ability/experience and are blessed with grace, diplomacy, communication skills or however you want to call it, obviously tend to enjoy the most success.
ChrisMarshallNY 5y ago
There's a chap named Linus, who is rather well-known for being a tough PR reviewer... I feel that if we are talking a fundamental toolbox, like a language, standard library, or kernel, then being a perfectionist is pretty much required. For myself, I agree that harsh language isn't particularly helpful, but I have extremely high personal standards. I seldom project them onto others, but if anyone wants to play in my sandbox, then they play by my rules.
chucksmash 5y ago
> Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Because they are adults with enough emotional maturity to not require constant encouragement in every aspect of life. It's one thing to make negative, targeted statements against an individual contributor. It's another to make a likely true, slightly negative outlook about the quality of contributions on average. Potential contributors should be responsible for maintaining their own emotional equilibrium in such a case, in my opinion.

iamthepieman 5y ago

"Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?" Because if they pass the bar knowing what it is then they also know that they're part of the club of developers who have the "patience, skill or experience to write half-decent code that isn't bug-ridden garbage."

xyzzy_plugh 5y ago

I don't think this is an unfair generalization. You need at least one of the three: patience, skill, experience. I am not sure who would argue with that. If you lack skill and experience, it's no problem. But if you begin to get frustrated as soon as you receive feedback... you're going to have a bad time. I've seen some truly impressive contributions over the years and the common element that stands out isn't the authors' skills or experience (even those can't always help you) but _patience_. Be kind, expect to be treated kindly, and just take your time. Breathe. If you receive feedback that bothers you, put it away. Sit on it and come back to in a week, or month, or whatever. Or walk away -- it's your choice. But the ones who are patient almost always succeed. And if it's the maintainers who lack patience, or they've dropped off the face of the earth -- just fork and move on with your life. That's the spirit of the whole thing, after all.

klelatti 5y ago
> bug ridden garbage > expect to be treated kindly Do you see why the first might make someone doubt the second?
- xyzzy_plugh 5y ago
  I didn't give that feedback to a contributor. I didn't encourage maintainers to insult contributors. 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.
  - ghusbands 5y ago
    Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind, which will be visible in other ways and will turn some people away. It can help your outlook on the world and your impact on others to make an effort to think less negatively.
    - coldtea 5y ago
      >Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind Or an accurate depiction of reality.
    - zozbot234 5y ago
      > Describing some code as "bug-ridden garbage" betrays a negatively judgmental frame of mind 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.
      - carlmr 5y ago
oreally 5y ago
'patience' that's why these projects never get many things moving forward and those higher up in the project's hierarchy seem to contribute way more. Also this is why younger, hungrier contributors should avoid these types of organizations and why these orgs will suffer sooner or later from certain bias. Ever heard of the quantity vs quality pottery story? You want to make mistakes and iterate on those to quality. Get the software working, then worry about styles and idiomatics. That seems lost on people nowadays.
- mixedCase 5y ago
  That's what code review in a PR is for. Iterate all you need, and people experienced in the codebase will help you point out your mistakes so you can iterate some more until the maintenance burden you're shifting onto someone else is reasonable.
  - oreally 5y ago
    Sure you can do it in a PR. But this assumes that the feature is tested in isolation and not in conjunction with the rest the software. And the software really should be worked on as a whole.
bluedino 5y ago
> You need at least one of the three: patience, skill, experience. I had a boss who was a self-admitted terrible programmer. I witnessed some of the worst practices ever while working there. His quote was, "don't underestimate a persistent idiot (programmer) with a lot of time on his hands. He'll get it 'almost right', eventually"

OJFord 5y ago

Because you want to be able to make high quality contributions, you want to learn? If you don't have that desire and can't take critical feedback then it's not really a contribution that the maintainers want to be attempted, so that's fine. Nobody's saying the feedback is hostile or outright dismissive, and generally what I see (no experience with LKML specifically but I assume the same) isn't. It might get there if it's repeated, or the author shows no interest in improving just 'pls merge works for me' sort of thing - but by that point what's in it for the maintainers to be soft and encouraging, if there's no willingness or cooperation?

klelatti 5y ago
> bug ridden garbage This is what I was reacting to. Does this suggest that the feedback is likely to be constructive?
- coldtea 5y ago
  The feedback can be very constructive despite the language. Or even because of it - as this kind of language can mean "I wont sugarcoat it, I'll say it like it is". It's up to the receiver of that feedback to be able to see this.
- OJFord 5y ago
  I don't know about you, but I think I'm capable of polite conversation with someone whom I believe to be talking nonsense; or being friendly in discussing something I think is no good. (In fact, maybe I'm willing to offer an example.. :/ - https://github.com/posquit0/Awesome-CV/pull/372#pullrequestreview-812788398 https://github.com/posquit0/Awesome-CV/pull/372#pullrequestr... - could have been better perhaps, but I don't think it's too off-putting if the author has a legitimate change they want in, and surely they'd see the problem, I don't think it looks like gate-keeping pedantry? (NB the repo was unmaintained, I was recently added as a collaborator, so older issues/PRs with no maintainer response aren't a counter-example, I'm just in the process of sorting through them.)) The author of that comment was talking to us about low quality PRs, not a specific one, to an author of one, nor in feedback comments on one.

Etheryte 5y ago

As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, and from the offset it's often not so straightforward to figure out which one you're dealing with. It isn't constructive to think of a contribution as a gift, if anything, it's a Greek gift [0]: contributing to an open source project creates more work for the maintainers, both in reviewing the contribution and then later on maintaining it. If the contribution is good, it offsets those costs, but oftentimes it is not the case. Don't get me wrong, there are countless brilliant people out there who are doing great work more or less for free in the way of contributing. I'm also very grateful for good contributions. Those contributions are the exception though, not the norm. [0] https://en.wikipedia.org/wiki/Greek_gift_sacrifice https://en.wikipedia.org/wiki/Greek_gift_sacrifice

DannyBee 5y ago
"As an open source author and maintainer, I think you're looking at this from the wrong way around. Good contributions are not the norm, they're the exception, " I've contributed to hundreds of projects, and maintained a ton, so i feel this pain, so please take what i say in that vein :) The question i usually ask when i see this is: "What is the thing you did that you think should have caused people's behavior to change?" Assuming you want this to be different, what actions are you taking that should have changed this? If they didn't, what did you learn and try? I'm not suggesting you will get to some perfect place where all contributions are great, but if you really want to improve them overall, you have to be doing things to improve the behaviors you see, seeing whether they work, and iterating, until you get the behavior you want out of most contributors.
- andkon 5y ago
  Wowwww this is lovely! Have you written anywhere about what you've done on the projects you've maintained along these lines? I think we'd all benefit from hearing more about what you can do in a project to make contributors more capable and helpful. After all, it seems like their incentives should align? Like, why wouldn't they want to make a contribution that actually helps? Making that easier to actually do seems like time well spent for everyone.

salamander014 5y ago

The fact is, most people can't write bug free code, that is also maintainable. It's a skill that takes years to hone. Even someone that is smart enough to understand all possible code paths and can prove it is bug free, doesn't automatically mean the code is written in a way that is easy to maintain. Also, open source goes both ways. Anyone can submit, but maintainers can deny. Their project, their right. Please remember, the bar has been set this high by successful projects. One of the reasons Linux became the world's most used OS kernel was because of the high standard Linus maintained for his project. (Not saying I agree with his colorful word choices, but in my opinion most of the time he was 100% right about the PRs.) That's why he calls himself benevolent dictator for life. The high standards must be maintained for the project to continue to be successful.

temac 5y ago

While the comment was overgeneralizing, the code will be rejected (actually, it won't even be rejected in a final way, just feedback will be given about how provide a better version that has chances to be integrated) if the code has actual problems (or at least perceived problems in the eye of the maintainer but in some case we are talking about concrete actual correctness problems that are not a matter of opinion but of pure logic), not just if there is an hypothetical risk that problems would be found if the code was reviewed. The efforts are mostly irrelevant if the result has serious problems. And the maintainers also spend some effort to provide the feedback. Which is fair if they say they are open to contributions: effort is provided by contributors, they provide efforts to review. What they can't do, is magically make contributors good enough. So anyone can attempt to contribute if they are ready to take seriously into account the feedback. In case of over-the-top maintainers who are not reasonable about what they want esp. if this is not about logic defects but about vague opinions, yes obviously you don't have to contribute to their project once you figure out they are chronically unreasonable.

jasode 5y ago

>Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? [...] Just that phrases like ‘bug ridden garbage’ don’t suggest a welcoming atmosphere. I think you missed the gp's point of bringing up the example from the long history of Linux kernel contributions. It's a counterexample to your intuition that people won't attempt to contribute if there's a "hostile atmosphere" (scare quotes) to bad code. So even though Linus Torvalds and his trusted lieutenants constantly complain about terrible buggy code that wastes their time, Linux still attracts new contributors (and this means more "bug ridden garbage"). EDIT add specific example... I think this 2014 Linus Torvalds complaint about programmer's bad code from has the "unwelcoming atmosphere" you probably wouldn't like : http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html http://lkml.iu.edu/hypermail/linux/kernel/1404.0/01331.html ... and yet people keep attempting to contribute to the Linux kernel project.

stormbrew 5y ago
.. Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through and it would still seem like there were no barriers. This is just survivorship bias.
- jasode 5y ago
  >Do you not see the difference between the linux kernel used on many millions of devices and a terminal emulator with a niche audience? 100 people could be turned off from pursuing their contributions to linux to completion for every 1 person who manages to get something through Your comparison is flawed because you're leaving out the fact that the Torvald's Linux kernel was also a tiny niche project in 1991 and that atmosphere of harsh critique has been there from the beginning. And yet programmers kept contributing code to Torvald's small project in the 1990s and that evidence of behavior contradicts the gp's rhetorical question of: "Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way?" Linux wasn't on a million devices in 1990s so mentioning that later fact is not relevant to its survival characteristics.

xyzzy_plugh 5y ago

Since you edited: I think you're misconstruing what I'm saying. I'm not selling an atmosphere. I'm writing a comment on this website. I don't have a project for you to decide to contribute to. I don't think anyone is suggesting that anyone's efforts should be dismissed impolitely -- but that's not what's being discussed here.

klelatti 5y ago
'Most programmers / contributors can only produce bug ridden garbage. Not you obviously!' Can you see the issue here?

coldtea 5y ago

>Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Isn't the parent's whole point to discourage them from contributing?

wyager 5y ago

> Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? I think most people who can make positive contributions are aware that they can do so. There are also a bunch of people who can't but think they can, which is fine, but they need to be understanding when their PR gets feedback or turned down outright. Contributing to someone else's project is both a gift and a burden for the maintainer, so contributors need to have humility about the net value of what they're contributing. If code isn't up to the maintainers' standards, the imposition on the maintainers may exceed the value to the project. If this isn't a risk a submitter can tolerate, it's unlikely that their contribution would be a net positive. Most communities have healthy expectations about participation in certain activities being contingent on a certain level of experience/skill so that participation does not impose an undue risk or cost on the community. Open source post-2010 has a very abnormal and unrealistic ideal of encouraging everyone to be involved at all points in the process at every skill and experience level. It's perfectly reasonable to have a feedback mechanism where you tell people to get good/lurk more/work on their backhand/etc. before engaging with the community at a certain level, so as to prevent the cost of managing their contribution from exceeding its value.

klelatti 5y ago
I think this is well put. If anyone suggests saying that someone or a group is only capable (for whatever reason) of producing 'bug ridden garbage' in any context, then I'd politely suggest that this isn't the best way to communicate the issue.

asimpletune 5y ago

I think I often see this disconnect, with developers on either one side or the other, and usually the distinguishing factor has to do with what their experiences have been. If you've ever maintained, like, anything - not even necessarily open source but even something at work (with users obviously) - for a significant period of time, long enough to see how a project evolves over time, you'd just... understand. People without that experience can at times be a little too demanding when they don't get exactly what they want the first time. At times the may even act out, often in ways that are actually harmful, like trying to get managers involved to override something, writing negative stuff about you or your project online, or in general getting fairly hysterical and creating a fuss. When you try to help them they get super defensive, often before putting in the effort to understand what it is you even said. So it's certainly the case that "bug ridden garbage" isn't optimal vernacular, but at the same, what I think can be worse is, as far as communication problems go, nitpicking project maintainer's communication whilst a.) not understanding that their underlying point remains actually true (I.e. "bug ridden garbage"), albeit not beautifully articulated and b.) not giving them the benefit of the doubt in terms of what their intent was. Now imagine this, but literally all the time, all day, every day, etc... it can wear you down a little thin. Basically, when someone doesn't understand something, which is why the code needs to be reviewed in the first place, some tend to kind of lash out while latching onto something else they do know, e.g. I know that "bug ridden garbage" isn't a graceful way to talk, so I'll attack that. Anyway, I'm probably not explaining this very well, and I think it's just something that people need to experience themselves. I've come to take people who are rough more as a compliment than anything, thinking, "this person thinks highly enough about me that they can just say what they really think, so I better not disappoint them by taking that trust and trashing it", obviously there are limitations, but this has helped me so much to learn from people smarter and more experienced than myself. I'll just say one last thing. From what I've seen, the people who do tend to get defensive and kind of nitpicky about maintainer communication tend to not succeed when they become project leads themselves, and they usually just change jobs. O and obviously the maintainers who have the ability/experience and are blessed with grace, diplomacy, communication skills or however you want to call it, obviously tend to enjoy the most success.

ChrisMarshallNY 5y ago

There's a chap named Linus, who is rather well-known for being a tough PR reviewer... I feel that if we are talking a fundamental toolbox, like a language, standard library, or kernel, then being a perfectionist is pretty much required. For myself, I agree that harsh language isn't particularly helpful, but I have extremely high personal standards. I seldom project them onto others, but if anyone wants to play in my sandbox, then they play by my rules.

chucksmash 5y ago

> Why would anyone even attempt to contribute if their efforts are likely to be dismissed in this way? Because they are adults with enough emotional maturity to not require constant encouragement in every aspect of life. It's one thing to make negative, targeted statements against an individual contributor. It's another to make a likely true, slightly negative outlook about the quality of contributions on average. Potential contributors should be responsible for maintaining their own emotional equilibrium in such a case, in my opinion.