Mark-toggle quoted messageShow quoted text
For what it's worth, as the original proposer, I would now view this suggestion as having three separate versions or options:
First is a moderation option that would automatically place a member account on some stricter type of moderation if there are X posts within P time period (say 15 posts in a week), and then automatically revert back to the original status at the end of that time period. This would automate, and so make far more convenient, something that would now take a lot of monitoring and followup.
Second is a moderation option that, once triggered as above (or manually), would limit the member account to Y posts within Q time period (say 2 posts per day). Excess posts within the window could either require moderator approval or simply be rejected. This again would automate (particularly the rejection option) something that would now take a lot of monitoring.
Third is a moderation option to delay, and possibly consolidate, such excess posts.
These three options could be implemented together or separately. Having all three together would be ideal, but either one of the first two would provide most of the functionality even by itself (so long as the threshold number and time period ranges were broad enough). The third option, on the other hand, seems like merely a tweak to the second one; it doesn't strike me as a priority, particularly if it could be hard to implement.
On Jan 22, 2022, at 3:58 PM, Marv Waschke <marvwaschke@...> wrote:
Long ago, when I was developing network management tools, our team implemented a rule like this in an agent for processing alerts-- x identical alerts within y time consolidated to a single alert. Worked fairly well. The logs became easier to read, enterprise-wide alert traffic went down. I can see similar benefits to groups.io.
However, some difficult bugs surfaced a few years out when the alert traffic was higher than we ever imagined and some unanticipated race conditions surfaced. These took serious effort to fix, more than the original implementation. My intuition, which really isn't worth much, is that implementing something similar in groups.io might surface similar issues. I would keep that in mind when deciding whether to implement or not, especially because a theme among the comments here is that this is a technical solution to a problem that might better be solved by addressing the human dynamics in a groups.
Just thoughts, Marv