LWN: Comments on "The selfish contributor revisited"

Gift economies

Phantom_Hoover — Mon, 10 Feb 2025 10:12:35 +0000

> Open source is often described as a "gift economy"—an ecosystem where contributors are motivated by a desire to make the world a better place.

That is not what a gift economy is. A gift economy is one where property is gifted without expectation of immediate compensation, serving to maintain complex social norms around reciprocal gifting. People in gift economies are still motivated by self-interest, not altruism.

https://en.m.wikipedia.org/wiki/Gift_economy

Seen from the other side

mathstuf — Mon, 10 Feb 2025 07:38:49 +0000

Yes, if you do not do a sweeping change to make the formatter happy with the entire codebase, you'll end up reformatting whole files when it gets touched the first time. We have the entire repository formatted en masse to make sure this doesn't happen. These commits are authored by our automation user and can be ignored for blaming purposes via `blame.ignoreRevsFile`[1]. We used to have the (IMO, awful) Whitesmith brace style and at some point decided to use something that editors can actually help with (Allman) to avoid having to think about it anymore.

[1] https://git-scm.com/docs/git-config#Documentation/git-config.txt-blameignoreRevsFile

Seen from the other side

wtarreau — Sun, 09 Feb 2025 22:19:27 +0000

The problem with automated tools is that it molests patches, and you end up with 1000 lines of changes instead of 3, which completely ruins your review, and that you definitely cannot commit without manually fixing to look like the original file. I agree that spaces/tabs are most of a semantic stuff than anything else that could theoretically be handled fine on the client, except that no two clients are equally configurable and you end up having to accept variations. That's where automatic reformatting of code produced in another editor makes things worse.

Seen from the other side

mathstuf — Sun, 09 Feb 2025 16:15:40 +0000

I do wish that editors had a "make it look nice" view, but that requires reliable formatting tools (which don't exist for every language). It's not something I think should be project-specific.

In any case, I have kind of inured myself to many objectionable formatting quirks in projects I drive-by contribute to (e.g., GNU-style indentation or inter-line alignment in tab-based projects) and other times I'm just not familiar enough with the language to know how some idiom should be formatted (e.g., comment placement/wrapping or Ruby's closures). No, the issue is that I have better things to focus on when coding than whitespace tweezing or line wrapping rules; these are things we *can* reliably outsource to automation. I hope that reviewers do too.

Seen from the other side

Wol — Sun, 09 Feb 2025 15:16:46 +0000

> In my case, the robot can also *do* the formatting fixes (I also don't like the "CI says formatting is wrong" that doesn't offer a fix or at least a diff I can apply), so there's no real "rejection" here nevermind for "obscure" reasons.

Those people who don't like the project's default format (and I would definitely enforce one) should simply define their own formatter to run on checkout. Then everybody wins - code in the repository is consistently formatted to the repository's rules, and contributors work with code formatted to their rules.

Cheers,
Wol

Seen from the other side

mathstuf — Sun, 09 Feb 2025 01:37:09 +0000

> Everyone prefers being explained by a human why their work was sub-perfect and was fixed rather than having a bot reject it for obscure reasons.

In my case, the robot can also *do* the formatting fixes (I also don't like the "CI says formatting is wrong" that doesn't offer a fix or at least a diff I can apply), so there's no real "rejection" here nevermind for "obscure" reasons.

