Is possible to hide flood edits on Special:RecentChanges? The Human (not bot) filter doesn't work and flood edits are visible.
Topic on Talk:Edit Review Improvements/New filters for edit review
You'll have to define "flood". If you mean the flooder user group, then theoretically it would only work if "bot" (automated edits) is unchecked. If you mean detecting floods on the fly, then that is a complicated situation, but the primary fix would be to reduce the general editing rates of all accounts to reasonable limits (high rate editing means high rate mistakes, and server load) , see:
It is odd though, some bots still appear in recent changes even if "human" is selected. My guess is that these accounts are making edits without using their bot flag (see Manual:Bots#The_.22bot.22_flag).
This makes sense to an extent because admins may give themselves the bot user right, but only use it when needed, and their actions shouldn't all be hidden from recent changes. Also, an account may do an action using the bot right, and then later on within the same day have those rights removed. So only actions related to bot activities should be hidden while allowing other actions to be seen.
A reasonable solution to this issue is adding a new filter that makes it possible to hide all edits by users currently with a bot right. This will contain false positives though.
Massive edits made by users who don't have the bot flag will not be filters as bots, indeed. The community have to be firm about that: massive edits = bot flag.
The community have to be firm about that: massive edits = bot flag.
That's the source of the problem. Registered users === bots (in terms of editing rate). They can essentially edit freely without limits and may causes server problems, as the linked task shows. In other words, aside from bureaucracy (and some api specific actions) no registered user really needs bot rights.
There isn't a really good way to be firm because of that. That configuration change (https://phabricator.wikimedia.org/T56515) should be part of edit review improvements. Simply put high edit rates === increased number of errors === high burden for editors === unreadable recent changes === higher rates of spam. Just look at recent changes in wikidata (e.g. #quickstatements tag), massive number of people editing in a bot like manner, obliviously introducing many errors and treating a database system like an article.
No human can operate above a certain rate without making many more errors (see Diminishing_returns). Developers and the so-called communities are just fooling themselves if they think otherwise.
Recent Change list should load more items after it filters out items