The English Wikipedia is one of the wikis whose VisualEditor/Feedback page didn't get centralized in 2016 (see T92661#1937634 ). Per User:Iridescent and casual inspection, local volunteers no longer seem to be watching the page closely. Therefore, it's probably better to have those reports sent directly to MediaWiki.org.
Description
Details
Related Objects
- Mentioned In
- T371738: Write a script to automatically migrate Flow boards to sub-pages
- Mentioned Here
- T227161: Add support for change tags to MessagePoster
T123522: Implement a server-side mw.MessagePoster equivalent
T148611: Plan to disable Flow on Enwiki
T92661: Plan to redirect inactive VisualEditor feedback pages for some wikis to mediawiki.org
Event Timeline
Change 517924 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[operations/mediawiki-config@master] Centralize enwiki's VisualEditor feedback page
Scheduled for tomorrow: https://wikitech.wikimedia.org/wiki/Deployments#deploycal-item-20190620T1800
Change 517924 merged by jenkins-bot:
[operations/mediawiki-config@master] Centralize enwiki's VisualEditor feedback page
Mentioned in SAL (#wikimedia-operations) [2019-06-20T18:15:10Z] <tgr@deploy1001> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:517924|Centralize enwikis VisualEditor feedback page (T224851)]] (duration: 00m 57s)
Change 518117 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[operations/mediawiki-config@master] Revert "Centralize enwiki's VisualEditor feedback page"
Change 518117 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "Centralize enwiki's VisualEditor feedback page"
Mentioned in SAL (#wikimedia-operations) [2019-06-20T20:23:18Z] <jforrester@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Revert Centralize enwiki's VisualEditor feedback page T224851 (duration: 00m 59s)
Sorry about the mess, I didn't realize that.
One possible solution would be T123522: Implement a server-side mw.MessagePoster equivalent. Another would be to somehow load the required MessagePoster JS code from the target wiki. Either would take some development effort.
Roan (and Growth team in general) recently worked on the MessagePoster code for T227161: Add support for change tags to MessagePoster, but I'm not sure if we can convince them to work on this problem. (I wouldn't mind if you wanted to take it off us though ;) )
@ppelberg asked for a time estimate, so I spent and hour or two looking into it:
It wouldn't be particularly tricky, but it would be a lot of code to write (or port).
There are patches on T123522 from 2017 where Matt has already done a lot of the work (probably the trickiest parts – talking to core MW and to Flow to make them post things), but it would need some updating, and an API module and a client-side RL module to communicate with it are still missing.
I'd estimate this to be about 1-2 weeks of work (and probably at least a month in real time, since I think many people from different teams would like to review it).
Another would be to somehow load the required MessagePoster JS code from the target wiki.
Writing a proof of concept turned out to be easy: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/524056
But I took a few big shortcuts. We'd have to make the API output additional information about modules and how to load them (currently this is only known internally in RL), and we'd have to coordinate with someone (Core Platform team? Performance team?) about using some ResouceLoader methods that are currently supposed to be private/internal. Also, Security team would probably like to hear about loading code from other wikis (even though it already happens a lot in gadgets/user-scripts, I don't think we've done it before in our code).
I'd also estimate this to be about 1-2 weeks of work, but it seems like the kind of thing that can get stuck forever since various stakeholders are likely to have differing opinions :)
During the Editing-team planning meeting it was determined we are not going to prioritize this due to the amount of time it will take and our current scope of work.
I think the simplest way to solve this problem is to reverse the "uninstall" part of T148611: Plan to disable Flow on Enwiki.
So, ... this depends on the user's current wiki having Flow extension loaded so that it can post to Structured Discussions on mw-wiki?
I think I'm going to need a "Bex and a good lie down".
Could a config switch be added to VE that says the "leave feedback about this software" item just opens a URL in a new tab, rather than presenting the feedback UI? Or a switch to hide "leave feedback" if feedback isn't being monitored on a site?
Change #1101158 had a related patch set uploaded (by Pppery; author: Pppery):
[operations/mediawiki-config@master] Update VisualEditor config to drop exclusions based on Flow
Change #1101158 merged by jenkins-bot:
[operations/mediawiki-config@master] Update VisualEditor config to drop exclusions based on Flow
Mentioned in SAL (#wikimedia-operations) [2024-12-16T21:11:16Z] <cjming@deploy2002> Started scap sync-world: Backport for [[gerrit:1101158|Update VisualEditor config to drop exclusions based on Flow (T224851)]]
Mentioned in SAL (#wikimedia-operations) [2024-12-16T21:15:40Z] <cjming@deploy2002> cjming, pppery: Backport for [[gerrit:1101158|Update VisualEditor config to drop exclusions based on Flow (T224851)]] synced to the testservers (https://wikitech.wikimedia.org/wiki/Mwdebug)
Mentioned in SAL (#wikimedia-operations) [2024-12-16T21:23:12Z] <cjming@deploy2002> Finished scap sync-world: Backport for [[gerrit:1101158|Update VisualEditor config to drop exclusions based on Flow (T224851)]] (duration: 11m 56s)