Page MenuHomePhabricator

Clarify how counter sequencing and resetting (on revert) should work on the backend
Closed, ResolvedPublic

Description

The product plan calls for sequenced counters (or "levels"), and for the penalty for a revert to be for the count(s) for only the CURRENT counter/level to be reset to 0.

There are different ways of modeling this on the backend:

  1. We could provide for counters to specify multiple target counts in an array, e.g., [5, 50]. (Implemented at https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/WikimediaEditorTasks/+/491292/)
    • This raises some problems:
      • If the first target (5) is passed, are only subsequent edits reset, or are all edits reset (but the record of passing 5 qualifying edits kept)?
      • If so, since we are maintaining per-language counts, how do we decide which counts to reset for which languages, in a situation in which edits are distributed across languages? (I would prefer not to have to maintain full histories of qualifying edits for each user...)
  1. We could otherwise provide for sequenced counters, and model multiple targets for edits with the same characteristics as separate counters.
    • This would eliminate the issue of uncertainty over which particular count(s) to reset, but raises other issues:
      • It could be confusing for clients.
      • It requires some thought about what a valid chain or tree of sequenced counters should look like, and where/how validation should happen.
      • It introduces more room for error in the counter configuration.

(Of course, these aren't mutually exclusive, and we might end up introducing both constructs anyway for different reasons. However, we probably only need one or the other for initial launch.)

In either case, how do we make what's happening on revert minimally confusing to the user? On revert, is there a provision planned for the app to inform the user that (some or all of) the user's counted edits have been reset to 0, and why?

Event Timeline

Mholloway renamed this task from Clarify how counter resetting (on revert) should work on the backend to Clarify how counter sequencing and resetting (on revert) should work on the backend.Feb 18 2019, 7:35 PM
Mholloway triaged this task as High priority.
Mholloway created this task.
Mholloway updated the task description. (Show Details)Feb 18 2019, 7:37 PM
Mholloway updated the task description. (Show Details)
Mholloway updated the task description. (Show Details)
Mholloway updated the task description. (Show Details)
Mholloway updated the task description. (Show Details)Feb 18 2019, 7:39 PM
Mholloway updated the task description. (Show Details)
Mholloway updated the task description. (Show Details)Feb 18 2019, 8:23 PM
Mholloway updated the task description. (Show Details)
Tgr added a comment.Feb 18 2019, 11:04 PM

There seem to be two separate questions here:

  • should counters be per-language? (I don't think it makes any sense to have per-language resets without having per-langauge counters.) Or per-wiki, for that matter. This is a product decision, I imagine per-language resets would mean separate counters and separate sequences and levels per language (possibly with some kind of interaction between languages, like how StackExchange gives you a starting reputation of 100 if you have sufficiently high reputation on some other SE site; but that would be too complex to store in configuration, anyway).
  • should sequences be implemented with a configuration array or with multiple counters? I might be missing the point of this task but I don't see any benefit from having multiple counters.
Mholloway added a comment.EditedFeb 19 2019, 3:01 PM

Counters are already per-language in order to support displaying counts per language in the app.

To illustrate the issue with (1), let's say we have a counter 1 with targets [5, 50], and user 1 is reverted after reaching the effective time of the first target.

Given a counts table like:

wetc_userwetc_key_idwetc_langwetc_count
11pt3
11en3

and a targets passed table like:

wettp_userwettp_key_idwettp_countwettp_effective_time
11520190218182440

Since targets are calculated based on the sum of per-language counts*, if we want to reset counts back down to the previous target level (5), we'd have to arbitrarily choose to update either the en or pt count to 2.

If it's permissible from the product side to simply reset the counts to 0 but retain any targets passed, that would easily resolve the problem. (And in fact that's the current behavior in the patch.)

*Actually, this might not be true, as there was some suggestion in the context of the "language CAPTCHA" discussion (T213947) that "levels" themselves are to be per-language; that needs clarification. (edit: confirmed on slack that targets are indeed for all langs combined.)

Mholloway closed this task as Resolved.Feb 20 2019, 5:54 PM
Mholloway added a subscriber: Charlotte.

If it's permissible from the product side to simply reset the counts to 0 but retain any targets passed, that would easily resolve the problem. (And in fact that's the current behavior in the patch.)

@Charlotte I discussed this in the devs sync just now and we agreed this seemed sensible, but just to confirm, the plan in an instance where a user is reverted after passing a target is for the record of the target being passed to remain in the DB, but for all per-lang counts to go back to 0. Please reopen if that doesn't sound quite right to you.

Yes @Mholloway that makes sense.