My experience is that it allows me more time as a reviewer to focus on the actual technical content of the patch rather than nitpicking over minutae (which is attention-consuming and a great way to make very-chatty PR threads…GitLab at least allows collapsing things usefully though; I don't know how Github-based reviews deal with its behaviors there).

Even as a contributor, I like using CI to improve my patches before roping a human into the loop.

Seen from the other side

wtarreau — Sat, 08 Feb 2025 12:03:08 +0000

> Because small-talk is important. It can help build connection and trust.
Exactly! It's super important IMHO to build trust with the community.

Everyone prefers being explained by a human why their work was sub-perfect and was fixed rather than having a bot reject it for obscure reasons.

Also when you see the same shocking patterns happen often in submissions, you can start to think about documenting them or even relax your coding style if that's not dramatic.

Fighting passive aggression should not entirely fall on the victim

intelfx — Sat, 08 Feb 2025 08:09:11 +0000

> It seems obvious to me that the existence of passive aggressiveness by people in mailing lists etc. predates codes of conduct, so I can only take it that what you actually mean is that CoCs have increased the amount of it rather than causing its invention.

I can try to probably explain what was meant.

Due to the fact that all too often, the codified conduct is superficial (tending to favor form over substance, aka "are we using nice words" over "is everyone respectfully working in furtherance of common goals") and enforcement is one-sided (tending to favor those who already were in positions of power and authority), it becomes very effective in punishing reactive abuse (when someone has enough and snaps) and very ineffective in punishing those who express hostility, sabotage and stonewall while making sure to only use nice words.

Thus, passive aggressiveness becomes the tool of choice to express unsubstantiated hostility and still "get out of jail free".

Fighting passive aggression should not entirely fall on the victim

koverstreet — Sat, 08 Feb 2025 07:07:38 +0000

> But are those environments really similar to OSS work though? Strangers don't turn up at the shop doing an unprompted change to your heavy machinery or to the vehicle. In the blue collar manual labour work you're talking about, the person is a team member that got explicitly hired by you. Or they're a team member and you're their more senior peer/mentor. And the justification for occasionally shouting in this context is that it can convey urgency and gravity where necessary. If they do something wrong like they're about to screw in the wrong bolt, you might have to urgently prevent or fix their action before the machine goes haywire and explodes.

OSS didn't invent non professional collaboration, though. In the blue collar world, sharing your shop with a buddy or acquaintance based on trust, a demonstrated level of competence and some sort of quid pro quo is absolutely the norm.

And in the OSS world, we're not forced to take patches from random strangers; people demonstrate their competence and trustworthiness over time and we choose who we want to work with based on that.

It's different in the OSS world because there is indeed a higher _expectation_ that we'll try to collaborate and make it work, but fundamentally it's all about trust, and if you can't demonstrate that your work is trustworthy you can't expect to get it in - and the way to become competent, to develop that trust, is to work well with others; listen, learn, own your mistakes and all that. That part's the same anywhere.

> If, despite previous advice, someone repeatedly tries to use the wrong bolt/bad technique in their patch/idea, you can tell them that those patches/ideas won't be considered as long as that error is still there and continues because it's not of sufficient quality. It's a brief but firm one liner that still doesn't require yelling or being passive aggressive.

Yup, and that part works well when there's a clear line of competent authority.

Where you see the real problems and drama occurring is where there isn't a clear line of authority; either the authority figure has too much to do, or you've got a maintainer who's screwing up and unwilling to admit it (lose face) and listen or back down. And since there's never enough true experts, and everyone's human and makes mistakes, those situations happen quite a lot.

Fighting passive aggression should not entirely fall on the victim

interalia — Sat, 08 Feb 2025 06:29:52 +0000

> In other safety critical environments (i.e. anything blue collar; imagine working on heavy machinery, or even installing brake lines in a shop), if you screw up in a way that's dangerous for someone else you can expect to get chewed out. That's just life. Take it on the chin, learn from your mistake, and move on; if you try to flip the script and say "CoC violation!" in that kind of environment you won't be working there long.

But are those environments really similar to OSS work though? Strangers don't turn up at the shop doing an unprompted change to your heavy machinery or to the vehicle. In the blue collar manual labour work you're talking about, the person is a team member that got explicitly hired by you. Or they're a team member and you're their more senior peer/mentor. And the justification for occasionally shouting in this context is that it can convey urgency and gravity where necessary. If they do something wrong like they're about to screw in the wrong bolt, you might have to urgently prevent or fix their action before the machine goes haywire and explodes.

This isn't the case in an OSS setting, someone just turns up and supplies a patch or an idea. The team is all ad-hoc and made up of self-selecting interested parties. But patches don't get auto-applied to the code, so often nothing bad has actually happened yet or is imminently happening. The machine doesn't have the wrong bolt applied and it isn't about to explode. There's no urgency at all. Or sometimes maybe it has been already applied, and you see a problem, but it still takes quite a while for code to work its way to production deployments. The yelling doesn't actually achieve anything now.

If, despite previous advice, someone repeatedly tries to use the wrong bolt/bad technique in their patch/idea, you can tell them that those patches/ideas won't be considered as long as that error is still there and continues because it's not of sufficient quality. It's a brief but firm one liner that still doesn't require yelling or being passive aggressive.

Fighting passive aggression should not entirely fall on the victim

interalia — Sat, 08 Feb 2025 06:03:58 +0000

It seems obvious to me that the existence of passive aggressiveness by people in mailing lists etc. predates codes of conduct, so I can only take it that what you actually mean is that CoCs have increased the amount of it rather than causing its invention.

If someone is unable to give their critical analysis of a contribution without being either directly aggressive or passive aggressive, then they need to either learn that skill or learn to take a breath and refrain from posting when they recognise their tone would be bad.

Seen from the other side

neilbrown — Sat, 08 Feb 2025 01:36:11 +0000

> Why not have this done in an automated way?

Because small-talk is important. It can help build connection and trust.
"I took your patch seriously and here are some comments" says something quite different to "nobody bothered to look at your patch because you misspelled 'colour'."

Seen from the other side

mathstuf — Sat, 08 Feb 2025 00:16:21 +0000

> What I found in this case is to address yourself the small unimportant stuff (e.g. fix typos or indent), mentioning it when taking the change and presenting it as something normal, so that the person is not surprised to see their contribution modified

Why not have this done in an automated way? It relieves the reviewer from having to consider it and the contributor can work with CI before looping a human into the loop.

Fighting passive aggression should not entirely fall on the victim

koverstreet — Fri, 07 Feb 2025 21:46:30 +0000

I'll one up you.

So before I started working on the kernel, splitting bios (block layer IOs) was an unholy mess. There was no reasonable way to do it if the bio was more than a single segment, so upper layers would query lower layers "can I add another page to this bio?" as they were building it up. Oof...

This was all stuff that predated the more modern stacking block drivers (dm, bcache); it kind of worked for md where the restrictions were static, but quickly fell over if they were dynamic. And it was a whole pile of fragile, brittle slow code.

So I got rid of that and made efficient bio splitting possible by introducing a novel concept - the iterator. That made the biovec immutable, meaning it could be shared by splits. Novel stuff. It also meant that you could take a bio you were processing (in the middle of the io stack), stash a copy of the iterator somewhere, submit it, and then on completion restore the iterator to its previous state and walk precisely the same segments you saw when it was originally submitted to you (say for bouncing, decryption, what have you).

Deleted a ton of code from the block layer and device mapper, and bcache was pretty heavily reliant on all this stuff. Worked great, but..

It seems the maintainers never got the memo on things you can and cannot do with bio iterators. Saving and restoring iterators works great, because then it doesn't matter what the lower layer does with the bio (and it can advance the iterator, truncate it, or both, or neither). But an iterator was too big for them, they wanted to be able to restore the bio to its previous state by just rewinding it (by some number of bytes they pulled out of the ether).

So they merged an entire standard normal looking API to do this completely broken "bio_rewind()" thing, and then drivers started using it in predictably broken ways. And I didn't find out about it by getting CC'd on any patches - no, I found out about it through reports of bcache corrupting data; much shouting was required to get it reverted. And then they tried to merge it again...

Fighting passive aggression should not entirely fall on the victim

Wol — Fri, 07 Feb 2025 21:14:03 +0000

The killer though was he ignored the comment spelling out exactly why that code was needed! And then wondered why the predicted consequences happened!

Cheers,
Wol

Fighting passive aggression should not entirely fall on the victim

koverstreet — Fri, 07 Feb 2025 17:50:33 +0000

So you're processing a digraph and he hadn't learned anything past linked lists? Hah...

Fighting passive aggression should not entirely fall on the victim

Wol — Fri, 07 Feb 2025 17:43:32 +0000

> In my career I've had to deal with and chase down quite a few silent data corruption bugs, often introduced by other people into code I wrote who were being sloppy with process. That's always a really, really stressful event, and you have to think about what's at risk; people's entire lives are on their computers these days, think about the photo albums that might not be backed up.

Been there, done that :-)

