In T375264#10290297, @Cparle wrote:

Just so we'll be able to estimate the number of SD statements this is resulting in, here are the current counts (before deployment of the patch) of source:P7482=file available on the internet:Q74228490 with the qualifier operator:P137=<the operator of the website where the image originated> for each of the origin sites we're adding data for

Facebook: 0
Google: 1
Instagram: 0
Pinterest: 2
YouTube: 1 image, 7 videos
GettyImages: 0
Reddit: 0
shutterstock: 1
alamy: 0
istockphoto: 0
tiktok: 0
amazon: 1

Checked on testwiki wmf.2 by creating new user accounts - one new account was presented with the Community update module, another new account did not have the module on Special:Homepage.

In T221258#10277976, @Michael wrote:

QA Note: This change should not cause any user-visible changes at all. But if anything seems out of the ordinary with Notifications (or emails or push messages), then please highlight that here.

Checked in testwiki wmf.2 - works as per the AC:

• when the Help panel is disabled in (Main) namespace via Special:Communityconfiguration/HelpPanel option, Suggested Edits articles still display the Help panel as usual. The editing surface will load and work as expected.
• the Help panel won't be present in non-Suggedted Edit articles

Checked on wmf.2 - no error reports, see logstash link. The last timestamp is Nov 5, 2024 @ 21:03:34.732 (for wmf.1).

In T129284#10299121, @Nikerabbit wrote:

Being bold here. Looking forward to if we some day get a better replacement for beta cluster.

In T154156#10297613, @Pppery wrote:

Flow-based User talk pages are in read-only mode

only true on some wikis. Flow is still editable on MediaWiki.org where there are thousands of talk page messages.

But at the same time Flow is dying so if there truly is a Flow-specific bug here it's not worth fising.

Checked locally

• e,g, $ php CommunityConfiguration/maintenance/UpdateEmergencyDefaults.php --wiki=enwiki GrowthExperiments HelpPanel outputs

Updated emergency defaults for HelpPanel.

• CommunityConfigurationFallbacks/ exists for extensions/GrowthExperiments with php files

CommunityUpdates.php      
GrowthHomepage.php        
GrowthSuggestedEdits.php  
HelpPanel.php             
Mentorship.php

I re-checked the steps on testwiki wmf.2 - the issue was not reproducible.
The following items from the issue description are not applicable anymore:

• the issue was happening on Flow-based or wikitext-based User talk pages; presently, Flow-based User talk pages are in read-only mode. The new User talk pages do not show the issue
• the issue description refers to "Press Esc to cancel" the wikilove popup - presently it's not possible to dismiss the popup with the Esc button
• no duplicate Echo notifications are sent
• no duplicate wikilove messages are displayed on User talk page.

In T378781#10293929, @Quiddity wrote:

Thanks! This seems resolved, albeit just from a single test. -- I successfully moved mw:User talk:Quiddity (WMF)/sandbox11 to mw:User talk:Quiddity (WMF)/sandbox11-1.

Checked on beta for mediawiki.product_metrics.homepage_module_interaction stream - works as expected.

In T375753#10287635, @Urbanecm_WMF wrote:

I spot checked production regarding this, and it looks good, except enwiki:

mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count(*), up_value from user_properties where up_property='growthexperiments-homepage-variant' group by up_value;
+----------+-----------+
| count(*) | up_value  |
+----------+-----------+
|  1226972 | control   |
|        1 | oldimpact |
+----------+-----------+
2 rows in set (14.031 sec)

mysql:research@dbstore1008.eqiad.wmnet [enwiki]>

Having over a million of control rows seems unexpected. We should probably check on this.

Checked in commons beta (thx, @Cparle for setting commons beta for testing ). The commons beta test results - https://phabricator.wikimedia.org/T377988#10291265; all looks as expected.

Checked in commons beta (thx, @Cparle for setting commons beta for testing).
What was checked:

• single uploads for

facebook' => 'Q631354',
google' => 'Q631355',
youtube' => 'Q631356',

• multiple uploads for the above when the sources are the same and when each file has a different source

Examples:

• google external links uploads P253154 (Operator) = Q631355 (Google) Special:Search P253154=Q631355
• described_at_url Special:Search P253095

In T376952#10285454, @Cyndymediawiksim wrote:

@Etonkovidova, We do not need to have testwiki in the title. Unfortunately I do not have the permissions to rename the charts(i think that right is reserved for the creator of the chart). Pinging @mforns for visibility and help us in renaming. :)

@Sgs - the spec says that all value aside from oldimpact should be removed, but on cswiki beta I see community-updates-module. Is this expected?

(cswiki)> select distinct (up_value) from user_properties where up_property='growthexperiments-homepage-variant';
+--------------------------+
| up_value                 |
+--------------------------+
| community-updates-module |
| oldimpact                |
+--------------------------+

Thank you, @Michael! Checked in beta for different fields/
providers and for null edits - all changes properly saved and displayed; the diffs shows only relevant changes.

In T376952#10285392, @Cyndymediawiksim wrote:

@KStoller-WMF , yes, dashboard renamed : https://superset.wikimedia.org/superset/dashboard/552/?native_filters_key=AUB2ivDvicidAvj-J9KKBoUCzk1TFk1iiQD7jxLbTKk37pVSr435BzTs0UFWpRRm

In T376952#10276864, @Sgs wrote:

We have enabled CommunityUpdates in test2wiki, I tested events are sent but not sure if they are ingested. @Cyndymediawiksim could you check if the events are properly ingested and we can see the data in the existing dashboard? Ty!

Thank you @EdoAug for the detailed report! Confirmedb - the popups of ?tour=test will not fit the width of mobile viewports (below is the screenshots for width=430):

