@JKatzWMF: can I get your opinion on rollout strategy? Does this need a staggered rollout, or can/should it be a "do it everywhere on date" thing?

@greg I believe a staggered rollout is preferable (as this will have an unknown impact on edits), but defer to others as I am honestly 95% unfamiliar with the ask. @Nemo_bis Is this merely a settings change? Who is doing the work for this? What are the metrics for success?

1. Do we want a user who clicks edit to go directly to an edit page? Or do we want to use the new feature as an opportunity to educate/introduce more people to editing WP? It is possible that investing in this step is more valuable than investing in counter-vandalism.
2. As a starter, and as we test, can we align anon edit with WP Zero to allow a full functionality for free, and to start with relatively smaller Wikipedias like: Arabic, Urdu, Malay, Bengali..etc.
3. Talk pages will help with controversial discussion, what else could help?

Thanks :-)

The problem in activating anonymous editing is, like Jon said on mobile-l[1], that the config var is cache related (it is actually stored in the html output, generated by SkinMinerva.php through OutputPage::addJsConfigVars() [2]). To avoid the same problems like on itwiki (See T74855: Purge is required to edit some page as unregistered user and T74856: Purge cache for all it.m.wikipedia.org pages) it would (in the actually state) be needed to purge page caches on all wikis, where this settings changes (in fact all wikis except itwiki), which is fairly a bad idea.

