Thanks for the task, @Trizek-WMF! I checked what might be happening, and I found out that if you open multiple Add Link sessions in separate tabs, then you are able to complete all of them. This is because the quality gate limit is checked when you open Special:Homepage and when showing the recommendation to the user, but once you have the recommendation on the screen, you can always complete it.

In T382701#10444339, @Sgs wrote:

Maybe that's something we could re-think for the future to make module / page styles less bound, although I don't see any easy alternative aside from creating a new separate module so we could distinguish between page and module styles.

In T380405#10408634, @Pcoombe wrote:

@KStoller-WMF No, they were from banners run by the fundraising team as well (e.g. https://en.wikipedia.org/wiki/NASA?banner=B2122_0629_enLA_thanks_Join) following on from the main fundraiser in those countries. I think we found they were not as effective as the message on the donor Thank You page. @spatton would we want to keep the option to try these again?

Note: morelike (the old algorithm for topics) has the same problem, as it also loads its configuration through legacy Community Configuration. Since we don't need morelike anyway, I am not going to spend any time on migrating it. Instead, enabling both morelike and legacy Community Configuration will result in a fatal error from now on. I also filled T383329: Drop support for morelike support from GrowthExperiments to actually drop morelike support.

@Michael The same problem exists in the Selenium tests. I don't run Selenium locally, so it is not a problem for me, and we are apparently (slowly) migrating to Cypress anyway, so maybe we can leave that unresolved? Curious to hear what you think about this!

Done.

Thanks for the tip! The dumping URL is useful to know about.

In T381939#10397225, @Trizek-WMF wrote:

Isn't the Impact module updated twice a day?

Thanks @Trizek-WMF!

In T382709#10428228, @Mhurd wrote:

What version of Docker/Docker Desktop are you using? Your screenshot shows an update is available. iirc there were two relatively recent (last year or two) Docker Desktop on Mac versions which had bugs which prevented Mediawiki containers from working

Thanks for the update, this is very useful to know. The API works for me, and I can also see the data in the new stream. FTR, I wasn't building any automation around topics, I was checking a possible bug in GrowthExperiments and wanted to know what the topics are.

Moving back to QA. @Michael, I posted a (non-blocking) thought on the commit. I'd be curious to hear your thoughts about it!

I ran a quick query to see what pages exactly are affected. The following table shows MediaWiki.org Flow boards that start with Growth:

Boldly assigning to @Trizek-WMF (+CC @KStoller-WMF for awareness).

Note: The automated archival process blindly assumes all subpages are archives, and it ignores them as such. Unfortunately, at certain projects (such as MediaWiki.org, which is a part of phase 2a), this is largely untrue. Pages on MediaWiki.org are hierarchically organised, and the fact a page is a subpage doesn't mean anything all by itself.

In T382810#10428477, @Etonkovidova wrote:

Usually, e.g. cawiki - Usuari_Discussió:Zilant17 on a new Discussion page for users with previous Flow board, there is an indication (a link) to a moved page (e.g. on Usuari_Discussió:Zilant17 the link is to Usuari Discussió:Zilant17/Flow). Is it done by a different migration script/process?

I deployed the change as requested. @The_Discoverer @Pppery, please let me know if you need any help with deleting the dormant Flow pages.

Should be done now.

This is happening, because User::isNamed and UserSelectQueryBuilder::named have very different implementations. While User::isNamed checks for "is registered and is not temporary", UserSelectQueryBuilder::named only checks for "is not a temporary account". This is a bug that should be fixed...

In T381728#10411211, @Daimona wrote:

I've tested this again, including my custom dockerfiles, and it's looking great! I said this already, but the environment feels much faster now. Selenium tests seem to confirm this, with a -20% total time on the CampaignEvents extension, and similarly for core.

In T382709#10423624, @Daimona wrote:

For anyone who stumbles onto this, I'm able to reproduce the issue by running an apache2 docker container on a non-native platform via qemu emulation.
If you're seeing the issue from a Docker image, try changing the platform to match the host system.

Is this something you could try?

This is caused by T118024: When deleting StructuredDiscussion content, deleted content is misattributed to the sysop that deleted it. In other words: the user created something via Flow, that something was later deleted and due to T118024, the authorship of that something was transferred to the deleting admin. That makes finding what the content was way harder, but not impossible.

In T378827#10424041, @Stryn wrote:

Hi, could someone with the rights move fi:Wikipedia:Väärinkäyttösuodatin/Virheet to fi:Wikipedia:Väärinkäyttösuodatin/Virheet/Arkisto4 because the main "virheet" pages is meant to be used for abuse filter error reports.

Has unresolved code review feedback; moving back to Doing.

Thanks for the work on this! Looks like nothing to follow-up from Growth's side. Removing from tracking.

Adding Mutex posixsem to apache2 in the container appears to fix the issue. That being said, I'm not sure how exactly (and whether that might break things on other systems).

Nothing to review, and fully resolving this means breaking the enwiki experiment. Moving to blocked, for decision on next steps.

We'll take a look (but probably in January).

I attempted to find the events by browsing around related links from the docs page. I found the articletopic-outlink service, which produces its data to the mediawiki.page_outlink_topic_prediction_change.v1 stream. The Hive table corresponding to that stream is not empty, and it contained predictions that looked believable. However, I'm not updating the page based on what I found, as I have no idea whether I found the new way of doing things, or something unrelated that shouldn't be mentioned in this page.

In T373188#10417790, @Etonkovidova wrote:

The difference between the number of available tasks with all topics selected and other two numbers on Special:Search and Special:Newcomer Tasksinfo is relatively small. Is it acceptable to have such discrepancy even as small as it is now?