Topic on Talk:Stable interface policy/Frontend

In https://www.mediawiki.org/w/index.php?title=Topic:Xn1201q2fbyyb7wj&action=history Tgr (WMF) raises that our current definition does not taken into account importScript.

Does anyone else have any ideas for improving how we evaluate?

Some off the topic of my head:

• The Gadgets tab on Special:Preferences page could count users in a similar way to Extension:BetaFeatures. This would be also useful for turning off seldom used gadgets.
• We could go by page views (e.g. hits to the .js pages with ctype query string)

en.wp has w:Wikipedia:User scripts/Most imported scripts.

The Gadgets tab does count users (that's Special:GadgetUsage, already mentioned in the policy); what's not counted is loading a user script from your personal common.js via mw.loader.load / importScript / etc. Definition-wise "number of users of the script" is clear, it's just often not very convenient to determine.

Page views would be nice but even more effort, I think - we don't have good patterns for creating tooling that works with private data. The number of users who installed a script could be counted by a toolforge tool (if it's a gadget, check Special:GadgetUsage; it it's a user script, do a global search for common import patterns; repeat the whole thing for all interwikis), someone would just have to write it first.

My concern with counting references to importScript is many of these are pages for inactive users. I think if we took this approach we would need to be more proactive about blanking user script pages for inactive users.

It would be nice to do _something_ about the imported user scripts of inactive/usurped users.

As a general rule, popularity can be judged by 50+ scripts in MediaWiki namespace or more than 1000 scripts across the user and MediaWiki namespace impacted by any given change

Our popularity definition currently only applies to MediaWiki and user namespace.

This came up recently in phab:T182050 although this was for pages using MediaWiki CSS (which is not covered by the stable policy and is using an unstable interface).

A change that impacted 580 pages and 1209 subpages (many translated) in the main namespace was interpreted as "widespread breakage". Do people think this a fair assessment?

I am starting to wonder if it makes sense to require communication for all changes where we know that there's impact (at least for CSS), but that also seems like a lot of overhead on developers.

This has definitely flagged a gray area in the frontend stable policy and how it can be interpreted so I'd like to improve our definition one way or another.