In T241180#5828334, @Jhernandez wrote:

In T241180#5827364, @egardner wrote:

There will be some limitations to this approach:

1. we'll rely on Vue's built-in template compiler for the time being, which means shipping a little bit of additional code in production;

This is irresponsible. For the amount of traffic we have, the amount of extra computation we are going to force on millions of clients because of our inability to get our process together.

I don't think that that would help. I was measuring mtime deltas not because I think there's a bug of the type you're alluding to, but as a proxy for finding out whether the bad servers generated their cache files very shortly after the scap happened. If the cache file is only a tenth of a second younger than the settings file, that might indicate some sort of race condition, but at 0.25 seconds that's less plausible, and at 3 seconds it's definitely not plausible.

It happened again today, with this patch. This time I left it broken for a while so I could investigate.

Thanks to Giuseppe I got dsh+keyholder to work: SSH_AUTH_SOCK=/run/keyholder/proxy.sock dsh -r ssh -F 20 -M -g mediawiki-installation -o -i/etc/keyholder.d/mwdeploy -o -oUser=mwdeploy -o -oBatchMode=yes -- 'echo "echo \$wgGEHomepageSuggestedEditsTopicsRequiresOptIn ? \"BAD\" : \"good\";" | sudo -u www-data php /srv/mediawiki/multiversion/MWScript.php eval.php --wiki=cswiki | head -n 1'

I encountered this bug again today, when deploying this config change. My teammates reported that the feature we'd just enabled was working about half the time, which likely means that about half (or at least a significant fraction, much more than 10%) of the app servers had an outdated config, I tried to use dsh to count how many app servers were affected, but I couldn't get keyholder to work.

It looks like @kaldari has updated the wiki page: https://www.mediawiki.org/w/index.php?title=Requests_for_comment%2FURL_shortener&type=revision&diff=3618236&oldid=2842533

Supplementing this with the reasoning that Amir provided in his commit messages, and highlighting what the changes are:

In T242052#5813863, @MMiller_WMF wrote:

@Tgr -- okay, I just talked to @Catrope about wanting to SWAT this on Tuesday. Because we don't want there to be a few days of the topic era that don't have this element as part of their events.

The config patches are done. The next step is for @Trizek-WMF to set a deployment date for each wiki.

The config patches are done. The next step is for @Trizek-WMF to set a deployment date for each wiki.

Which namespace(s) and/or categories the Help panel search should handle = https://hy.wikipedia.org/wiki/%D4%BF%D5%A1%D5%BF%D5%A5%D5%A3%D5%B8%D6%80%D5%AB%D5%A1:%D5%8E%D5%AB%D6%84%D5%AB%D5%BA%D5%A5%D5%A4%D5%AB%D5%A1:%D5%95%D5%A3%D5%B6%D5%B8%D6%82%D5%A9%D5%B5%D5%B8%D6%82%D5%B6

@Trizek-WMF: We don't support category search here yet, you can only search in entire namespaces. Right now, all wikis that have the help panel search in namespaces 4 (Wikipedia) and 12 (Help).

Which namespace(s) and/or categories the Help panel search should handle (0 is mandatory) = 0, 4; Kategória:Segítség

I don't believe 0 is mandatory here at all. The normal setting is 4, 12 (Wikipedia and Help). We also don't have support for searching in categories right now.

On which namespaces it have to be deployed = 0, 2, 4

Shouldn't this be 2, 4, 12? That's how all our existing wikis are configured. Including 0 worries me in particular. See also T231720#5811842

The ukwiki patch does not enable the help panel in the main namespace in read mode, even though that was requested, because it's unusual and we've never done it before. If we decide that is desired, we can do it, but for now I'm erring on the side of caution. I brought this up on the Ukranian-specific task at T231720#5811842.

On which namespaces it have to be deployed = 0, 2, 4

Just checking, this means the help panel would appear in read mode on pages in the main, User and Wikipedia namespaces, but not in the Help namespace. Is that intended? On every other wiki that has the help panel, we don't enable it in the main namespace, and do enable it in the Help namespace (in other words, we do 2, 4, 12). Note that this is just about where the help panel appears in read mode; in edit mode it will appear in every namespace.

The patch above is incomplete, we'll need to add the URLs of the translated privacy policies once they're available. Assigning to @MMiller_WMF since he's the liaison with Legal for that.

This is ready to go, waiting on a decision from @MMiller_WMF as to when to deploy this. We probably want @nettrom_WMF to be around?

I can't reproduce this on desktop Chrome (with or without mobile emulator), desktop Firefox (with or without mobile emulator), or mobile Chrome (on Android). Does this only happen on iPhones? Does it happen in desktop Safari too?

For completeness: if you want to turn topic matching back off and test the UI that normal users see, you can run step 3 but with the 1 changed to a 0:

new mw.Api().saveOption('growthexperiments-homepage-suggestededits-topics-enabled', 0).done( function() { window.location.reload() });

Looks good to me

In T241180#5801407, @Jdrewniak wrote:

I'm very excited about this proposal and eager to adopt a modern framework like Vue!
I think there's still a lot of infrastructure that needs to be put in place to take advantage of single-file components, and I'm wondering what the developer experience is like without them.

Supporting single-file components wouldn't actually be that hard at all. With small modifications to our existing infrastructure, we could have ResourceLoader automatically remap SFCs to JS component definitions (with the template as a string), because this transformation is very simple. We wouldn't be able to support ES6 or scoped styles though (because those depend on preprocessing steps that use nodejs libraries).

In T242400#5803375, @Dyolf77_WMF wrote:

I created the page and made the changes as suggested.

In T223988#5775582, @Hmxhmx wrote:

@Catrope Would that PR also solve the same problem with dates in Special:Notifications?

I've scheduled the config patch for the 19:00 UTC SWAT on Thursday Jan 16. The train should already have run by then (it's scheduled for 14:00-15:00 UTC).

Once this is deployed, the following console snippet will enable topic matching in production:

new mw.Api().saveOption('growthexperiments-homepage-suggestededits-topics-enabled', 1).done( function() { window.location.reload() });

To turn it back off, change the 1 to 0.

I think having the branch be cut at a fixed time would be good in general, because it would make the process more predictable. It would be helpful if the branch cut happened late enough in the day that there's an opportunity for people to merge patches on Tuesday morning in time for the train, but I also recognize that you can't both cut it late enough that developers on the US west coast have a chance to merge patches (say 18:00 UTC) and also cut it early enough that a releng team member in Europe can run the train (which currently happens at 14:00 UTC, when it happens).

There are some issues with the existing code in MachineVision that I ran into when I copied it to GrowthExperiments:

