Clear policy regarding changes(commits) that introduce serious bugs

[ArturKnopik]

Hi, I wanted to talk about the policy regarding changes that introduce serious bugs.

Recently, bugs were introduced that cause the engine to not be able to work on Linux (NPC revscript) and monsters do not follows target (I just discovered it)

What should happen to commits that introduce such serious bugs? In my opinion, they should be reverted as soon as possible, if the Author wants to add his code again, he should make sure it works properly (including testing)

[nekiro]

Agreed.

[gesior]

I agree.

We should punish for PRs that introduce bugs or are clearly IDE/AI content made just to increase someones 'github activity'
(ex. #4847 - author posted it and closed after I've commented that it's useless. So it was useless, when he posted it? Don't worry, he will post more, he has 114 commits merged into TFS master branch.
I just opened his 114 commits list, picked random and it's:
6579f12
WTF? Changes 1 IF into 2 IFs in some random Lua file.

For last few years TFS merges PRs that are not working at all. Ex. 'monster direction' PRs. There were 2-4 PRs to fix directions of monsters and it all started with 'refactor PR', that should just reformat code, not change logic.

Some FOSS projects ban users that create seriously bugged PRs for X years. You can't know, if it's mistake or planned "bug" (to crash/abuse other OTSes).
They also often ignore 'new users' as not trusted.
Idea is simple: project maintainers should not waste X hours to analyse someone's changes to find out that after login all monsters look opposite direction.