Page MenuHomePhabricator

Please centralize enwiki's feedback for VisualEditor
Open, Needs TriagePublic

Description

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.

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

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

Change 517924 merged by jenkins-bot:
[operations/mediawiki-config@master] Centralize enwiki's VisualEditor feedback page

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

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"

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

This won't work, because the StructuredDiscussions code has been removed from enwiki (even though it's meant to be live on all prod wikis).

Instead of working, it errors with "Feedback report failed because MessagePoster could not be fetched". See the config for dewikivoyage etc.

Obviously we can re-enable the extension on enwiki, but I imagine that might confuse some people.

Change 518117 merged by jenkins-bot:
[operations/mediawiki-config@master] Revert "Centralize enwiki's VisualEditor feedback page"

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

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, this is impossible without reversing T148611.

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.

It sounds like we should be talking to @Catrope about this.

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 :)

JTannerWMF added a subscriber: JTannerWMF.

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.

matmarex added a subscriber: matmarex.

I think the simplest way to solve this problem is to reverse the "uninstall" part of T148611: Plan to disable Flow on Enwiki.

I think the simplest way to solve this problem is to reverse the "uninstall" part of T148611: Plan to disable Flow on Enwiki.

That seems like a terrible idea.

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?