Writing a critical path analysis program.

The code said:

1) Find a segment with no predecessors and process it.
2) If the successor segment only has the current segment as a predecessor, go back to (1) and process it.
Comment : If there's any other predecessors DO NOT process the next segment because that's the way you find temporal loops.
3) Forget the next segment, search for a different segment with no predecessors and go back to (1) ...

Of course, a colleague of mine looked at the code that abandoned the next segment, said "what's that for" and deleted it (leaving the comment there, of course), and then couldn't understand why the code assumed the user had a time machine handy ... (ie would happily process temporal loops without realising there was a problem).

Cheers,
Wol

Fighting passive aggression should not entirely fall on the victim

koverstreet — Fri, 07 Feb 2025 16:42:58 +0000

> Why not just point out the first part (trying to do something dangerous)? What is gained by the insult? I do know what is lost - this fosters a shouty atmosphere that drives people away. This (kitchen, heat) is sometimes mistaken for a meritocracy, but the absence of a very basic level of (workplace-type) civility puzzles me.

We were talking about the situation where someone is being passive aggressive and dismissive, i.e. you've already tried the first option. In that case, making an issue out of it rather than letting it slide or simmer is absolutely the right call.

> I'm a complete outsider to the kernel, but do participate a bit in open source. Kitchen/heat type environments create an in-crowd culture - I venture it does not help long-term sustainability.

