Mentioned in SAL (#wikimedia-operations) [2022-04-27T20:06:51Z] <catrope@deploy1002> Synchronized wmf-config/InitialiseSettings.php: Config: [[gerrit:784582|Halt the DiscussionTools A/B test (T291873)]] (duration: 00m 51s)

This has been deployed.

Change 784582 merged by jenkins-bot:

[operations/mediawiki-config@master] Halt the DiscussionTools A/B test

https://gerrit.wikimedia.org/r/784582

Firefox ESR on Debian 10. According to the font inspector, the sans-serif font is DejaVu Sans Bold, the serif is Linux Libertine O. I did play a bit with my font settings (years ago), but I think these two happen to be the defaults.

In T299814#7882857, @Tacsipacsi wrote:

On Patch Demo I see the following:

(Cyan line added by me.) The sans-serif font is noticeably taller, even though both fonts should be 28.8px according to the CSS inspector. This is unexplainable from a user perspective (if anything, the page title should be larger than the namespace, not the other way round), but cannot be fixed as it’s caused by the inconsistency between fonts. Is the different font really needed? The spacing is okay (especially if the inconsistent search field is fixed), but I’d avoid using multiple fonts in the title. Either serif or sans-serif, but not a mix of both.

In the current implementation the space is implemented as a margin, so will not be present if the title were copied.

Thanks for highlighting this @alexhollender_WMF and for the added context @Quiddity.

In T299814#7872517, @alexhollender_WMF wrote:

@Quiddity regarding search, I'm seeing two different sets of results depending on whether or not a space is there:

I'll schedule this for a backport this week.

Removing from QA's list. This was deployed several months ago. Moving to ready for signoff.

@Quiddity regarding search, I'm seeing two different sets of results depending on whether or not a space is there:

Re: spaces and copying - To elaborate a bit more:
The concern is that some users will either copy&paste, or manually type the title with the space(s), and we want to confirm that nothing will break from that.

@Esanders regarding the space that appears to be added between the namespace (e.g. Talk:) and the page title:

It's something that could be added in much the same way as we made sure the editing session ID was passed through, if that's required.

Ok. I think we can hold on to creating that task pending resolution T305541 . If we can ensure all posted topics and comments are logged correct as saveSuccess in EditAttemptStep, then I can reliably use that schema for the metrics that require determining pageview. But good to know this can be added if needed.

Having implemented the bold namespace change feature of page frames, I'm documenting some resulting inconsistencies we get with action pages. We may decide this isn't a problem, but just making a note of them anyway:

Change 784582 had a related patch set uploaded (by DLynch; author: DLynch):

[operations/mediawiki-config@master] Halt the DiscussionTools A/B test

https://gerrit.wikimedia.org/r/784582

Change 761986 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Remove limit on the number of topic subscriptions per user

https://gerrit.wikimedia.org/r/761986

Is there a page_token within talk_page_edit or can this be easily added?

Thanks for the summary @DLynch.

Quick definition: I'm going to use "editing schemas" to refer to EditAttemptStep, VisualEditorFeatureUse, and talk_page_edit, and "UIActions schemas" to refer to DesktopWebUIActions and MobileWebUIActions.

My comment in T303654#7856027 applies to this as well. Summary: if we set the sample rates the same in config, this should work.

Yes. Thanks!

Outcome of the conversation:

• @Ladsgroup is fine with the changes proposed in this task, but would like us to have a plan to make some of the improvements suggested in T294881#7707795 (even if we won't have the time to actually make those changes, just a plan is needed)
• Therefore I filed T306199, which describes a plan to remove some columns from the table, which would become possible after the work on T296801 is completed
• We can remove the limit on topic subscriptions

@ppelberg
Here are the completed reports for the logged-in and logged-out New Topic AB test analysis.
Logged-In New Topic AB Test: Report| Summary
Logged-Out New Topic AB Test: Report| Summary

Logged-Out Users KPI Results

Notes:

• We do not have data on the experience level of an anon user as we do not retain long-term data for these users. As a result, we are not able to account for the impact of experience level on these contributors. The data below reflects all logged-out contributors that were included in the AB test.
• Some metrics such as retention rate we are not able to accurately calculate given the limited long-term data tracked for anonymous users. Please see the full report for additional details on the methodology used to assess the impact of the new topic tool on logged-out users.

@ppelberg
For review, below is a summary of the results from the New Topic Tool AB Test analysis for logged-in users. Please see further details in the report. Let me know if you have any questions or suggested changes.

Next steps

• 1. @matmarex and @Ladsgroup to talk about whether removing the subscriptions is indeed a non-starter
• If "1." proves to be true, we'll need to scope work for deciding what happens when people approach/reach the 5,000 subscription quota.

@ppelberg - yes, that bit of text is a remnant from old designs, I will strike it out to not be confusing.

In T299814#7833532, @iamjessklein wrote:

I've updated the task description with the mockups.

@iamjessklein, a question:

• Within the **Clearer Visual Cues (aka Talking Affordances) section, what is meant by Highlight signature? I ask this having been operating with the understanding that we decided NOT to make changes to how and where peoples' signatures are presented.

I've updated the task description with the mockups. In our team discussion I would like to call out a few topics: