[matsemann]

> the security of all our computers depends on maintainers

Not getting paid anything, getting bullied and harassed while spending their free time maintaining things. Surely this isn't sustainable. And telling maintainers how to act will not fix anything.

[fc417fc802]

> telling maintainers how to act will not fix anything.

That depends. In this case it's good actionable advice that should hopefully lower cognitive load. Politely suggest a fork, then if the nagging persists block and move on. Sure if you're in a position of authority you have a responsibility to the community but cutting ties with a stranger who is flagrantly violating social norms is perfectly acceptable. There's no expectation that you indefinitely burden yourself with their poor behavior.

Sometimes dropping the ban hammer really is in the best interests of both yourself and the project.

[matsemann]

I don't really think it's actionable. It's like all those campaigns trying to steer behavior, pretty useless. Don't do drugs. Don't speed. Don't drink and drive. You can't just tell people something and expect it to happen. You need systems and guard rails in place.

Relying on maintainers to always do the right thing to ensure our security by telling them what to do is not the way.

[josephg]

> I don't really think it's actionable.

How is it not actionable? "Hey, you seem keen on feature X but I don't care about that. Just maintain X in your own fork. Thanks!" -> Close issue / PR.

Is this an illegal move? I've done it plenty of times. And other people have said the same to me, too!

[zygentoma]

> It's like all those campaigns trying to steer behavior, pretty useless. Don't do drugs. Don't speed. Don't drink and drive.

They're not useless. They just don't work on the individual level but on the collective. It's a numbers game …

[fc417fc802]

It's not an attempt to steer behavior but rather intended as helpful advice. There are certainly cases of organizations disseminating "helpful advice" with the underhanded intent of steering behavior but that doesn't mean we should assume bad faith by default.

The advice is actionable because it is a concrete change that could be made. I believe it to be relevant to the context because someone in a position of authority who is badgered into accepting something would most likely benefit from reevaluating how he is interacting with the general public.

[cj]

I have a feeling the thing triggering this guy is the responsibility of "the security of all our computers depends on maintainers".

A lot of people don't want to be responsible for that. It's not fun to carry that weight.

[josephg]

> telling maintainers how to act will not fix anything.

I'm just saying its ok to ignore overly enthusiastic contributors and tell them to just fork your project.

I think this does help, actually. In my early days of maintaining opensource software I felt burdened by open PRs - like I was letting someone down by ignoring their work. "Its ok, let them do whatever in their own fork" is advice I wish someone had given me.

[dotancohen]

  > I'm just saying its ok to ignore overly enthusiastic contributors and tell them to just fork your project.

I propose the phrasing "fork off".

[josephg]

A maintainer recently told me to “Fork baby, fork!” in response to a large patch set.

I was delighted.

[stackghost]

>And telling maintainers how to act will not fix anything.

Indeed. For too long, maintainers were expected to be gracious, courteous, and polite at all costs lest they be labeled "problematic", except for a few who were too influential to be muzzled like Theo de Raadt or Linus.

Perhaps we need to normalize bullying people who submit obvious slop as PRs.

[fc417fc802]

No, you absolutely should be gracious, courteous, and polite. But only at first. The duty of maintaining a functional community doesn't mean you're obligated to suffer unlimited abuse.

[account42]

You can be if you want to but social skills should not be a requirement to lead an open source project. If you create something and share it that doesn't oblige you to even respond to anyone.

[fc417fc802]

Of course, a hobbyist putting his code out there is under no obligation whatsoever. But we aren't talking about small time hobbyists here. These are professionals who are either paid as part of their job or else contribute their spare time to maintain important projects that are part of a large ecosystem that is relied on. There's a community and it necessarily has behavioral standards as part of the shared goal of maintaining group cohesion.

[jrochkind1]

There is no reason you can't be gracious, courteous and polite while refusing to accept or even to review the PR. These things are not tied together. You can also refuse to be bullied by submitters, stop engaging altogether. But bullying is part of the problem, not the solution, normalizing bullying is the wrong direction and will not result in more secure code.

[stackghost]

>There is no reason you can't be gracious, courteous and polite while refusing to accept or even to review the PR.

I agree, and I never suggested we cannot do these things.

I'm saying we should normalize immediately telling people who submit obvious AI slop to fuck right off. Submitting AI slop pull requests is rude. It is disrespectful of the maintainer's time and energy. I see no reason why I or anyone else should be respectful of someone who has already demonstrated a lack of reciprocal respect by submitting a vibe-coded PR that they obviously haven't even read or tested.

Respect must be earned.

[jrochkind1]

Because encouraging a culture of disrespect and bullying is actually bad for security not good for it. Politely decline, please, no need to be rude because of your (not always guaranteed to be correct) perception of where someone (or some thing!) is coming from.