I'm on the side of the CoC committee who told the author they engaged without enough consideration or kindness.
Reporting bugs is nice. It's less nice if, when a maintainer asks for a clearer reproduction, you respond with "I already gave you a reproduction, even if you have to edit it a little. I'm not a programmer, all I can give you is some AI spam. I'll leave it up to you to do your jobs" (edited only lightly from what the author really wrote).
Because the authors expect him to submit a patch when he stated that he is not a developer. That they expect him to reduce the build scripts when he can't do that. Pointing that out, the dev tells him, they don't expect him to be a developer, when some comments above they exactly did that. That is classic passive-aggressive behaviour.
The dev also writes on their page as the top item on what they do:
"fixing paper cuts for users, so all sorts of bugs;"
"Please try to minimise the steps required to reproduce it rather than producing large scripts with options that definitely won't work for me."
The guy doesn't have to do that, but then, he can hardly expect that people will want to donate their own time to help him with his problem.
Now, I get that he may not have known entirely how to proceed, but instead of asking how, he just says "no" and demands action.
That doesn't leave the dev anywhere to go -- without a way to reproduce the problem they really can't produce a fix.
So only then does the dev say "You're free to propose a patch yourself instead" which I think is pretty obviously rhetorical, meant to point out that there aren't any good alternatives if you don't want the dev's help.
It's all so strangely entitled -- the dev is asking for only the basic minimum of what's needed to actually fix the user's problem and now we've got people trying to shame them on HN.
The expectation to have a reasonable reproducer makes total sense, and if your reporter can't provide a clear reproduction, well, the developer can spend time on the bug but they're not obligated to. Our author was speaking like he was entitled to Sam's time.
I do agree "patches welcome" can be pretty passive aggressive, but in this case it was after our user was already an entitled asshole, and after our user posted AI slop, so I can understand why Sam might feel like being short.
Also, it's just wild that a "non-programmer" is submitting bug reports to a compiler, and then defending themselves with "but I'm not a programmer". Who cares about compiler warnings? Programmers. Compiler warnings are literally just for programmers.
Compilers are one of the projects where the devs actually can and should expect 100% of their users to be programmers, by definition. Why else would you be running a compiler?
I guess maybe the director of the CSI: Cyber show would care about them because they'd make the show look more l33t h4x0r, but I'm really struggling to think of any other audience for compiler errors.
I don't really have a dog in the race, but I think people should react this way to AI communication. They should be shunned and informed in no uncertain terms that they are not welcome to communicate any more.
He used AI as in he gave the AI the patch that regressed, asked the AI to "find the bug", and pasted that output.
This would be akin to walking up to the architect for a house, and saying "it's not my job to build buildings, but I tried to use this lego design to show you how to do your job. Look, the legos snap together, can't you do that with the house?"
Using AI to try and explain things to a subject matter expert, which you yourself do not understand, will come off like that, like you're second-guessing, belittling, and underestimating their expertise all at once.
This might have been too petty to comment on, if it weren't for the irony that an arrogant human asserting that AIs are fallible made his own logical error or exaggeration in the same sentence. Was he designed to produce lies too?
Edit: I'm not really defending a layman using AI to produce patches, but the OSS developer's characterization is an overreach in the other direction. It's not a very useful heuristic either; at some point AI content is not going to be labeled or obvious, so it will have to be carefully evaluated for correctness and good-faith intention the same as human-generated content is.
> it further demonstrated my good intentions
> "you are arguing with a law professional"
> "AI summary," ... shows the effort I am willing to invest ...
Wow.
I feel like it's probably a Google VP who works on Gemini astroturfing.
The output in their Mesa project bug report is outright misinformation, it sounds completely plausible but is absolute nonsense. This is the true danger of AI, it is so convincingly confident that people forget to question it, or in this case, don't even have the tools to begin questioning it. It's actively unhelpful at best.
Open source thrived back in early 2000-s too. Although I don't remember anything even remotely resembling Code of Conduct back then, I wasn't paying attention. Was it a thing?
I found that Drupal adopted CoC in 2010, and Ubuntu had one already no later than 2005 (the "Ubuntu Management Philosophy" book from 2005 mentions it).
EDIT -
> Once again these two Gentoo developers showed a lack of good manners.
…
> hold a personal grudge against me
Yes, indeed this non technical person seems to have found that while they don’t have a mind sharp enough for software, nor the respect and understanding that they can’t talk to people the same way they do as a lawyer, they’ve well on their way into the subculture of posting their emotional rants onto the internet. (haha!)
LLVM has already found that AI summaries tend to provide negative utility when it comes to bug reports, and it has a policy of not using them. The moment you admit "an AI told me that...", you've told every developer in the room that you don't know what you're doing, and very likely, trying to get any useful information of you to be able to resolve the bug report is going to be at best painful. (cf. https://discourse.llvm.org/t/rfc-define-policy-on-ai-tool-us...)
Looking over the bug report in question... I disagree with the author here. The original bug report is "hi, you have lots of misnamed compiler option warnings when I build it with my toolchain" which is a very unactionable bug report. The scripts provided don't really provide a lot of insight into what the problem might be, and having loads and loads of options in a configure command increases the probability that it breaks for no good reason. Also, for extra good measure, the link provided is to the latest version of a script, which means it can change and no longer reproduce the issue in question.
Quite frankly, the LLVM developer basically responded with "hey, can you provide a better, simpler steps to reproduce?" To which the author responds [1] "no, you should be able to figure it out from what I've given already." Which, if I were in the developer's shoes, would cause me to silently peace out at that moment.
At the end of the day, what seems to have happened to me is that the author didn't provide sufficient detail in their initial bug report and bristled quite thoroughly at being asked to provide more detail. Eli Schwartz might have crossed the line in response, but the author here was (to me) quite clearly the first person to have thoroughly crossed the line.
[1] Direct link, so you can judge for yourself if my interpretation is correct: https://github.com/llvm/llvm-project/issues/72413#issuecomme...
> Do your job
Which is a volunteer based job lol. Even if it was said in a heated argument, the bug reporter never really apologizes from what I read.
Maybe that's a "strawman" though
"I'm a volunteer, my job is to choose where I volunteer my time, and I won't be volunteering it for free for this".
There's no denying that AI is helpful, _when_ the human has some baseline knowledge to check the output and steer the model in the correct direction. In this case, it's just wasting the maintainers' time.
I've seen many instances of this happening in the support channels for Nix/NixOS, which has been around long enough for the models to give plausible responses, yet too niche for them to emit usable output without sufficient prompting:
"No, this won't work because [...]" "What about [another AI response that is incorrect]?" (multiple back-and-forths, everyone is tired)
"But I am not blaming you for not having a degree in software engineering."
But then
"And you admitted that the large scripts in question contain hardcoded information such as your personal computer's login username, clearly those scripts won't work out of the box on someone else's machine".
while the other committer ends with
"You're free to propose a patch yourself instead. "
So the committer is acknowledging that the user is no software developer, but then the two of them demand the user to do things that the user might not be able to do.
That's not going to work.
It actually reminds me of the the [OSS Sabotage book](https://www.cia.gov/static/5c875f3ec660e092cf893f60b4a288df/...)'s section on General Interference with Organizations and Production (page 28):
(11) General Interference with Organizations and Production
(a) Organizations and Conferences
(1) Insist on doing everything through “channels.” Never permit
short-cuts to be taken in order to expedite decisions.
(2) Make “speeches.” Talk as frequently as possible and at great
length. Illustrate your “points” by long anecdotes and accounts
of personal experiences. Never hesitate to make a few appropriate
“patriotic” comments.
(3) When possible, refer all matters to committees, for “further
study and consideration.” Attempt to make the committees as
large as possible—never less than five.
(4) Bring up irrelevant issues as frequently as possible.
(5) Haggle over precise wordings of communications, minutes, resolutions.
(6) Refer back to matters decided upon at the last meeting and attempt
to re-open the question of the advisability of that decision.
(7) Advocate “caution.” Be “reasonable” and urge your fellow-conferees
to be “reasonable” and avoid haste which might result in
embarrassments or difficulties later on.
(8) Be worried about the propriety of any decision—raise the
question of whether such action as is contemplated lies within
the jurisdiction of the group or whether it might conflict with
the policy of some higher echelon.What an amazingly effective phrase to get open source developers to do what you want. /s