| KStoller-WMF | |
| Dec 2 2022, 1:00 AM |
| F35869174: Screen Shot 2022-12-15 at 1.14.43 PM.png | |
| Dec 15 2022, 10:18 PM |
| F35827652: Screen Shot 2022-12-01 at 4.58.37 PM.png | |
| Dec 2 2022, 1:00 AM |
Steps to replicate the issue (include links if applicable):
(reported here)
What happens?:
The new impact module shows 1,000 total edits.
What should have happened instead?:
Given I'm an editor with 1,000 or more mainspace edits,
When I view my impact module,
Then I see 999+ as the Edit total
Given I'm an editor with 1,000 or more Thanks,
When I view my impact module,
Then I see 999+ as the Thanks received total
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | KStoller-WMF | T248330 [EPIC] Growth: Positive reinforcement | |||
| Resolved | KStoller-WMF | T222310 [EPIC] Positive reinforcement: New Impact Module | |||
| Resolved | BUG REPORT | Tgr | T324286 NewImpact: edits and thanks are capped at 1000 |
We are limiting the metrics at what can be derived from the user's last 1000 mainspace edits (so e.g. top-viewed articles will only include those edited within the last 1000 edits) to avoid performance problems. There are users with a million edits, the query could get arbitrarily slow otherwise.
Somewhere else (I can't recall now) we used language like "999+" for displaying values above the limit.
Thanks for the explanation! I totally understand that the other metrics we are calculating need a reasonable limit, but I thought we already had a way to quickly grab the main namespace edit count? I know it's one of the Namespace Totals provided in Xtools, and we show the full count in the old impact module.
The new version says that I have made only 1,000 edits, but the old (current) version says the truth (36,754 edits).
The old impact module shows the total edit count, which is cached by MediaWiki as a separate DB field. The mainspace edit count would have to be computed by us, the data for experienced users is not precomputed so it would slow down the loading of the impact module, and it would need the intersection of two indexes (as the revision table does not know about the namespace) and InnoDB is in general not good at counting things.
A random example from enwiki:
wikiadmin@10.64.48.74(enwiki)> SELECT COUNT(*) FROM revision JOIN page ON rev_page = page_id WHERE page_namespace = 0 AND rev_actor = ( SELECT actor_id FROM actor WHERE actor_name = 'JPxG'); +----------+ | COUNT(*) | +----------+ | 31700 | +----------+ 1 row in set (3.633 sec)
Still works but quite slow. At 5 seconds the query would be killed.
We could just try and see if it works - it would for most wikis, and for many users even on large wikis. But we'd have to suppress the error reporting somehow, as it's used to detect operations issues.
XTools uses the Toolforge replica tables, which are MyISAM and considerably faster at counting; but mostly, it's just not in a hurry. For example, it renders the contributions page for my huwiki user (which doesn't have that many edits) in 6s. For the enwiki user above, it took 220s. (Granted, it calculates way more things than just edit counts so it isn't really a fair comparison.)
There are a number of things we could do (e.g. push the computation to a job, which has much more relaxed query time limits, and poll from the frontend whether it's done). How much effort is it worth though, given that experienced users aren't really our audience?
If not yet reported, this capped to 1,000 issue is also true for the number of Thanks received (example).
Having something like 999+ when the limit is reached is perfectly acceptable given the audience we target at the moment.
We discussed in the engineering sync, and would like to fix this before release. @Tgr will add a string to show 999+ when the user has more than 1,000 edits/thanks. We'll then need to collect the translations in translatewiki.net to backport in T324465: NewImpact: Backport latest translations for pilot wikis.
As Kosta said, skipping the design phase due to urgency. We can discuss afterwards if a different approach is preferred but keeping the limit and showing some kind of clarification on the UI is the only one that's realistic for a Tuesday deploy date. We have used the "X+" pattern somewhere (suggested task search result counts, while they were capped at 200, I think?) so it's presumably good enough.
Change 865027 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] NewImpact: Show "999+" when we could not count edits/thanks
Change 864910 had a related patch set uploaded (by Kosta Harlan; author: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.12] NewImpact: Show "999+" when we could not count edits/thanks
Change 864911 had a related patch set uploaded (by Kosta Harlan; author: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.13] NewImpact: Show "999+" when we could not count edits/thanks
Change 864910 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.12] NewImpact: Show "999+" when we could not count edits/thanks
Mentioned in SAL (#wikimedia-operations) [2022-12-06T10:16:52Z] <kharlan@deploy1002> Started scap: Backport for [[gerrit:864910|NewImpact: Show "999+" when we could not count edits/thanks (T324286)]]
Mentioned in SAL (#wikimedia-operations) [2022-12-06T10:36:25Z] <kharlan@deploy1002> kharlan and kharlan: Backport for [[gerrit:864910|NewImpact: Show "999+" when we could not count edits/thanks (T324286)]] synced to the testservers: mwdebug2002.codfw.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2001.codfw.wmnet, mwdebug1001.eqiad.wmnet
Mentioned in SAL (#wikimedia-operations) [2022-12-06T10:48:17Z] <kharlan@deploy1002> Finished scap: Backport for [[gerrit:864910|NewImpact: Show "999+" when we could not count edits/thanks (T324286)]] (duration: 31m 25s)
Change 864911 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@wmf/1.40.0-wmf.13] NewImpact: Show "999+" when we could not count edits/thanks
Mentioned in SAL (#wikimedia-operations) [2022-12-06T15:43:30Z] <kharlan@deploy1002> Started scap: Backport for [[gerrit:864909|User impact: Do not show impact module if user has no mainspace edits (T324285)]], [[gerrit:865082|Localisation updates from https://translatewiki.net.]], [[gerrit:864911|NewImpact: Show "999+" when we could not count edits/thanks (T324286)]]
Mentioned in SAL (#wikimedia-operations) [2022-12-06T16:02:54Z] <kharlan@deploy1002> kharlan and urbanecm and kharlan: Backport for [[gerrit:864909|User impact: Do not show impact module if user has no mainspace edits (T324285)]], [[gerrit:865082|Localisation updates from https://translatewiki.net.]], [[gerrit:864911|NewImpact: Show "999+" when we could not count edits/thanks (T324286)]] synced to the testservers: mwdebug1001.eqiad.wmnet, mwdebug2002.codfw.wmnet, mwdebug1002.eqiad.
Mentioned in SAL (#wikimedia-operations) [2022-12-06T16:13:14Z] <kharlan@deploy1002> Finished scap: Backport for [[gerrit:864909|User impact: Do not show impact module if user has no mainspace edits (T324285)]], [[gerrit:865082|Localisation updates from https://translatewiki.net.]], [[gerrit:864911|NewImpact: Show "999+" when we could not count edits/thanks (T324286)]] (duration: 29m 43s)
Change 865027 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] NewImpact: Show "999+" when we could not count edits/thanks
