try to reduce the number of PRs with mass reformatting changes

[k-yle]

there are at least 10 recent PRs where people are mass re-formatting files for some unknown reason¹

since this repo doesn't want auto-formatting, it's a waste of time if every code review starts with "please remove the unrelated formatting changes".

the diff in every recent PR matches the style of Prettier, so disabling that software should fix the problem.

Footnotes

1. i think maybe the LLM software is trying to follow modern code standards? or maybe AI editors like Claude enable format-on-save by default ?? ↩

[matkoniecz]

there are at least 10 recent PRs where people are mass re-formatting files for some unknown reason1

I guess that benefit here is that LLM slop can be closed for mixing in pointless formatting changes?

[k-yle]

i have no opinion on the topic of banning LLM-driven spam 🍿🍿

happy to close this, i just thought we could save a bit of time for everyone. i suspect many beginner contributors are not familiar with git cherry-pick, which is why they often rewrite all the code in a new branch, which probably takes ages

[k-yle]

another thought: this might also be solvable by adding this line to .vscode/settings.json, which presumably¹ works in every popular LLM IDE, since they're all forks of vscode.

"editor.formatOnSave": false

Footnotes

1. i only tested trae.ai, not the others ↩

[tyrasd]

I don't think adding config files for every possible formatting tool that we don't actually use is very sustainable, as the number of such tools is unbound. 😅 Sure, prettier is quite popular, but I'm questioning how much a contribution is worth if the author is not even bother to check which linter we use, or to read the contribution guidelines. 🤷

"editor.formatOnSave": false

Is this not the default of vscode already?

[1ec5]

I’ve also recently seen inadvertent reindentation from a contributor who was working on their PR by hand, repeatedly on each push in fact. Part of the problem is that some files use different formatting than others.

What if we do a one-time pass over the repository to make indentation and whitespace at least internally consistent? Then at least users of VSCode or whatever can adjust their settings once and not have to worry about it again. While we’re at it, we could align with a default style from one of these tools, reducing noise going forward.

Normally projects only take a refactoring step like this after minimizing the number of open PRs. Otherwise, many PRs will have major merge conflicts for minor reasons. Unfortunately, we’re quite a ways from Inbox Zero, but if we’re willing to help resolve conflicts in the more promising PRs, then this approach becomes more feasible.

I guess after saying that I’m fine with the proposed change as a stopgap. 😅

[matkoniecz]

Unfortunately, we’re quite a ways from Inbox Zero

I just started osmfoundation/ewg_bidding#58 which includes also review of iD PRs so it is supposed to go down a bit?

(this includes also review of iD PRs, with #11590 as the first merge and some PR closures)

So can we wait with potential messing up of most PRs, at least for now?

[matkoniecz]

i have no opinion on the topic of banning LLM-driven spam 🍿🍿

I would describe them as unwanted trash. In case where LLM output is submitted without clearly making it as LLM output, there are also more complex cases that may or may not be OK.

And more annoying than regular spam as they may be easily confused with actual contributions in either direction, at least on initial review (I got question already on one of my PRs "is it LLM" where no LLM was involved at all, so there is definitely risk here). What makes banning it harder.