8 ms·

The public embarrassment of lazy and dishonest actors, especially those who are paid to collaborate, is an effective tool for maintaining order and sta

The public embarrassment of lazy and dishonest actors, especially those who are paid to collaborate, is an effective tool for maintaining order and standards on behalf of the quality of the product, and provided nobody gets hurt permanently at the end of the day, it is easily justified. Can you explain why you feel rants and insults are necessary to maintain high technical standards? Literally nobody is asking Linus to relax his standards for what makes it into the kernel.

microcolonel 8y ago
> Can you explain why you feel rants and insults are necessary to maintain high technical standards? It is possible that they are not truly "necessary", but they are one often-effective way to discourage disruptive/unproductive behaviour. Linus ultimately should not be asked to review changesets he will be far from willing to merge; and for him there are only so many hours in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard, and it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding). It is a high-risk, unappealing technique, but we should be careful not to impose alternatives which fail to meet the same criteria at least to some extent.
- JohnBooty 8y ago
  there are only so many hours [for Linus] in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard This is a really a restatement of the old (yet still relevant) "Linus doesn't scale" issue, right? It's true: Linus' time is a valuable resource and shouldn't be wasted. This is of course true of any project maintainer, or any person at all really -- it's just that the stakes are a higher in the case of the Linux kernel because of the scope and impact of the project. it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding) This is a nearly universal problem. Imagine suggesting "hurl insults at the perpetrators until they learn" as a solution in any other field. Ridiculous! The answer of course is to proactively reduce the number of time-wasting things that are raised to Linus' attention, not to reactively be meaner when those sorts of things do happen. Typically you'd do this in Linux or any software project by: (a) making sure that the other kernel maintainers are trusted and skilled (b) making sure that everybody has a solid understanding of what is and isn't a good contribution (c) discussing contributions ahead of time so that there are fewer surprises at review/merge time (d) solve the "Linus doesn't scale" issue by delegating more of his responsibility elsewhere, cloning him, etc. I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows.
  - microcolonel 8y ago
    > I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows. Well, you're spot-on right here. The reason I think it is a more understandable solution for Linus is that, by the time a piece of substandard or dishonest work makes it to Linus, the buck should have stopped at least at a couple of places. They are doing an excellent job, but at the 99.995th percentile there is going to be a piece of substandard or dishonest work in Linus' inbox, and each time it should be a matter of considerable interest to everyone involved as to how it got there (and the multitude of ways it should not have made it).
ponyfleisch 8y ago
I suppose the theory is that fear of embarrassment makes people put in extra effort before submitting anything. This would reduce the time spent politely rejecting submissions. Intuitively, in my opinion this sounds plausible.
- pell 8y ago
  I think fear also hinders innovation as it hinders thought and disruption at times. I am sure, to a certain degree, it's good to be fearful and understand the stakes but I doubt this has to be something maintained through verbal attacks, public humiliation and other forms of _abuse_. I like Linus Torvalds. It's hard not to have a soft spot for him when his counterparts always were Bill Gates and Steve Jobs (for the longest time). But for this, there is no necessity of asshole-behavior.
  - johnny22 8y ago
    Is that the "At least he's our asshole". That kinda makes sense to me.
- johnny22 8y ago
  Intuitively? have you ever contributed code to a FOSS project? My experience is that I try to write the best code I can to be accepted, because I care about quality. The embarassment (my feels) is gonna be because my code wasn't up to snuff. I choose not to contribute to projects in which the feedback might be based on feels (vitriol) rather than reals (the code quality)

microcolonel 8y ago

> Can you explain why you feel rants and insults are necessary to maintain high technical standards? It is possible that they are not truly "necessary", but they are one often-effective way to discourage disruptive/unproductive behaviour. Linus ultimately should not be asked to review changesets he will be far from willing to merge; and for him there are only so many hours in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard, and it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding). It is a high-risk, unappealing technique, but we should be careful not to impose alternatives which fail to meet the same criteria at least to some extent.

JohnBooty 8y ago
there are only so many hours [for Linus] in the day. It is, as a practical matter, necessary to communicate that there is a cost to wasting his time with work that somebody should have known was substandard This is a really a restatement of the old (yet still relevant) "Linus doesn't scale" issue, right? It's true: Linus' time is a valuable resource and shouldn't be wasted. This is of course true of any project maintainer, or any person at all really -- it's just that the stakes are a higher in the case of the Linux kernel because of the scope and impact of the project. it is important that that cost is borne primarily by the originator of that substandard work (i.e. it needs to suck more for the committer to waste Linus' time than it sucks for Linus to spend time responding) This is a nearly universal problem. Imagine suggesting "hurl insults at the perpetrators until they learn" as a solution in any other field. Ridiculous! The answer of course is to proactively reduce the number of time-wasting things that are raised to Linus' attention, not to reactively be meaner when those sorts of things do happen. Typically you'd do this in Linux or any software project by: (a) making sure that the other kernel maintainers are trusted and skilled (b) making sure that everybody has a solid understanding of what is and isn't a good contribution (c) discussing contributions ahead of time so that there are fewer surprises at review/merge time (d) solve the "Linus doesn't scale" issue by delegating more of his responsibility elsewhere, cloning him, etc. I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows.
- microcolonel 8y ago
  > I should note that I have no idea about how the kernel maintainers function on a daily basis. Maybe they're already doing a really great job of those things, and it's only 0.001% of merge requests that result in spectacular Linus rants and therefore show up on HN or whatever. Since it seems like kernel development is humming along pretty well for the mooooooost part I'd put my money on that, but who knows. Well, you're spot-on right here. The reason I think it is a more understandable solution for Linus is that, by the time a piece of substandard or dishonest work makes it to Linus, the buck should have stopped at least at a couple of places. They are doing an excellent job, but at the 99.995th percentile there is going to be a piece of substandard or dishonest work in Linus' inbox, and each time it should be a matter of considerable interest to everyone involved as to how it got there (and the multitude of ways it should not have made it).

ponyfleisch 8y ago

I suppose the theory is that fear of embarrassment makes people put in extra effort before submitting anything. This would reduce the time spent politely rejecting submissions. Intuitively, in my opinion this sounds plausible.

pell 8y ago
I think fear also hinders innovation as it hinders thought and disruption at times. I am sure, to a certain degree, it's good to be fearful and understand the stakes but I doubt this has to be something maintained through verbal attacks, public humiliation and other forms of _abuse_. I like Linus Torvalds. It's hard not to have a soft spot for him when his counterparts always were Bill Gates and Steve Jobs (for the longest time). But for this, there is no necessity of asshole-behavior.
- johnny22 8y ago
  Is that the "At least he's our asshole". That kinda makes sense to me.
johnny22 8y ago
Intuitively? have you ever contributed code to a FOSS project? My experience is that I try to write the best code I can to be accepted, because I care about quality. The embarassment (my feels) is gonna be because my code wasn't up to snuff. I choose not to contribute to projects in which the feedback might be based on feels (vitriol) rather than reals (the code quality)