A solution could be to load wgMFEditorOptions via RL (e.g. through ResourceLoaderGetConfigVars hook [3]), for which, iirc, the cache-time is very short (15 minutes, see T91372#1081364)?

[1] https://lists.wikimedia.org/pipermail/mobile-l/2015-March/008809.html
[2] https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/includes/skins/SkinMinerva.php#L837
[3] https://www.mediawiki.org/wiki/Manual:Hooks/ResourceLoaderGetConfigVars

It's not just config changes it is probably php/js changes too.

In terms of my time you'll have to okay that with @JKatzWMF first as I need to get Gather in a MVP deployable state first.

I fear 30th may be far too soon (see my reply to Nemo's email on wikitech). I'd rather we did this carefully and properly then rush it and mess up.

In T93210#1137696, @Jdlrobson wrote:

It's not just config changes it is probably php/js changes too.

In terms of my time you'll have to okay that with @JKatzWMF first as I need to get Gather in a MVP deployable state first.

Official request placed, @JKatzWMF :)

I fear 30th may be far too soon (see my reply to Nemo's email on wikitech). I'd rather we did this carefully and properly then rush it and mess up.

Noted. I placed this in the "April-June" column on the roadmap given that.

In T93210#1137697, @Jdlrobson wrote:

I don't want to give the false impression I'm doing this yet. I'm super swamped with work right now.

Noted and agree :)

Thanks @greg April - June seems much more realistic.

Also I echo @Moushira particularly 1. Would be great if @Jaredzimmerman could have a quick glance at how its working on Italian Wikipedia and suggest cheap ways to improve it if any.

Mmm.. Also looks buggy just tried to get past through the first screen on Italian Wikipedia and couldn't do it on my nexus 5 (maybe a bug?)

Would be good to add some browser tests to this before putting in production.

Change 198691 had a related patch set uploaded (by Nemo bis):
Restore unregistered editing on mobile sites (staggered)

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

Added the gerrit link to https://wikitech.wikimedia.org/w/index.php?title=Deployments&diff=prev&oldid=149551 . This is only a site request; if you have suggestions or reports which involves code changes, please post them on separate tasks so that we have a clear overview.

In T93210#1139964, @Nemo_bis wrote:

As we want a staggered release, there might be no urgent need of a cache purge. T91372, as currently described, can be addressed later and is not a blocker.

I don't know, how this would solve our problem? I thought we don't want to purge page caches on any wikipedia version, which would be needed at the moment. Background: The config var, which controls, if unregistered users can edit or not, is delivered as a skin config var, which will be in the page html output (directly in the head of a page's source). And as far as i know, html pages are cached for unregistered users 30 days (?), which would result in the same problem like on itwiki:

Some pages (which are edited and rerendered) are already editable by unregistered users, and others are not (maybe because they aren't edited so often). Because of this we had to purge _all_ page caches on itwiki to enable anonymous editing.

To be clear: I want to resolve this task as soon as possible, too, but i must agree with Jon: It would be terrible to have the same problems on enwiki (or dewiki or any other wmf-wiki) like we had on itwiki. So i would welcome it, if we are totally sure, that we don't need to change anything (or purge caches or something else) before we merge the config change :)

So, open questions for me (maybe they are already answered and i haven't read it, than : sorry :():

• Are JS Skin Config variables (added through OutputPage::addJsConfigVars()) cached? (They life in html source, so i think: yes)
  • How long they are cached?
  • Would it help to move the config var to a Resourceloader hook (which are, iirc, cached for 15 minutes only)?

I'm pretty sure if the option is moved to the RL startup module (using the Resourceloader hook the cache can be cleared in 5 mins) Basically we want to do what VE is doing since I guess they have the same problem. This would roll it out to all users in 5 minute window and allow us to disable it for all users within a 5 minute window,

So I think although we want a staggered release we want the ability to turn off instantly? It may be better to release it to projects one at a time on a daily basis, starting with the smaller ones. Would that work?

Change 199227 had a related patch set uploaded (by Florianschmidtwelzow):
Move wgMFEditorOptions to ResourceLoaderGetConfigVars hook

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

Change 199227 merged by jenkins-bot:
Move wgMFEditorOptions to ResourceLoaderGetConfigVars hook

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

Please exclude kowiki; Per the consensus here (It is support for Prohibiting them)

In T93210#1160189, @revi wrote:

Please exclude kowiki; Per the consensus here (It is support for Prohibiting them)

Please file a separate report, so that it can be correctly referenced in the configuration.

Missed one question:

So i would welcome it, if we are totally sure, that we don't need to change anything (or purge caches or something else) before we merge the config change :)

As far as I know (and of course we can always improve our knowledge), there is no *need* to purge the cache immediately. it.wiki wanted to get the configuration applied to all pages as soon as possible, hence it asked an immediate purge of the whole cache. Are you aware of a reason which *forces* us to do the purge, or something else? If so, it would be nice to have it filed.

@Nemo_bis: The "problem" (which would require to purge page caches) was resolved with https://gerrit.wikimedia.org/r/199227 (which is part of MediaWiki train release 1.25wmf23). So, technically, there is no need to purge caches, just change the configuration (like every other config change).

In T93210#1161570, @Florian wrote:

@Nemo_bis: The "problem" (which would require to purge page caches) was resolved with https://gerrit.wikimedia.org/r/199227 (which is part of MediaWiki train release 1.25wmf23). So, technically, there is no need to purge caches, just change the configuration (like every other config change).

Thanks! I'll update the commit message of the configuration change.

Change 198691 merged by jenkins-bot:
Restore unregistered editing on mobile sites (staggered)

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

Hi Everyone--I apologize for the delayed response. It took me some time to get up to speed on the ask. The mobile web team is looking forward to deploying this, provided we can assure all implications are well understood and okayed. Anonymous editing is already enabled on test.wikipedia.org and @Moushira is going to be inviting community members to test the current workflow so that we can identify any bugs and workflow issues before deploying it. We also might have to have some internal conversations about the implications of such a move. @Amire80, any ideas around testing this for other languages before deploying elsewhere?

In T93210#1164119, @JKatzWMF wrote:

@Amire80, any ideas around testing this for other languages before deploying elsewhere?

Nothing special. I continuously test RTL, and it works well (I just checked master again).

All the relevant messages are translatable and well-documented, but it never hurts to publish an invitation to complete the translations to their languages:
https://translatewiki.net/w/i.php?title=Special%3AMessageGroupStats&x=D&group=ext-mobilefrontend#sortable:3=desc

AFAIK local admins don't bother to change CSS and JS for mobile sites, but some post-deployment testing on a sample of wikis won't hurt.

Thanks, @Amire80 https://phabricator.wikimedia.org/p/Amire80/!

FYI basic stats https://meta.wikimedia.org/w/index.php?title=File:Editing_department_%E2%80%93_Quarterly_Review_slide_deck,_2014%E2%80%9315_Q4.pdf&page=31