Page MenuHomePhabricator

Communicate transition of Graph/Graphoid to client-side only JavaScript feature
Open, LowPublic

Description

What is the goal?

Ensure community members who have contributed graph UGC are aware that Graph/Graphoid is transitioning to a client-side only JavaScript feature and some functionality will be reduced, in order to reduce maintenance cost. We would like to ensure community members are aware that syntactic changes will likely be necessary in wikitext in order to continue function, or at least smooth function, in a number of cases.

How can we help you?

Communication via wikitech-ambassadors and appropriate wiki fora, as well as some targeted user outreach.

What does success look like?

Users are notified. Ideally one or two community members volunteer to assist with the transition of wikitext assets to work with Graph coincident with the software engineering contractor's work to transition the codebase.

What is your deadline?

There are several milestones. Note that we anticipate the contractor's contract to be 6-9 weeks in length.

  1. Getting early advance notice out in the next couple of weeks would be ideal.
  2. An interim notice to the community on the date the contractor will begin work (sourcing is still in flight, but it's likely 3-6 weeks before the start date at the time of this Phabricator support request) and where to go to follow along.
  3. Advance notice about first target wikis cutover date (probably 3-4 weeks after contractor starts).
  4. Advance notice for all wikis cutover date (probably 5-8 weeks after contractor starts).

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 30 2019, 11:21 AM

@MarkTraceur I filed this request - you should probably be the one to manage the request given you'll be project managing the contractor, but let's discuss. Feel free to edit the request, as I may be not thinking holistically enough...or I may be thinking too holistically!

dr0ptp4kt updated the task description. (Show Details)Oct 30 2019, 11:23 AM
dr0ptp4kt updated the task description. (Show Details)
Elitre triaged this task as Medium priority.EditedOct 30 2019, 11:38 AM

Triaging, and waiting for Mark's reply as well. before assigning Thanks for filing!

In no particular order:

  • Hiring is ongoing, but we're close. Start date looks like it's still a few weeks out, however.
  • Based on advice we've gotten so far, I don't believe syntactic changes will be required. In theory, the system will Just Work™. If changes are needed, we don't know what they are yet, but I'd expect that to be part of the report as work is closed and before deployment occurs.
  • If we want to roll this out to particular wikis piecemeal, I'd love some help figuring out which ones should go first. I believe I've heard there are counts for graph usage per-wiki floating around somewhere, which may help.
Elitre assigned this task to Keegan.Nov 26 2019, 11:35 AM
Keegan added a comment.EditedDec 6 2019, 8:09 PM
  • If we want to roll this out to particular wikis piecemeal, I'd love some help figuring out which ones should go first. I believe I've heard there are counts for graph usage per-wiki floating around somewhere, which may help.

Link: https://phabricator.wikimedia.org/T211881#4878324

There's some more good data tidbits in there. I'll look more into ordering release next week.

Most of this work will be scoped to broadcasting the change once we've determined impact and rollout.

I think we'll need someone with better analytics skills than I have to help look at this, but I've been going over the data in the task link above. As stated there, only about 10 wikis are using most of the graphoid service. The largest that will be impacted, enwiki, is interesting. During the two-week measured frame it got the most hits for graphoid at over 21k requests. However, as @dr0ptp4kt found in T211881#5065149...

There's a grand total of 182 pages bearing <graph> in the source according to that primitive search query (that includes a low level of non-executing documentation).
113 are in User namespace. 39 of those invocations are in Article namespace. 8 are in Wikipedia namespace. 5 of them are in Template namespace; 4 of those 5 templates have just one article associated with them bearing the <graph> tag. The other 17 other usages of the tag are scattered about.

The most important offender likely being https://en.wikipedia.org/wiki/Template:Graph:Street_map_with_marks, which is used in nearly 1.2k articles.

I imagine the situation is like this for the other ten wikis. It'd be very helpful in messaging to know if indeed there are a few templates that are widely propagating <graph>, and if they can be updated or otherwise alerted to this change. It'd be helpful to be more targeted here in the communications so as to not avoid an unnecessary panic when the impact might be small.

@Keegan this task would welcome an update. TY!

Once a contractor is hired and onboarded to the project, we'll start the outreach to the few places actively using this tag. Still very much a WIP.

Elitre changed the task status from Open to Stalled.Jan 21 2020, 6:31 PM
Elitre lowered the priority of this task from Medium to Low.

I think we'll need someone with better analytics skills than I have to help look at this, but I've been going over the data in the task link above. As stated there, only about 10 wikis are using most of the graphoid service. The largest that will be impacted, enwiki, is interesting. During the two-week measured frame it got the most hits for graphoid at over 21k requests. However, as @dr0ptp4kt found in T211881#5065149...

There's a grand total of 182 pages bearing <graph> in the source according to that primitive search query (that includes a low level of non-executing documentation).
113 are in User namespace. 39 of those invocations are in Article namespace. 8 are in Wikipedia namespace. 5 of them are in Template namespace; 4 of those 5 templates have just one article associated with them bearing the <graph> tag. The other 17 other usages of the tag are scattered about.

The most important offender likely being https://en.wikipedia.org/wiki/Template:Graph:Street_map_with_marks, which is used in nearly 1.2k articles.

I imagine the situation is like this for the other ten wikis. It'd be very helpful in messaging to know if indeed there are a few templates that are widely propagating <graph>, and if they can be updated or otherwise alerted to this change. It'd be helpful to be more targeted here in the communications so as to not avoid an unnecessary panic when the impact might be small.

In case its useful, For an entirely different purpose, I did a (mostly superficial) analysis of how the graph extension is used on en wikipedia at https://www.mediawiki.org/wiki/User:Bawolff/Reflections_on_graphs#How_is_the_Graphs_extension_used_currently

Moving to CommRel-Specialists-Support (Apr-Jun-2020), assuming this is not done yet.

I've emailed tech ambassadors and made a first post at https://en.wikipedia.org/wiki/Template_talk:Graph:Chart

Keegan changed the task status from Stalled to Open.May 11 2020, 8:38 PM

More outreach is in the works, including Tech News.

I’m not sure what “client-side only JavaScript feature” means. Is it that JavaScript will load for all graphs (in contrast to the current situation where it’s loaded only on-demand and not loaded for simple graphs at all)? Or is it that graphs will be rendered only on client side, without any server-side (PNG) fallback? Latter case would mean that Grade C browsers (and other browsers incapable of executing JavaScript, e.g. users with unreliable internet connection or users with NoScript) wouldn’t get any graphs, which is against the promise set out on the compatibility page (see link) that “content is presented in a readable manner”. I really hope this won’t happen.

dr0ptp4kt added a comment.EditedMay 13 2020, 10:08 PM

@Tacsipacsi, that's correct, it would be rendered only on the clients with sufficient JavaScript support. It's not ideal, but it's a compromise to avoid graphs being disabled altogether. Archiving of the PNGs to the File: namespace is one possible way to cut over content meantime where that's preferred over the client rendered approach.

I think even disabling graphs for all would still be a better solution than disabling them only for some. Imagine that the article says “the change over the years is shown on the below graph:”—and there’s no graph. There is a clear promise on https://www.mediawiki.org/wiki/Compatibility that the content will be presented for Grade C browsers in a readable manner; this must be followed by all WMF software.

Johan added a subscriber: Johan.May 14 2020, 12:41 PM

This has been added to Tech/News/2020/21.

I think even disabling graphs for all would still be a better solution than disabling them only for some. Imagine that the article says “the change over the years is shown on the below graph:”—and there’s no graph. There is a clear promise on https://www.mediawiki.org/wiki/Compatibility that the content will be presented for Grade C browsers in a readable manner; this must be followed by all WMF software.

This feature is a Javascript feature to begin with, whether rendered on the server or in the browser, so compatibility as outlined is not applicable here.

However, the underlying point is understood, and there's active discussion about in T249419 about how to replace the service. Please consider this change to be but one piece of the work to re-do graphs and make them more robust, while at the same time deprecating parts of the architecture that are holding up progress.

AlexisJazz added a subscriber: AlexisJazz.EditedMay 17 2020, 7:38 PM

I've just translated this for Tech news and I'm confused about what this even means. To users with even less knowledge, this sounds like you're about to break loads of stuff and boil the CPUs in everyone's phones and tablets.

Users who don't understand all the tech may think that every graph, even static SVG files, will now require JS. Sure, I understand that won't be the case, but Tech news isn't read by just me. And even I don't understand exactly what is covered by this, why this has to happen and how badly my phone will overheat because of it.

Pelagic added a subscriber: Pelagic.Jun 2 2020, 6:21 PM

Agree with AlexisJazz, about need for more explanation. How is client-side JS more maintainable than server-side?

A graphing feature seems that it would be very useful, but I’d never heard of it. Wondering why usage is so low.

Keegan added a comment.Jun 2 2020, 6:35 PM

Agree with AlexisJazz, about need for more explanation. How is client-side JS more maintainable than server-side?

Client-side rendering is handled through the browser, and for an individual the cost is very, very low because you're only rending for yourself; CPU usage is a fraction of a percent, there's straight up no danger to individuals.

Scale this up to having the server handling all the requests all the time, and it's the central rendering place that's in danger falling over. It's reached an unsustainable point.