This can be tested once T269093: Deploy new language switching location to test wikis and begin A/B test pt 1

Over to @MNeisler for some thoughts.

Declining as per the comment above. We currently do not support IE11 on the mobile site.

Looks good!

@MNeisler - seems like we're all done here! I'm going to go ahead and resolve but feel free to re-open in case there's anything missing

WE can decline for now

This is also quite old. I'm going to go ahead and resolve. @alexhollender - let me know if you'd like to keep it open.

Declining this for now as PDFs have dropped in priority over the past few years.

In T284496#7143126, @matmarex wrote:

In T284496#7142981, @ovasileva wrote:

Can we backport this? Generally, this wouldn't be a blocker, but since there's no train next week, it would be nice to get a fix out sooner than the next train.

I would consider this issue a blocker, even if the impact is somewhat low, because message notifications are a hot topic right now (see https://en.wikipedia.org/wiki/WP:THEYCANTHEARYOU).

Moving to backlog for now - @Volker_E - feel free to bring this back into the sprint board whenever

In T262859#7142562, @phuedx wrote:

@ovasileva: @Jdlrobson and I are discussing how much of the survey should be visible on the screen before we log an impression. Currently, we log an impression when approx. half of the survey is visible. @Jdlrobson's patch supports changing that value if we want. Do we want to change this behaviour? If so, then how much of the survey should be visible before we log an impression?

Can we backport this? Generally, this wouldn't be a blocker, but since there's no train next week, it would be nice to get a fix out sooner than the next train.

In T274428#7140021, @matmarex wrote:

What is the reasoning behind the capitalization in "You have a new Talk page message"? I noticed this change recently (while working on DiscussionTools) and it was distracting to me.

In T257695#7140293, @Jdlrobson wrote:

@ovasileva patchdemo doesn't support QuickSurveys so to test this we'd need to enable a survey on the beta cluster. Do we want to do this now, or as part of a future deploy of a survey and skip QA this time round?

In T276566#7140307, @Jdlrobson wrote:

Basically we'll have the search button appear only and that will take people to the search results page directly? Do we have a mock for what this would look like? Would it be the magnifying glass or the actually submit button/button that says "Search"?

@ovasileva no mock but you can test this intermediate state on https://patchdemo.wmflabs.org/wikis/759bf35ffc/wiki/Main_Page?useskinversion=2

Rough set of questions;

• How does usage of the links decrease or increase before and after usage of the feature. For this, we will not be performing an A/B test, but rather a before and after comparison between the current implementation (for which we should have historical data via the DesktopWebUIActionsTracking schema and compare to the current implementation. Open question for this spike - does the new version track events in a similar way?
• Do these changes affect account creation - it's possible we might see an increase or decrease here. For this we would do a before/after comparison. Note: we're already tracking this in the desktop improvements superset dashboard: https://superset.wikimedia.org/superset/dashboard/153/

Thank you for opening this @phuedx!

Let's keep this task on hold for right now - tagging it as low, but would like to revisit once we have more data on the opt-outs from T269664: Determine opt-out rate for desktop improvements feature on test wikis pt 2

Looks good!

@alexhollender, @Jdlrobson - just to confirm the change to the AC: "At lower resolutions the search input is hidden search and only the submit button is shown. It should behave like a form submit link (e.g. submit the form with no input value). We'll wire this up in a later task T284242."

In T283811#7130854, @alexhollender wrote:

In T283811#7130634, @Jdlrobson wrote:

@alexhollender just to make it explicit, it sounds like you are okay with changing the default for all skins to show this link twice?

yes, I feel relatively confident that such a change won't rock the boat too much for legacy vector, monobook, and modern users. Though it might make sense to wait for @ovasileva to return before we finalize this?

In T273093#7134485, @Edtadros wrote:

@alexhollender @bwang is this in prod yet? I still don't see it.

@Volker_E - any updates on this one? If we're not planning on tackling it in the near future, I'd support moving it back to the backlog for now.

In T261842#7135316, @MNeisler wrote:

I rechecked the data logged in mediawiki_pref_diff and confirmed that we stopped recording final_state = 'vector' events on May 17th.

During my review, I noticed one event where a user switched from initial_state = 'vector1' to final_state = 'wikimediaapiportal' on api.wikimedia.org. See details regarding the event below: Any idea what occurs to fire this event? @phuedx

date	initial_state	final_state	edit_count	wiki	num_selections
2021-05-19	vector1	wikimediaapiportal	0 edits	api.wikimedia.org	1

Besides that one event, I don't see any other anomalies and events are logging as expected. @ovasileva I'll plan to go ahead and start on T269664 next week.

QA notebook

All found bugs are now tracked, resolving!

All done, resolving!