• It depends on mediawiki.template.mustache+dom, which is in the WikibaseMediaInfo extension (MachineVision already depends on WBMI, but it doesn't make sense for GrowthExperiments to depend on WBMI)
• The mustache+dom templating engine avoids destructively rerendering embedded OOUI widgets, which is good, but it does destructively rerender nodes created by the template. This is a problem, because it breaks CSS transitions for state changes.
• Because CSS transitions don't work, the widget uses CSS animations instead. But that causes a bug where the widgets animate (the text moves from left to right) when they're being unhidden or added to the DOM.
• There is no clean group widget for these, so I had to make one by picking the relevant pieces from ImageWithSuggestionsWidget (which contains a lot of other things as well). Without that, the SuggestionWidgets don't behave correctly, because they rely on a CSS class set on the parent element to hide the outline.
• These widgets don't extend SelectWidget and OptionWidget, which means you have to reinvent some wheels around selection management and getting the selected values from the group widget for example

The config page for Arabic is here: https://ar.wikipedia.org/wiki/%D9%85%D9%8A%D8%AF%D9%8A%D8%A7%D9%88%D9%8A%D9%83%D9%8A:NewcomerTopics.json

Like Kosta I also ran out of time, so I'll put this back in the pool so that either Kosta can pick it up in his morning, or I can pick it up in my morning tomorrow.

The button doesn't do anything yet when clicked, but I'm going to implement that as part of T238612

In T238610#5756884, @RHo wrote:

hi there - I think the mock-ups were based on the v1.0 'final mocks' which have since had minor text changes. I've just updated to match what's in the copy doc and happy to go with option B as well.

These are now done:

• Czech: https://cs.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json
• Korean: https://ko.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json
• Arabic: https://ar.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json
• Vietnamese: https://vi.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json

I have transferred the config to this page on viwiki, which is protected so that only admins can edit it: https://vi.wikipedia.org/wiki/MediaWiki:NewcomerTopics.json

In T240512#5787027, @MMiller_WMF wrote:

@kostajh @Tgr @Catrope -- when I try this on Czech or Korean Beta, I am able to select a task type from the dropdown, but the topic field remains free text, with no choices. Does something need to be changed?
I'm here: https://cs.wikipedia.beta.wmflabs.org/wiki/Speci%C3%A1ln%C3%AD:API_p%C3%ADskovi%C5%A1t%C4%9B#action=query&format=json&list=growthtasks

@MMiller_WMF @RHo The copy for the "base paragraph" is significantly different between the mockups for this task, and what's currently in production. What should the base paragraph be? And should this be different depending on whether topic matching is enabled or disabled?

The difference is because Arabic Wikipedia's MediaWiki:Common.css has a rule .mw-body-content { font-size: .95em }, which makes all text ~1.12x the size it would normally be. We use ems (which are relative to the font size) for sizing the text, but px (which are absolute) for sizing the box, so the text grows while the box doesn't. If we would use ems for the box's height, the box would also grow 1.12x and everything would fit again.

In T235723#5662029, @RHo wrote:

hi @Catrope - there's a few minor style issues on the desktop version of the overlays which I've listed below (will keep all style issues for the mobile version of overlays tracked on the T234854).

Intro overlay

(1) Subheader text should be slightly smaller and have a greater line-height across all versions: .mw-ge-startediting-dialog-intro-general-subheader {font-size: 16px; line-height: 1.375;}

We hadn't yet updated the icon, but we had been using the old icon but enlarged and positioned in a better way. This regressed in rEGREa64079ba6964: Suggested Edits: Use Drawer component on mobile, which broke the mobile-specific styling for this icon by introducing a typo in the CSS class name for its wrapper. The first patch fixes the typo and restores the old styling. I'll submit a patch to use the new icon after lunch.

Since this also changes the email notifications for watchlist edits (from the old style to the Echo style), this will need to be rolled out carefully. We'd be moving a lot of people's cheese, and some pretty important cheese at that.

In T238888#5731138, @kostajh wrote:

I've merged the patch which adds a new preference for tracking this variant, but as I wrote in T238888#5696207 I'm curious if we plan to add individual preferences for every variant or if we should use a single preference that contains the various variant groups that a user might be in.

In T232396#5730324, @MMiller_WMF wrote:

@Catrope -- how will your implementation handle users who change their preferences manually? Does it, like, automatically turn off help panel if a user turns off homepage? Or is more like it sets them both on for a user, but then whatever happens after that is up to the user?

It's the latter: at signup time, we will either enable both or neither, but after that the user can do whatever they want in their preferences. There are still separate preferences for the homepage and the help panel, and the user can choose to turn on/off one but not the other.

Once this patch is merged, remember to remind the ambassadors to get the changed messages retranslated (they are growthexperiments-homepage-startediting-subheader-edit-typo and growthexperiments-homepage-startediting-subheader-other).

I did a bit of thinking about what a WatchedItemStore-like solution could look like. Here's my best idea so far:

• When marking a notification as read:
  • Check if the notification is already marked as read in the DB; if it is, bail
  • Add its ID to the cached going-to-be-marked-as-read list in MainStash (using merge())
  • Enqueue a job to mark it as read in the DB
  • Purge the cached notification count in WANCache
• When computing the notification count (i.e. the getWithSetCallback calback for the cached notification count in WANCache):
  • Get the going-to-be-marked-as-read list from cache
  • Query the number of unread notifications from the DB
  • Subtract the length of the going-to-be-marked-as-read list from the DB query result, and return that
• In the job that marks things as read:
  • Update the DB to mark the notification as read
  • Remove the notification from the going-to-be-marked-as-read list (using merge())
  • Purge the cached notification count in WANCache (needed for convergence after race conditions, see below)

Going one step further: config being both a request property and a service seems weird. I think we should make up our mind about which one it is. I'd suggest that the config should be a service, not a request property, and so we should not just deprecate RequestContext::setConfig(), but also (soft-)deprecate RequestContext::getConfig() and move away from it in favor of the MainConfig service. There is a little bit of precedent for this, we deprecated ResourceLoaderContext::getConfig() this year.

I'm not sure yet which one I prefer. I think that A is messy and confusing, but that B and C would probably work. I like declarative things generally, so I like B for that reason, but I also like the flexibility of C. (They're also not mutually exclusive, we could support both.)

I'll just start throwing around some ideas here:

It turns out the other tasks were not related, this was just a bad type hint.

We don't need to do any special work for this task, and T238888: Variant tests: "initiation" test is already in code review, so I think this task can go into the backlog.

For the record, I ended up implementing this slightly differently than I had said I would. The random selection of who does and doesn't get the suggested edits module pre-initiated is only done for accounts that were randomly assigned to get the homepage, not for all new accounts. This means that all users who are in the control group and then enable the homepage manually will see an un-initiated suggested edits module (as opposed to half of them seeing that and the other half seeing a pre-initiated one).

Scratch that -- going to deploy it now because there are no deploys tomorrow.

Scheduled for Wednesday November 27 at 23:00 UTC (~24 hours from now)

This can be deployed in any SWAT window of our choice