It seems not to be functioning of late, and TBH I don't know why it was enabled to begin with since it wasn't designed for the skin. See also phab:T367646.
Also, responsiveContentBase currently in Browsing for both Vector and Timeless probably should be living in the proximity of responsiveContent. Don't really care if that's in Appearance or Browsing. (Why do we have section names that are almost exactly the same in intent?) Izno (talk) 15:52, 17 June 2024 (UTC)[reply]
@Izno, I just noticed you removed EditNoticesOnMobile (ENOM) 10 days ago: MediaWiki:Gadgets-definition (Diff ~1251928150) Shortly after the native implementation was rolled out there was a question of whether ENOM was still needed. My response was that the native implementation was missing some features, so I didn't think ENOM was obsolete. Assuming the native implementation hasn't been improved since, some shortcomings are: 1. Once dismissed, edit notice can't be read again. (unless the user opens the same page in a private/incognito tab or waits 24 hours) ENOM provides a link on the edit confirmation screen. 2. Will re-show popup every 24 hours no matter what. For ENOM this is 2 weeks or longer. This could result in what I call "notice fatigue" where users may stop reading them. 3. Can't be disabled on a per-page or per-namespace basis (ENOM is disabled in file namespace here IIRC because that notice is more informational than cautionary in nature) 4. Popup is always narrow, no matter how wide your screen is. I'm more neutral on the matter these days, I have enough worries in my personal life so fewer responsibilities is a pro for me, and one gadget less slightly reduces bandwidth and stuff I suppose. Whether or not we should have an RfC for the removal (as the gadget was installed following an RfC), I'm unsure. Ping @Xaosflux who helped massively with the deployment of ENOM. — Alexis Jazz (talk or ping me) 16:13, 28 October 2024 (UTC)[reply]
If the primary functionality is now being supported upstream, that does seem preferable - as there would be active maintainers. Was any usage data gathered prior to decom? — xaosfluxTalk16:38, 28 October 2024 (UTC)[reply]
I think there is room for opinion here without supporting a fork. Some of your suggested shortcomings look more like opinion than not. Some need improvement upstream rather than continuing to maintain a gadget locally that 'forks' the now-native functionality. On the specific points:
That we have any limit here is different than desktop contexts, either WTE or VE. It shouldn't be: we should shoot for uniformity here as best we can and encourage upstream to think about ways this can be improved in both locations. In which case, 24 hours is much closer to the native state of things than is 2 weeks.
I don't think this is necessary in any system. If we have "informational" edit notices, I think those should just go away in toto. :)
@Xaosflux, "usage data" can not be gathered for default gadgets. Theoretically the user experience will have simply changed based on the noted differences between the two. Izno (talk) 16:46, 3 November 2024 (UTC)[reply]
I don't have a strong worry if someone wants to keep this as an OPT-IN alternative gadget, but agree we shouldn't compete with the default anymore. — xaosfluxTalk18:18, 6 November 2024 (UTC)[reply]
We are talking about something invoked on millions of pages here though correct? I'm certainly a fan of not using default loads when we don't need to - but this seems a bit heavy. — xaosfluxTalk21:46, 20 December 2024 (UTC)[reply]
Only unreliable part is the initial population of the category which can take some time due to parser cache. We already use template gadget for WikiMiniAtlas which has a million+ pages and didn't see any issues, due to a 2-stage rollout (adding the template gadget first, then removing the common.js load a month later). The same can be done here. – SD0001 (talk) 18:19, 26 December 2024 (UTC)[reply]
Difference there, that is basically a single-purpose gadget - I suspect this one may continue to be reused for more applications as a general utility. This isn't a hard oppose, more of a caution that we could be setting ourselves up for future problems. — xaosfluxTalk19:35, 26 December 2024 (UTC)[reply]
I don't really see new uses creating a problem either, except that adding the category to a highly-used template would cause the gadget to take a while to propagate to users, which is natural. – SD0001 (talk) 10:58, 4 January 2025 (UTC)[reply]
