Page MenuHomePhabricator

Database review: Automoderator
Closed, DeclinedPublic

Description

Links to the schema on master:

Should this table be replicated to wiki replicas (does it not contain private data)?
The table does not contain private data.
Will you be doing cross-joins with the wiki metadata?
No
Size of the table (number of rows expected).

  • automoderator_model: 1 row per wiki to start
  • automoderator_rev_score: Actual number TDB: the size will be proportional to the recent changes table on each project. We will score most revisions and store those scores here.
  • automoderator_model: 8 rows per wiki per year would be generous. This will grow by the number of models we use times the number of version increments per model. For now we are using a single model, and we only see potentially adding one more within the next year. We don't expect version changes to happen more often than quarterly.
  • automoderator_rev_score: Actual number TDB: this will grow in tandem with the recent changes table per project. We are implementing a prune job to align retention with recent changes

Expected amount of queries, both writes and reads (per minute, per hour...per day, any of those are ok).
TODO
Examples of queries that will be using the table.
TODO
The release plan for the feature (are there specific wikis you'd like to test first etc).
We will be deploying to test and id.wiki first, aiming for May 2024.

Event Timeline

Ladsgroup subscribed.

you need to give me way more information on what tables, what are their designs, what are aiming to achieve with those tables, etc.

Samwalton9-WMF changed the task status from Open to Stalled.Apr 3 2024, 7:19 PM

you need to give me way more information on what tables, what are their designs, what are aiming to achieve with those tables, etc.

Of course :) Our team's engineers are going to fill in the details here, I just filed this as a placeholder for now. I'll make that explicit by marking this as stalled for now.

Since you're aiming for May, I suggest doing this sooner than later since from what I'm seeing in the parent tickets it needs a bit of rework before it can go live.

Since you're aiming for May, I suggest doing this sooner than later since from what I'm seeing in the parent tickets it needs a bit of rework before it can go live.

Thank you! I'll go ahead and fill in what we have today.

Hi,
I need an answer to this. For start, in T360144: Create database schema for AutoModerator it's written:

In T356100, we have determined that we need a database table to keep track of edits that have been checked but not reverted by AutoModerator. We also need a place to store revisions that haven't been checked by AutoModerator due to failures in the check process.

And in T356100: Determine method for tracking edits that have been checked but not reverted by AutoModerator

So my question is, why do you need to keep track of the edits? Is it for analytics/PM/internal use or you're planning to build a user feature on top of this table? and if so, what feature (i.e. select patterns)?

Answering to this, will change how the design of storage should look like.

@Ladsgroup, thank you for looking at this.

There are two kinds of general cases we want to cover:

  1. issues requiring intervention: as an example, we can't always merge the "undo" content if the edit to be reverted is no longer the most recent by the time we try to revert it. When this happens, we will want to surface it for manual revert by a moderator. The UX for that doesn't exist yet but it's a thing we know we'll need.
  2. observability: we want moderators to be able to see/validate that it is working in cases where it is not reverting edits. There isn't a clear feature designed around this for the pilot. Perhaps just observability into the overall activity of the extension would be adequate for now.

[...]

  1. observability: we want moderators to be able to see/validate that it is working in cases where it is not reverting edits. There isn't a clear feature designed around this for the pilot. Perhaps just observability into the overall activity of the extension would be adequate for now.

We talked about this one in particular today and clarified that there isn't going to be a user facing feature for this in the foreseeable future. That should strip down our db needs significantly. We shouldn't have gotten this far without having clarified this, which is a failure on my part.

@Ladsgroup, thank you for looking at this.

[...]

  1. issues requiring intervention: as an example, we can't always merge the "undo" content if the edit to be reverted is no longer the most recent by the time we try to revert it. When this happens, we will want to surface it for manual revert by a moderator. The UX for that doesn't exist yet but it's a thing we know we'll need.

[...]
Per our research, we believe that AutoModerator will only attempt ~7 reverts daily with our "very cautious" pilot settings. For now, we'll just log problems within that set of revert attempts.

I'm closing this out for now. We will revisit this if/when user-facing features requiring an extension-specific table have been designed.