Checked on eswiki beta. Two new accounts: user_id-4343 - didn't get the CommunityUpdate module; another user, user_id=4344 - got the CommunityUpdate module.

@Michael - it seems that I cannot correctly supply the provider's name for the script. I thought that the field's name is a provider's name, e.g.EHomepageSuggestedEditsIntroLinks - but it's not correct.
Where the providers' names are stored? I couldn't find them in extension.json, but probably I just didn't know how to look.

@Sgs - the variant "community-updates-module" will be stored in user_properties table? The new user accounts created on cswiki beta do not get Community update module displayed on their Homepage.

Checked in wgGESurfacingStructuredTasksEnabled beta - default is false; the flag enabled on beta wikis. Checking on enwiki (thx, @Michael for the instrucitons!) - link recommendations are available in read mode and suggested edit surface is available in Edit mode.

In T374124#10268986, @Michael wrote:

QA Note: This change only affects the PageTitleControl and CommonsFileControl components. They can be both tested on the CommunityConfiguration form for CommunityUpdates, for example on https://cs.wikipedia.beta.wmflabs.org/wiki/Speci%C3%A1ln%C3%AD:Komunitn%C3%AD_konfigurace/CommunityUpdates

There should be no significant behavior change from this task.

In T357699#10267641, @Sgs wrote:

@Edtadros would you mind sharing the tool you use for contrast checking? I used FF accessibility tool in the past for non dark-mode related issues but it seems it does not work for our case since it does not pick up the font color has been inverted (that's my hypothesis).

An example of the reports with included cypress tests: https://integration.wikimedia.org/ci/job/quibble-vendor-mysql-php74-selenium/47611/console

Checked in testwiki wmf.28 - a user input is saved, regardless whether a page exists or not. The link to a non-existing page is displayed as a blue link in Help module on Special:Homepage.

In T365727#10251931, @Michael wrote:

I very much appreciate the work on this 💚 ! But I think closing it might be a tiny bit premature.
Let's wait till these changes reach at least Group 2 on Thursday. Then we can keep our eyes open for the Unable to fetch suggested edits count for user {userId}; no user impact found.-message and start figuring out what is going on with that. In that context, we can then open a new task for that and close this one.

Checked in wmf.28 - no regression in functionality for new accounts or old accounts.

Checked on testwiki wmf.28 - checked new account creation (Homepage guided tour) / email confiramtion - all fixes are in place:

Checked on wmf.28 - the issue has been fixed. I filed a follow-up task T378153: Homepage: deselecting all task types doesn't change SE task counter.

The last timestamp for the error is Oct 21, 2024 @ 09:38:19.928 (logstash link) - can this tak be closed?

Checked on testwiki wmf.28 - seems to be working according to the specs.

In T377783#10249310, @Urbanecm_WMF wrote:

...I could swear there used to be a visible "No recommendation found" for this error scenario... Or maybe that was for Add Link only? Assuming my memory serves right, then we have an actual bug (that would probably appear in production too, under the right circumstances), and that we should probably fix separately to this.

In T377907#10255498, @Urbanecm_WMF wrote:

Tested at testwiki while backporting this, seems to work there as well. Should land within a couple of minutes!

In T377907#10253132, @Michael wrote:

I can reproduce the problem on testwiki, unsure what the cause is. When I try to edit another article, I get an "Editnotice links" pop-up:

Is that supposed to be there? If it is unexpected, could that be what colliding with our UI?

In T377868#10252397, @KStoller-WMF wrote:

Do you think we need working Add Image on other (beta) wikis besides cswiki beta? If so, which ones? Maybe pilots?

Yes, perhaps we should do this for eswiki beta and frwiki beta since we plan to pilot test Surfacing Structured Tasks work (T362584) on those two wikis. Should we just update this task to include them as well?

+1 to have ADd image on pilot wikis.

Checked in commons beta - the wikitext, e.g. {{User:TestUser/photographer|camera=}} will be displayed without added square parentheses. Moving to Verify on Production since commons beta doesn't allow to test Template:User fully.

Verified on commons beta - works as expected. The wikitext, e.g. if "Author's name" preference in UploadWizard is [[User:Example|Example]], a user name will be correctly displayed on a file page.

In T357806#10243755, @Samwilson wrote:

Probably! I've created T377636: UploadWizard: Unable to use wikitext in "Author's name" preference.

Re-checked on cswiki beta - the same scenarios as in https://phabricator.wikimedia.org/T376124#10215805

In T367936#10238825, @Urbanecm_WMF wrote:

(1) Values like 3e10 are accepted. The success confirmation is displayed and the value gets stored in MediaWiki json file.

Since introducing a warning system to Community Configuration would be a substantial project, I propose we don't do anything about this for now (at least until this actually confuses someone). @KStoller-WMF @Etonkovidova @Michael, does that sound like a good approach to you?

In T357806#10241454, @Samwilson wrote:

I think possibly the recent change to uw.deed.OwnWork.js is perhaps now breaking the case in which the upwiz_licensename preference is a custom value. For example, I've got that preference set to a template (which has worked fine for years), but it's now ending up with this sort of thing: |author=[[User:Samwilson|{{User:Samwilson/photographer|camera=}}]] which isn't correct. Maybe that preference isn't meant to be arbitrary wikitext, but if that's true then it should say so. Maybe this is a case of XKCD #1172.

In T375704#10228582, @Sgs wrote:

I believe these errors could be produced by engineers when developing the integration with MP in T375525 which was around the time. The error has not reproduced since Sep 26, moving to Test in production for monitoring next Sprint and resolve if not seen again.

Checked on testwiki wmf.27 (with uselang=pl). The message in the task description displays user gender preference: