Page MenuHomePhabricator

Enable talk for mobile users on enwiki
Closed, ResolvedPublic

Description

Description

Feature summary (what you would like to be able to do and where):
Enable the talk links for all mobile users on the English Wikipedia.

Benefits (why should this be implemented?):
This has been requested following a community RfC at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=1050972680#Enable_Article_/_Talk_tab_bar_for_mobile_anon_users

NOTE: Current deployment data: Week of Nov 8

Acceptance Criteria

  • Enable talk tab at the top of the page for anonymous users on the mobile site for English Wikipedia
  • Perform full QA across different namespaces

Signoff criteria

Related Objects

Event Timeline

Specifically:

For 'wgMinervaTalkAtTop'

set

'enwiki' => [
'base' => true,
'beta' => true,
'loggedin' => true,
]

Xaosflux changed the subtype of this task from "Feature Request" to "Task".Oct 20 2021, 11:53 PM
Xaosflux added a subscriber: AlexisJazz.
Juan90264 added a project: User-Juan90264.
Juan90264 moved this task from Backlog to Working on on the User-Juan90264 board.
Juan90264 subscribed.
ovasileva triaged this task as Medium priority.Oct 21 2021, 9:33 PM
ovasileva added a project: Web-Team-Backlog.

Thanks for filing @Xaosflux. We will review and add next steps and a tentative implementation plan in the next couple of days.

Change 732705 had a related patch set uploaded (by Juan90264; author: Juan90264):

[operations/mediawiki-config@master] Enable talk for mobile users on enwiki

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

Hey everybody, we’ve done an initial review on this request and have come up with the following as a rough outline of the process we’d like to follow before implementing the change:

  • Before implementing the change, we would like to collectively define some success criteria for the feature (this is standard practice for any new feature introduction on the mobile site). In particular, we’re interested in measuring any significant increase to revert rates to edits on talk pages. In the past, we’ve studied how anons and new editors approach the talk page on mobile and have noted some amount of confusion - people think it’s a general discussion, similar to a comments section on other websites, while others assume it’s a place to ask questions about the wikis in general, such as “how do I edit?” I think this creates a potential risk for high revert rates on mobile.
  • We would also like to research whether readers who are not attempting to edit will understand the purpose of a talk page link shown at a prominent location. We can focus on performing some additional research on readers that will allow us to understand how these readers will interact with the link. A potential evaluation here might include studying how long people spend on a talk page after they click, as well as additional user testing focused on understanding their expectations for the page.
  • I know the goal of adding the talk page link is to make it easier to discuss with anonymous editors. Are there any additional things we want to measure around this goal? For example, we could look at a decrease in reverts for anons overall, or an overall decrease in blocks to all anon editors.

Potential next steps:

  1. We can begin by adding the talk link to the bottom of the page, which would alleviate the concern for creating confusion for readers above. This implementation would still carry some risk for revert rates, however, so we should be ready to report on reverts to talk page edits before and after the change. In terms of timeline, if no new instrumentation is required, we can make the first change within two weeks of agreeing on the success criteria.
  2. If the revert rates from the first change are within a reasonable range (TBD), continue with identifying potential user testing scenarios for readers. Due to other commitments, the timeline for this would be within the next 4-5 months.

How does all this sound?

hey, I wanted to add another thought here. As noted by several folks in the RFC discussion on Village Pump, screen real estate on mobile phones is limited, and screen real estate at the top of the screen is almost extra sacred. Anything we add there is, on some level, a distraction from the article content (which is what most people are coming for). We all recognize the importance of additional elements (page notices, article quality indicators, links to talk/history, etc.), so this is somewhat of a balancing act we have to figure out. What is essential? What is important but not essential?

I noticed that on Sweedish Wikipedia, which serves as our test-case for the Article/Talk tabs, they've added an additional element to that area for location-based articles:

Screen Shot 2021-10-22 at 2.41.00 PM.png (683×391 px, 127 KB)

As with other elements listed above this element can be considered important, no doubt. But again, it's a balancing act, and I think we should keep in mind that if we add the Article/Talk tabs to the logged-out view, there will possibly be additional elements added to that area in the future. I don't want to be pessimistic, or alarmist, but I do think it can be a slippery slope and we should be very cautious with adding any non-essential elements to that top area.

Just wanted to leave a note here that we've posted an update with some questions on VPP as well.

Hey everybody, we’ve done an initial review on this request and have come up with the following as a rough outline of the process we’d like to follow before implementing the change:

  • Before implementing the change, we would like to collectively define some success criteria for the feature (this is standard practice for any new feature introduction on the mobile site). In particular, we’re interested in measuring any significant increase to revert rates to edits on talk pages. In the past, we’ve studied how anons and new editors approach the talk page on mobile and have noted some amount of confusion - people think it’s a general discussion, similar to a comments section on other websites, while others assume it’s a place to ask questions about the wikis in general, such as “how do I edit?” I think this creates a potential risk for high revert rates on mobile.
  • We would also like to research whether readers who are not attempting to edit will understand the purpose of a talk page link shown at a prominent location. We can focus on performing some additional research on readers that will allow us to understand how these readers will interact with the link. A potential evaluation here might include studying how long people spend on a talk page after they click, as well as additional user testing focused on understanding their expectations for the page.
  • I know the goal of adding the talk page link is to make it easier to discuss with anonymous editors. Are there any additional things we want to measure around this goal? For example, we could look at a decrease in reverts for anons overall, or an overall decrease in blocks to all anon editors.

Potential next steps:

  1. We can begin by adding the talk link to the bottom of the page, which would alleviate the concern for creating confusion for readers above. This implementation would still carry some risk for revert rates, however, so we should be ready to report on reverts to talk page edits before and after the change. In terms of timeline, if no new instrumentation is required, we can make the first change within two weeks of agreeing on the success criteria.
  2. If the revert rates from the first change are within a reasonable range (TBD), continue with identifying potential user testing scenarios for readers. Due to other commitments, the timeline for this would be within the next 4-5 months.

How does all this sound?

Bad, actually. The community gave you some very clear instructions. Success criterion: mobile anons are treated the same as every other editor. Anyone is free to study revert rates as that is public information. Studying how long people hang around on talk pages etc you should discuss with Legal (particularly to be GDPR compliant), that's not really any of our business and the community shouldn't have to wait for it.

If the data at some point would reveal that this was a Bad Thing™, you are free to create a proposal on https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals) to change things.

@ovasileva: Sorry to have almost anticipated the deployment, but could you let me know when you deploy this modification of the Minerva skin in the mobile version? So I (Not necessarily me, you can also do if you wish) prepare the deployment in Gerrit, 732705: Enable talk for mobile users on enwiki | https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/732705.

@Jdforrester-WMF please remove your -1 from https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/732705/ or change it into a +1. Developers shouldn't stand in the way of deploying a change the community has voted for because of their personal opinion.

@ovasileva: Sorry to have almost anticipated the deployment, but could you let me know when you deploy this modification of the Minerva skin in the mobile version? So I (Not necessarily me, you can also do if you wish) prepare the deployment in Gerrit, 732705: Enable talk for mobile users on enwiki | https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/732705.

Anyone who has the required system rights to approve that patch is encouraged to approve it, right away. Do not wait for Olga. Don't make this a repeat of developers illegitimately blocking ptwiki consensus to disable IP-editing.

Edit: Olga promised on enwiki to get back to this in the next two days and what she said seems to suggest the team may respect the community consensus, but we'll have to wait for the follow-up to know for sure. I'm carefully optimistic, so let's wait for the follow-up.

Perhaps that's exactly the problem: developers have a different platform (Phabricator), a different etiquette (as you linked) which tends to alienate the rare vocal Wikimedian who wants to open a communication channel with developers, politics aren't allowed here and developers don't read on-wiki discussions. When they do read them (as we know at least two were aware of this issue) they don't reliably relay that information to the rest of the team, resulting in the team being blindsided by community consensus. So this won't be the last time community and developers clash. Surely this is off-topic as well, but ignoring issues doesn't make them go away and there is no public place that I know of to raise this.

@Jdforrester-WMF please remove your -1 from https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/732705/ or change it into a +1. Developers shouldn't stand in the way of deploying a change the community has voted for because of their personal opinion.

@ovasileva: Sorry to have almost anticipated the deployment, but could you let me know when you deploy this modification of the Minerva skin in the mobile version? So I (Not necessarily me, you can also do if you wish) prepare the deployment in Gerrit, 732705: Enable talk for mobile users on enwiki | https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/732705.

Anyone who has the required system rights to approve that patch is encouraged to approve it, right away. Do not wait for Olga. Don't make this a repeat of developers illegitimately blocking ptwiki consensus to disable IP-editing.

I will deploy this Gerrit tomorrow to activate this requested function. Anyone opposed to the decision?

