Moving back to ready for dev for the mobile changes Rita asked for.
Fri, Nov 8
This definitely looks like a very deep MCR/core issue to me, not at all a Growth team issue. I don't know how we came to be tagged on the related task, but this is way out of our area of expertise.
Thu, Nov 7
If Kosta is right about which change introduced this (I haven't double-checked but he probably is), then this bug hit production on September 5th.
This is now fixed
Tue, Nov 5
I've added the links to the relevant JSON pages. Note that Arabic has not currently defined an "expand" task type (is this missing, or do we not have templates for it?), so I didn't add that one.
Yes, this is perfectly reasonable.
Mon, Nov 4
Sat, Nov 2
With my patch:
Fri, Nov 1
The attached patch adds $wgGEHomepageSuggestedEditsRequiresOptIn. By default it's set to false, which means all users get the suggested edits feature (current behavior). If it's set to true, only users who enable the preference get the suggested edits feature. The preference is currently hidden, but it could easily be made visible if we decide we want that (we'd just have to write a label for it and get it translated).
I'm sure there's some language out there which doesn't use 10^3-based grouping...
Yes. Indic languages use 10^3 for the first group, then increments of 10^2 for all subsequent groups:
Thu, Oct 31
@RHo I had to change your CSS a little bit. Because of the weird way that widths of table columns are negotiated, the width: max-content trick you found doesn't work well. It worked in your codepen, but once I changed the text in the right-hand column to the Czech text (and applied the 700px width constraint and 14px font size used in the dialog), the extra width of that text caused the right column to grow and the left column to shrink, so the "Středně obtížné" text still wraps. The solution I found was to keep width: 20% (which functions more like a min-width, and min-width itself doesn't work), then preventing wrapping using white-space: nowrap
Rita's CSS tweaks: https://codepen.io/reets/pen/eYYEwXr
Wed, Oct 30
I couldn't find another task offhand for changing the label of the filter button to "Easy, Medium difficulty" instead of just "Easy, Medium", so I linked the patch for that to this task. Let me know if you'd like it to be linked to a different task instead.
Tue, Oct 29
@Tgr says the ConfigurationLoader service returns this information
Wed, Oct 16
In debug mode the cache control headers are set to no-cache
I'm not 100% sure that they are, but if they're not, they should be. And in any case, dropping the version param will lower the cache time to 5 minutes.
I would strongly encourage you to make iterative improvements to Vector where possible. There is value in writing a new skin, yes, but a lot of what the Desktop Refresh project aims to achieve, especially more consistency between the desktop and mobile experiences, can be done with small iterative changes, so I suggest starting with that first.
Tue, Oct 15
Regression rGOJU6689fe50461b: WikimediaUI theme: Use `px` instead of `em`s, which changed left: Nem; to margin-left: -Nem; for no apparent reason.
Oct 4 2019
I've put two patches in Gerrit that sketch out how I think this would be done. I'll come back to them tomorrow and test them properly etc.
Oct 3 2019
I also visited the URL https://en.wikipedia.org/w/index.php?limit=50000&title=Special%3AContributions&contribs=user&target=Heymid&namespace=&tagfilter=&start=2005-01-01&end=2017-06-30 and got a response in 16 seconds (according to mw.config.get( 'wgBackendResponseTime' ). So it looks like these timeouts might have been a fluke, somehow?
I also tried running this query on the production DB server that logstash says served this query db1105:3311, which is listed as the contributions replica. It took 9 seconds instead of 5, which is slower than on the analytics replica but still nowhere near 60.
I tried running this query on stat1006, and it only took 5 seconds. But logstash shows Expectation (readQueryTime <= 5) by MediaWiki::main not met (actual: 59.138929128647), and the query failing with an error code of 0 (so probably a 60-second timeout?). Maybe it's being sent to a DB server that doesn't have the right indexes for contribution queries?
Turns out, we are correctly capping the limit already!
Oct 2 2019
As a proxy for the number of pages a user has their signature on, I looked at the number of pages that link to their user talk page. Here are the top 100 linked-to user talk pages on enwiki:
There are 15 users whose signature appears on >100k pages (and 9 of them are bots), a couple dozen over 50k, about a hundred over 25k, and just under 500 users over 10k. So it looks like having your signature used on 10k pages is decently common, but having more than 50k is uncommon and more than 100k is rare.
That's a very good point, thanks for raising it. One particularly worrisome variant would be if a user who has signed a bunch of comments in a bunch of different places either turns malicious or has their account compromised, and changes their signature preference to something that's so bad that it's oversight-worthy (e.g. doxing, death treats). In that situation, oversighters wouldn't have good tools to get rid of it: you could remove the signatures from existing discussions even without necessarily needing to oversight those edits, but there would be too many places the signature is used to feasibly do this. The proper way to fix this situation is to change the user's signature to something non-terrible, but admins/oversighters don't have the power to change another user's preferences (nobody does).
Oct 1 2019
Yes, that sounds correct to me. Based on your second bullet point, I propose that we do the configurable storage backend and the TTL change, but that we keep storing timestamps separately for now unless and until we find (or you tell us) that it's better to store them in pairs. In other words, we'd do the first and third item from the check list in the task description, but we'd hold off on the second item for now. Does that sound OK?
Sep 30 2019
Sep 28 2019
Sep 27 2019
Sep 26 2019
This is a normalization bug in Parsoid. The output technically isn't incorrect, but it's unhelpful.
Sep 24 2019
This happened because the change above moved the padding to make room for the header from the overlay div to the overlay-content div, and Special:Homepage already had a different padding rule on overlay-content, which overrode Minerva's new rule.
git bisect blames rSMINd8deb264f2b5: Only apply padding-top to overlays with headers, which sounds quite plausible.
This appears to be a regression in MinervaNeue between wmf.22 and wmf.23.
Sep 19 2019
This is on hold while @MMiller_WMF decides whether we should disable it, or keep it enabled. It's been enabled for about two and a half weeks now, since September 3rd at 12:19 UTC (which is when wmf.20 was finally fully rolled out; this was supposed to happen on August 29th, but was delayed).
It turns out this is a regression from rEGRE5ef7faffb42e: Invert configuration, defaulting features to "on", for T229389: Invert configuration for GrowthExperiments.
Sep 18 2019
Turns out this only happens for users who don't get assigned to a WelcomeSurvey group (i.e. don't automatically get shown a survey after account creation), and it only affects the case where you force the survey to appear by manually navigating to Special:WelcomeSurvey with the ?group=exp2_target_specialpage parameter.
I can reproduce this both on testwiki and locally. Rolling back GrowthExperiments to wmf.22 or wmf.21 locally didn't help, so the culprit is probably somewhere else. Going to try rolling back core next.