Some thoughts and specs:
The core idea is as follows:
When a user meets criteria X, do Y. When a user no longer meets criteria X, do Z.
Let's define some key terms:
- Criteria Group: The set of all criteria that a user meets.
- Criteria (singular Criterion): An arbitrary set of requirements. Criteria are paired with triggers and actions, and are composed of:
- Metrics: A numerical requirement. For example, post count or number of likes received. A criterion could require a range/minimum/maximum of metrics.
- Condition: An abstract boolean requirement. For example, not being suspended, or having an email that matches a certain regex.
- Action: Something that happens automatically when a criteria is met or lost. This could include anything from adding/removing a group to sending an email to suspending a user.
- Triggers: A set of events that would cause a user's criteria groups to be reevaluated. These are associated with metrics and conditions.
The admin dashboard will include a GUI for managing criteria.
Example 1: Group Management
Criteria: Users that receive 50 or more likes and have started at least 10 discussions should placed in the "Active" group.
Here, the metrics are "received 50 or more likes" and "have started at least 10 discussions". Unsurprisingly, they come with the triggers (
PostWasUnliked) and (
The actions are:
- When the criteria is met, add the user to the "Active" group
- When the criteria is lost, remove the user from the "Active" group
Example 2: Suspension
Criteria: If a user gets 15 warnings or more and is not an admin, suspend them.
Here, the metrics are "gets 15 warnings or more" and the requirements are "is not an admin". The triggers would be a new warning for the metric. The requirement has no triggers.
The actions are:
- When the criteria is met, suspend them
- When the criteria is lost, unsuspend them
Metrics vs Conditions
It's clear to see that any metric could be represented as a condition. However, metrics are highly preferable if possible:
- A requirement must be specific. "More than 50 received likes" could be a requirement. However, metrics can allow for any range of values.
- Metrics can be stored and used for other purposes. For example, a planned feature is combining all metrics to provide a "reputation" score.
When you add requirements to a criterion, you indicate whether that requirement must be met, must not be met, or whether it shouldn't apply.
When you add metrics to a criterion, you indicate a range of values.
Actions can define their own settings. So when you add an action to a criterion, you might be prompted to fill in some settings. This allows creating generic actions, such as adding a user to an arbitrary group.
Keep in mind that criteria are generally "If and only if" relations. Going back to example 1, users will be placed in the 'active' group if and only if they have received 50+ likes and have started 10+ discussions. If an admin then removes that user from the 'active' group, the user will be re-added the next time a trigger is run if they meet the needed criteria.