@Juan90264 -- thank you for following closely on this issue and helping this change along. I just wanted to let you know that tomorrow morning, we from the WMF side are going to post on Village Pump a little more of a structured plan to activate this change over the next two weeks, including metrics that we're going to keep an eye on to quickly see if it has any adverse impacts. The reason we want to be careful is because although the code change is simple, we anticipate that this change will be seen on over 100 million page views per day, which means it is very high visibility. That means it may lead to an unpredictable amount of vandalism to talk pages, which we want to make sure we can watch closely. We also think that since the change is high impact, it might be better to activate it at the beginning of a workweek so that there are backport options immediately in the following days, as opposed to near the end of a week, when we have fewer opportunities to make any fixes.

@Juan90264 -- thank you for following closely on this issue and helping this change along. I just wanted to let you know that tomorrow morning, we from the WMF side are going to post on Village Pump a little more of a structured plan to activate this change over the next two weeks, including metrics that we're going to keep an eye on to quickly see if it has any adverse impacts. The reason we want to be careful is because although the code change is simple, we anticipate that this change will be seen on over 100 million page views per day, which means it is very high visibility. That means it may lead to an unpredictable amount of vandalism to talk pages, which we want to make sure we can watch closely. We also think that since the change is high impact, it might be better to activate it at the beginning of a workweek so that there are backport options immediately in the following days, as opposed to near the end of a week, when we have fewer opportunities to make any fixes.

Okay, I understand the visibility, and I would like to know what would be possibly the best date to activate this change, between the next two weeks as said.

Left a note in VPP as well, our current timeline is to deploy this within the next two weeks

Left a note in VPP as well, our current timeline is to deploy this within the next two weeks

Ok, I will activate this change on November 8th (Monday), 23:00 UTC.

ovasileva raised the priority of this task from Medium to High.Nov 1 2021, 10:52 AM

Left a note in VPP as well, our current timeline is to deploy this within the next two weeks

Ok, I will activate this change on November 8th (Monday), 23:00 UTC.

I will be working on the expedited instrumentation portion this week. My understanding is we need 2 weeks - 1 week to build, and 1 week to gather some baseline data, so November 8th would not give us that.

I would therefore suggest either Thursday 11th AM at earliest (although risky as only one deploy after that) or more comfortably 15th November (monday).

Left a note in VPP as well, our current timeline is to deploy this within the next two weeks

Ok, I will activate this change on November 8th (Monday), 23:00 UTC.

I will be working on the expedited instrumentation portion this week. My understanding is we need 2 weeks - 1 week to build, and 1 week to gather some baseline data, so November 8th would not give us that.

I would therefore suggest either Thursday 11th AM at earliest (although risky as only one deploy after that) or more comfortably 15th November (monday).

Thank you for telling me how much time you will need for this, I will do it on the most comfortable day November 15th at 18:00 UTC, which is also more comfortable for me as a holiday in my country (Brazil), so I will be available.

Note to deployer: wmf8 hasn't rolled out yet. Ideally, this change should go out with wmf8.

If we want this to go out with wmf7, since the train was cancelled this week, we should look to backport https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/738487 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/738399 to make sure we are capturing bounce rate on talk pages.

Without those changes, we lose an opportunity to gather some useful data.

Note to deployer: wmf8 hasn't rolled out yet. Ideally, this change should go out with wmf8.

If we want this to go out with wmf7, since the train was cancelled this week, we should look to backport https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/738487 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/738399 to make sure we are capturing bounce rate on talk pages.

Without those changes, we lose an opportunity to gather some useful data.

Discussed in standup today. We will backport these later today during the evening window, but they are not blockers for the deployment of the tabs. @Juan90264 - feel free to continue with the deployment later today.

Note to deployer: wmf8 hasn't rolled out yet. Ideally, this change should go out with wmf8.

If we want this to go out with wmf7, since the train was cancelled this week, we should look to backport https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/738487 and https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaEvents/+/738399 to make sure we are capturing bounce rate on talk pages.

Without those changes, we lose an opportunity to gather some useful data.

Discussed in standup today. We will backport these later today during the evening window, but they are not blockers for the deployment of the tabs. @Juan90264 - feel free to continue with the deployment later today.

Okay.

Change 732705 merged by jenkins-bot:

[operations/mediawiki-config@master] Enable talk for mobile users on enwiki

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

Mentioned in SAL (#wikimedia-operations) [2021-11-15T19:37:18Z] <urbanecm@deploy1002> Synchronized wmf-config/InitialiseSettings.php: 898ebb1e8400a759ffc5553794f6a7200c97bf49: Enable talk for mobile users on enwiki (T293946) (duration: 00m 57s)

All done here, resolving. Work on instrumentation and analysis will continue under T294503: [EPIC] Measuring the impact of exposing talk pages to mobile web anons