Well, the thing you have to keep in mind is: the kernel is safety critical, high stakes code. Most of the world's infrastructure runs on Linux - the stuff that doesn't is a rounding error, and whatever additional testing and validation there might be before it's put into mission critical applications can only provide an additional safety margin, not real assurances.

We have to take responsibility for our work and own our mistakes, that has to come first.

In other safety critical environments (i.e. anything blue collar; imagine working on heavy machinery, or even installing brake lines in a shop), if you screw up in a way that's dangerous for someone else you can expect to get chewed out. That's just life. Take it on the chin, learn from your mistake, and move on; if you try to flip the script and say "CoC violation!" in that kind of environment you won't be working there long.

In my career I've had to deal with and chase down quite a few silent data corruption bugs, often introduced by other people into code I wrote who were being sloppy with process. That's always a really, really stressful event, and you have to think about what's at risk; people's entire lives are on their computers these days, think about the photo albums that might not be backed up.

If we want the kernel to be a less stressful place to work, the way to do that is:
- slow down a bit, take care with the code you write
- listen well, have empathy for the people you work with and the people who will be running and relying on your code
- own your mistakes, and make sure mistakes are addressed with a minimum of drama: seeing conflict addressed /well/ instead of being swept under the rug is a big builder of trust
- and embrace tools that make it easier to ship code we can rely on: better testing, Rust

Fighting passive aggression should not entirely fall on the victim

marcH — Fri, 07 Feb 2025 16:27:36 +0000

> For me it really does not amount to the same thing. I may not be the only one.

Of course the choice of words affects perceptions, emotions and form matters.

It's as far from an "exact science" as it can be though; maybe why it's tempting to dismiss it?

Fighting passive aggression should not entirely fall on the victim

stijn — Fri, 07 Feb 2025 16:07:24 +0000

> If someone's being an idiot and trying to do something dangerous, you tell them they're an idiot, simple and short, and you move on.

Why not just point out the first part (trying to do something dangerous)? What is gained by the insult? I do know what is lost - this fosters a shouty atmosphere that drives people away. This (kitchen, heat) is sometimes mistaken for a meritocracy, but the absence of a very basic level of (workplace-type) civility puzzles me. I'm a complete outsider to the kernel, but do participate a bit in open source. Kitchen/heat type environments create an in-crowd culture - I venture it does not help long-term sustainability.

> (If you're a senior engineer with a bit of eloquence and you've had your coffee you don't use those literal words, you tell them more specifically what they were doing wrong - but it amounts to the same thing).

For me it really does not amount to the same thing. I may not be the only one.

Fighting passive aggression should not entirely fall on the victim

pizza — Fri, 07 Feb 2025 15:26:21 +0000

> When it escalates into full blown yelling, no that's never ideal or productive,

Unless the person doing the yelling is in charge; in which case they're rewarded for "strong leadership" and "getting results".

Our society is replete with countless examples of this sort of behavior, and how it is explicitly *rewarded*.

Fighting passive aggression should not entirely fall on the victim

fishface60 — Fri, 07 Feb 2025 13:56:59 +0000

I remember hearing about that. The original study showed a correlation but completely neglected the context that the kids who ate the marshmallow immediately came from disproportionately poorer households which won't have sweets as often so sweets would be more immediately alluring, and may have experienced food precarity and seen promises of food later not materialise.

Success later in life tracks much more strongly with family wealth growing up, much quicker to look at that than wasting time with an experiment with sweets and the wealth disparity suggests a remedial action that could be taken there there were political will to do so.

Fighting passive aggression should not entirely fall on the victim

koverstreet — Fri, 07 Feb 2025 13:28:58 +0000

> I guess IRL where you have non-verbal cues to clarify the situation it might work, but over the internet I just don't see how it could ever work as intended.

Precisely, IRL you notice when someone is getting annoyed and about to snap at you and you back off.

When it escalates into full blown yelling, no that's never ideal or productive, but generally the breakdown in communication happened well before that point [0]; and the solution to avoiding those breakdowns in communication is to be more direct, not less.

If someone's being an idiot and trying to do something dangerous, you tell them they're an idiot, simple and short, and you move on.

(If you're a senior engineer with a bit of eloquence and you've had your coffee you don't use those literal words, you tell them more specifically what they were doing wrong - but it amounts to the same thing).

Unfortunately, because CoC enforcement is heavy handed, everyone now walks around on eggshells, taking the politeness to absurd levels and avoiding _anything_ that might lead to a blowup or confrontation because if you're smart you don't want to be in the vicinity when that gun goes off. Not a healthy situation.

[0] or you have someone who's seriously stressed out and needs a break, or just an asshole, but that's a different problem.

Fighting passive aggression should not entirely fall on the victim

randomguy3 — Fri, 07 Feb 2025 10:17:55 +0000

more recent attempts to replicate the marshmallow experiment (the classic psychological experiment you are referring to) have suggested its abililty to predict success as an adult is either much less than originally thought, or even negligible

Fighting passive aggression should not entirely fall on the victim

Wol — Fri, 07 Feb 2025 09:56:14 +0000

> Really? I don't see how that could be a natural response, nor can I think of a situation where it would actually help. Yelling is never a productive approach.

If it's not the natural response, why do so many people do it?

As you say, it's never (or rarely) productive, but it usually gives the yeller a short term win, and we are biologically programmed to prefer immediate wins - in life-or-death situations the immediate win is all that matters! But people who can break that tend to win in the end.

The classic psychological experiment is to take a class of kids and give them all a sweet at the start of a lesson. Tell them they can eat that sweet whenever they want, but if they can show you that sweet, untouched, at the end of the lesson you'll give them another sweet. That will very rapidly identify the kids that will do well both later in school, and later in life.

Cheers,
Wol

Fighting passive aggression should not entirely fall on the victim

kleptog — Fri, 07 Feb 2025 07:50:45 +0000

> because the natural response - yell and chew them out when someone is being over the top

Really? I don't see how that could be a natural response, nor can I think of a situation where it would actually help. Yelling is never a productive approach.

I guess IRL where you have non-verbal cues to clarify the situation it might work, but over the internet I just don't see how it could ever work as intended.

Fighting passive aggression should not entirely fall on the victim

NYKevin — Fri, 07 Feb 2025 07:47:57 +0000

As I said, you don't have to yell and chew people out to get your point across. It is enough to credibly and sincerely tell them that their behavior is unacceptable and repeat incidents will result in removal from the community. Then follow through, if necessary.

The problem is not that people are forced to use civil language, nor that CoCs are superficial. The problem is that we do not have the practical ability to make credible threats of this nature (shouting is at best a poor substitute, because they'll just do it again in a few months). If the perpetrator has enough "social credit," then half the community will bend over backwards to excuse almost any misbehavior whatsoever, so you can't ban these people. I would cite examples, but then my replies would be filled with people arguing that so-and-so did nothing wrong, for every value of "so-and-so" that I might care to bring up. I'm sure that gives you a sense of the general category of person I'm suggesting ought to be banned.

For all the superficiality of CoCs, at least they have established the de facto ability to remove people who misbehave (in some communities, anyway). Now we just have to get them better at identifying misbehavior, and worse at starting petty squabbles over nonsense.

Seen from the other side

wtarreau — Fri, 07 Feb 2025 06:03:22 +0000

I really agree with many of James' observations and points. Sometimes you're yourself on the side of the one having to accept changes that you don't like much, and you know by being used to that, that your comments might give you a label of PA or manipulator. This often happens when you disagree with something for various reasons but try to to hurt the submitter, so you keep your dissatisfaction for you and take the patch, but the problem is that it creates a precedent, with something imperfect that serves as an example of how to properly contribute. It can be small issues like coding style etc for example, or an approach that you're not certain how it will evolve over the long term.

What I found in this case is to address yourself the small unimportant stuff (e.g. fix typos or indent), mentioning it when taking the change and presenting it as something normal, so that the person is not surprised to see their contribution modified, and if there's nothing to fix but you're not much happy with the change, but have no technical argument against it (often we're driven by feeling itself driven by experience), just openly mention it: "I sense something might go wrong by proceeding like this, but I can't tell what; since I have no technical argument, let's merge it, and if later we figure it really causes a problem, we can revert it". It generally makes the contributor more careful in the future about the goals of the project, and if the suspected problem finally happens and something needs to be changed, the person doesn't perceive it as something bad since it was already envisioned. Usually that makes that contributor feel trusted and come back with more contributions. And even the problems you envisioned are often related to a slight change of direction that was clashing with your approach, but the contributor can continue that change and finally replace an older approach with something much better in the end.

This is a good example of long-term win/win driven by trust. It's difficult though because as a project leader you're also the one responsible for the project not to steer in directions that don't match the community's expectations, but by making public statements like this, you bring the community with you, or the community will contest your decision and you can roll it back if there are good reasons.

Fighting passive aggression should not entirely fall on the victim

koverstreet — Fri, 07 Feb 2025 05:19:15 +0000

People spend too much time arguing about what to do about passive aggressive behaviour because the natural response - yell and chew them out when someone is being over the top - is banned. There is no direct response, and that's the problem. CoCs created this problem when they started enforcing culture in a way that was entirely superficial.

If you want an example, we had one just the other day with Christoph trying to stop Rust work in its tracks.

The answer is to stop all the hand wringing and put some actual thought into what professionalism is.

Fighting passive aggression should not entirely fall on the victim

NYKevin — Fri, 07 Feb 2025 04:46:44 +0000

> He did suggest that people should and could intervene by deflecting the PA attempts, but I think Bottomley sees calling it out as just feeding into what the person wants in the first place.

In other words, we're talking about people who are deliberately trolling for reactions, not just having a bad day or whatever. My attitude is that you ban trolls and move on without them. But for some reason, many online communities have a hard time actually doing that when the perpetrator is an established member. The Wikipedia folks have written an essay[1] on this problem (in the context of their community), but there do not appear to be any easy answers.

"Gray rocking," the general behavior of ignoring abusive behavior, can be effective under the right circumstances, but it is not part of a healthy relationship, and most people cannot keep it up indefinitely in response to a regular or sustained pattern of abuse. We should not be asking newcomers to put up with abuse in the first place, let alone dictate the specific coping strategies they employ in response. Our ultimate goal should be the removal of problematic individuals from the community, difficult as that may be, and that starts with identifying bad behavior.

[1]: https://en.wikipedia.org/wiki/Wikipedia:Unblockables

Relevance to Recent Contributions

robbawebba — Fri, 07 Feb 2025 00:37:46 +0000

I agree with many of the points made by Bottomley. Progress becomes easier when we empathize with others, understand each other's motivations, and have calm discussions in good faith. Ideally these steps make it easier to find a solution in which everyone wins.

I see examples of many of Bottomley's observations in the recent patchset and mailing list discussion about Rust abstractions for DMA allocation (Covered by LWN on Jan 30, 2025, titled "Resistance to Rust abstractions for DMA mapping"). In the ML discussion, you'll find competing motivations, attempts for negotiation, passive aggression, requests for leadership involvement, and little progress towards a compromise. Some aggression and conflict in the thread have been squashed and called out as unproductive, and I hope that the contributor and maintainers can re-ignite the discussion based on the technical merits of the patch.

Fighting passive aggression should not entirely fall on the victim

jzb — Thu, 06 Feb 2025 21:48:19 +0000

He did suggest that people should and could intervene by deflecting the PA attempts, but I think Bottomley sees calling it out as just feeding into what the person wants in the first place.

What I've observed in other communities is that if you call out an entrenched PA'er, you give them the fight that they were itching for but didn't want to be seen obviously starting. If they are 1) ignored and/or 2) people stand up for the "victim" with support, it tends to defuse things much more handily.

Of course, no tactic is going to work in all situations. And I fully agree with your last point. I try to think about how I will feel about a reply when I calm down, or try to imagine how Fred Rogers would respond in my shoes. So far that has worked out pretty well.

Fighting passive aggression should not entirely fall on the victim

NYKevin — Thu, 06 Feb 2025 20:32:15 +0000

> Leaders also have to learn to deal with passive-aggressive people in email. He reminded the audience that leaders in open-source communities have no real power, "you have to persuade the pig". Bottomley suggested that people should respond only to the technical content in that kind of email and ignore the passive aggression. People employing passive aggression seek responses to their aggression and he said the victim should "never, ever" respond to the passive-aggressive part of the message. Nothing is going to nudge them toward more effective engagement. It is, of course, easier to say that people should not respond to passive aggression than it is to avoid doing so. "There will be times when you don't achieve this advice, but that shouldn't stop you from trying the next time".

This is necessary, but not good enough. It is also important for established members of the community (who are not the victim) to explicitly call out passive aggression when they see it. I don't necessarily advocate for doing this in every case, since there will always be gray areas and the project does not benefit from bickering over them. But we must not tolerate clear instances of incivility or unkindness, no matter how many good patches the perpetrator wrote in the past.

Addressing the obvious reply: You do not have to be mean to get your point across. If you have a technical argument, you can state it dispassionately. If you cannot control your emotions, you can step away from the computer and take a walk.

programming as theory building

hecanjog — Thu, 06 Feb 2025 19:22:17 +0000

> If asked, he said, engineers will claim that anything they're doing—including staring out the window while thinking—is productive work.

This really reads like a misunderstanding of what programming is to me -- a human process. Characterizing "productive work" this way makes sense for a large corporation I suppose. It doesn't make any sense to me unless you ignore the human component, though.

Negociation/manipulation

Wol — Thu, 06 Feb 2025 17:20:26 +0000

A leader looks for the "win win". If you can be honest about what you want, and think clearly about what the other person wants (it's far too easy to project *your* motivation on *them* and reward them with something *you* find valuable), then negotiation should be easy.

If you can't see clearly, amd offer them something they find worthless, then you're not going to get very far.

Cheers,
Wol

A single leader isn't the only way

kleptog — Thu, 06 Feb 2025 16:54:05 +0000

> The process of bringing those viewpoints together is assisted by some kind of leader who can help people see how to combine their inputs into the best solution.

Having a single leader is definitely one way of doing it, but not the only one. It is said the best form of governance is a benevolent dictatorship, but it's also unstable because succession is an issue long term. Though this isn't really an issue for most opensource projects.

You don't need a 'leader' so much as 'leadership'.

The alternative is leadership by a group or council. Much harder to setup and get going , but more stable in the long run. It does require careful nurturing and training, because each of the members of the council needs to have all the skills to negotiate and work with others. This takes effort and will, but leads to better results in the long run.

But yeah, people like 'strong men' and its simplicity does explain why it's so popular in opensource projects (and elsewhere).

Negociation/manipulation

nim-nim — Thu, 06 Feb 2025 15:45:09 +0000

A coach put it a lot more bluntly to us, manipulation is when you want others to do something and do not care if there is something in there for them (zero-sum win/lose mentality), leadership is when you care enough to make sure everyone wins something in the end (even if others may find the solution unbalanced).

Manipulation by incentive is just manipulation if the incentive does not materialize, it only works once, engineers have better memories than pigs.