Is this intentionally tagged Collaboration-Team-Backlog (because of VE in Flow?)?

In T129322#2103984, @Mattflaschen wrote:

Is this intentionally tagged Collaboration-Team-Backlog (because of VE in Flow?)?

Untagged because it seems unrelated, happy for it to be retagged if someone presents a good reason for it to be.

..there are different ways how to move forward with this, I added them below. Some are possible, some may sound spammy. It all depends on how want this to be used, and in any case, we can always start with something and change it if needed:

1. Just add it to the sidebar and announce it so that editors start using it
2. Instead of the sidebar, do we want this to be part of the editing interface because we want to draw editors attention to realizing the impact editing style has on performance?
3. We even want to add more emphasis on the importance of page performance, so, when an issue needs to be flagged, page contributors can receive notifications with options on how to act accordingly to optimize it. @Mattflaschen @Catrope hence the collaboration team tag, as FYI if you think this needs to be discussed.

In T117411#1773274, @Aklapper wrote:

Where is the current documentation that editors could find (if there is any)?
Would e.g. https://wikitech.wikimedia.org/wiki/Debugging_in_production#Showing_profiling_data_for_MediaWiki_requests be related?

Re: ^ ... @Peter @Moushira :

• Is this tool explained anywhere apart from the description of T117411? (I found https://www.mediawiki.org/wiki/Extension:PerformanceInspector but it's almost empty)
• Is there any place where non-developers (i.e. without wrangling a local MediaWiki installation!) can test it out, right now?
• How often do you expect editors/readers to utilize this tool, and report feedback based on it? (e.g. Will some editors be likely to use it daily? Will most editors be likely to use it once a year?) If you expect infrequent usage, or low quantity of total editors, then I'd advise against using the mediawiki:sidebar - that's too prominent, and we have to work hard to prevent it growing with everyone's favourite tool(s)!
• Do you expect it to be used at all wikis, or just a few?

Options:

• One option, might be to add it to local equivalents of https://en.wikipedia.org/wiki/MediaWiki:Pageinfo-footer which is shown at the bottom of the "Page information" link (in the sidebar). e.g. https://en.wikipedia.org/w/index.php?title=MediaWiki:Pageinfo-footer&action=info itself, or https://en.wikipedia.org/w/index.php?title=Romanian_literature&action=info (which shows how much further down the section is, on articles that have a significant number of template calls)
  • Or! Add a new row to the data tables in the pageinfo - much like http://bf-wmpageview.wmflabs.org/wiki/Taylor_Swift?action=info does (Click the 888,276 once it transforms into a link) See details and related tasks in https://phabricator.wikimedia.org/T40450 )
• The description of T117411 mentions "We could push the code for this either by: load it on demand when the user wants it, or package it as bookmarklet, or make a browser plugin." - these all sound a lot less prominent than a sidebar link.

I'm concerned this is too technical for readers and probably the majority of editors. I would suggest only showing this when debug=true
or linked to inside action=info

The interface link will probably be hidden by default via a user preference. This task is more about how that link would look and where it would be.

Adding it to action=info itself wouldn't an option. We need a place that is visible at all times so that one can invoke it in the context of the current page and state (search results, log in page, edit page, specific articles, etc.).

In T129322#2128139, @Krinkle wrote:

The interface link will probably be hidden by default via a user preference. This task is more about how that link would look and where it would be.

Adding it to action=info itself wouldn't an option. We need a place that is visible at all times so that one can invoke it in the context of the current page and state (search results, log in page, edit page, specific articles, etc.).

No such place exists in mobile unless you have a permanent fixed position icon somewhere in the UI (search and edit overlays the entire page full screen)

@Quiddity:

Is this tool explained anywhere apart from the description of T117411? (I found https://www.mediawiki.org/wiki/Extension:PerformanceInspector but it's almost empty)

No but I've updated T117411 to reflect better what it will be. Now when things are started to work I'll update
https://www.mediawiki.org/wiki/Extension:PerformanceInspector

Is there any place where non-developers (i.e. without wrangling a local MediaWiki installation!) can test it out, right now?

No. It's still in development. I'm making sure the structure is ok and then we can add more metrics/make it more useful.

How often do you expect editors/readers to utilize this tool, and report feedback based on it? (e.g. Will some editors be likely to use it daily? Will most editors be likely to use it once a year?) If you expect infrequent usage, or low quantity of total editors, then I'd advise against using the mediawiki:sidebar - that's too prominent, and we have to work hard to prevent it growing with everyone's favourite tool(s)!

I'm not the right person to answer that since I will use it all the time :)

Do you expect it to be used at all wikis, or just a few?

I hope on all. I think (and hope) that in countries where the connection speed is a limit, the tool will be even more useful.

@Jdlrobson lets see if we can find a place for it, the tool isn't ready for mobile yet but I think it have the possibility to give great value.

FYI: I've kept it in the tools section for now.

The NewPP report is disabled since one month (T110763).
This new tool is not yet available.

In the mean time, is there a way to get the information that was in the New PP report in some way (eg javascript) ?
The information I'm interested in is template expanded size and lua time.

If this is not the place for such a question please tell me where I should ask next time I have such question.

@Zebulon84 you can still see the newpp report in if you do View source for a page. The output format has changed from HTML comments to JSON (so it's machine readable). If you scroll down to the bottom of the page, you should be able to see it (the Performance inspector uses JSON).

Asking on Phabricator is perfect, if you cannot find a task that match, you can create a new task the next time.

In a script tag, found it, thanks.
It's less visible in the inspector view I was using, but easy to find in unfolded source, and easy to use with JS, variable called wgPageParseReport
great. :)

For desktop, the current placement (inside the tools section of the navbar) is fine if it's shown only on opt-in, though we may want to find a shorter label to pick. "Page speed" maybe?

For mobile, could we insert it into the menu (again, if the account has opted-in)? This would make it available on every page but out of the way except for experts.

Thanks, I'll fix that then. We'll not push it on mobile for now, just start on desktop.

Page Speed for me is Google way of talking about performance (Google Page Speed Insights) but if we feel that makes it cleaner that's good, I'll just talk to Ori and the rest of the team.

In T129322#2644359, @Jdforrester-WMF wrote:

For desktop, the current placement (inside the tools section of the navbar) is fine if it's shown only on opt-in

It seems like you are also saying that it is not fine for it to be shown by default to all users. Is that correct? If so, why not? Can you think of alternatives?

This has been addressed in multiple comments in this and other tasks. TL;DR the sidebar is enough cluttered as it is. The number of people who would be using such a tool would be extremely low and certainly not enough to "deserve" a new link. But if you make it opt-in, as recommended, then such a link would be fine, although it'd be good to see the other proposals addressed.

This definitely should not be always present for everyone. And I don't think that it's important that this tool is available to logged-out users either. The target audience is really:

• MediaWiki developers (staff or community) who are trying to understand the resource load of a particular page
• Community members who are trying to understand what resource demands are causing an article, or a wiki, to be slow
• Those who support community members, who have a way to request significant information about a user's experience of a wiki that isn't otherwise available.

Having this functionality be opt-in (as currently implemented by having it be a Beta Feature) seems like the correct thing going forward, as that does seem to address clutter and other potential issues with minimal fuss. From a community perspective, is there any real reason to graduate something like this from beta? I'm thinking of something like GMail, where some Labs features have been in that state for years and years. This seems like a good candidate for the same sort of treatment, until/unless a more appropriate preference option is found.

The bookmarklet/browser plugin options have the downside of adding maintenance that's not necessary with the beta feature approach; and the fact that the user has to leave the on-wiki workflow in order to access the new feature. For the circumstances where this is a helpful tool, being able to quickly enable, use, and (if desired) disable is preferred.

So, in short: an implementation that is opt-in only, and that has the possibility of being short-lived, is the most desired outcome.

In T129322#3956774, @Imarlier wrote:

From a community perspective, is there any real reason to graduate something like this from beta?

Beta Features are meant to be temporary trials, pulled after (at most) six months of no significant development. They're not meant as a long-term option; they are way too high-profile to put there. Just sling it into the Editing section as a normal preference and be done with it?

In T129322#3956951, @Jdforrester-WMF wrote:

In T129322#3956774, @Imarlier wrote:

From a community perspective, is there any real reason to graduate something like this from beta?

Beta Features are meant to be temporary trials, pulled after (at most) six months of no significant development. They're not meant as a long-term option; they are way too high-profile to put there. Just sling it into the Editing section as a normal preference and be done with it?

If that works for you, it works for me. Editing does seem like the right place for it, since I can't really foresee a situation where someone who didn't look at that pref pane would be using this functionality. @Quiddity thoughts?

+1 to placing it in the Editing preferences. Specifically, I think there are three options:

1. Add it at the bottom in a new section (perhaps titled "Developer tools" or "Technical tools" or similar) by itself
2. Add it in the existing top section "General options", above or underneath the existing item "Enable parser migration tool"
3. Create a new section at the bottom, add this new preference there, and also move the "Enable parser migration tool" preference down to there.

3 would be ideal (imo) but is slightly (?) more complicated.

Awesome, that seems very reasonable -- thanks both!

Change 428568 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/core@master] Add "developer tools" preferences section

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

Change 428570 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/extensions/ParserMigration@master] Move to new "developer tools" preferences section

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

Change 428606 had a related patch set uploaded (by Gilles; owner: Gilles):
[mediawiki/extensions/PerformanceInspector@master] Move option to enable/disable extension to Preferences page

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

Change 428568 merged by jenkins-bot:
[mediawiki/core@master] Add "developer tools" preferences section

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

Change 428570 merged by jenkins-bot:
[mediawiki/extensions/ParserMigration@master] Move to new "developer tools" preferences section

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

Change 428606 merged by jenkins-bot:
[mediawiki/extensions/PerformanceInspector@master] Move option to enable/disable extension to Preferences page

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