Last modified: 2014-11-17 10:35:12 UTC
This seems like a reasonable tracking bug, even though I don't have any bugs to track yet. I imagine a few user preferences in MediaWiki core could be turned into JavaScript gadgets, particularly once global gadgets exist. This bug seeks to track bugs about specific MediaWiki user preferences that could be gadgetized.
Do we have any way to ship gadgets bundled with core? If not, this bug actually means "remove some user preferences altogether". A more useful tracking bug would be "Removal of user preferences", but in general this doesn't offer any solution. What you want is probably a RfC to produce some criteria to decide what preferences are "useless" and can be removed or disabled, and what's the process to follow. Such removals in the past have been very dubious and increased conflict. I personally prefer solutions which don't remove functionality: there's much more to do in that area, see e.g. the confusion tracked by bug 31882.
(In reply to comment #1) > Do we have any way to ship gadgets bundled with core? If not, this bug actually > means "remove some user preferences altogether". > A more useful tracking bug would be "Removal of user preferences", but in > general this doesn't offer any solution. Hmm, right. We'll probably need one tracking bug for "core user preferences evaluation" and then several underlying tracking bugs for the various options of what to do (gadgetize --> this bug; remove altogether --> another tracking bug; move to a different section --> another [tracking] bug; etc.). > What you want is probably a RfC to produce some criteria to decide what > preferences are "useless" and can be removed or disabled, and what's the > process to follow. Such removals in the past have been very dubious and > increased conflict. Aye: <https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences>. > I personally prefer solutions which don't remove functionality: there's much > more to do in that area, see e.g. the confusion tracked by bug 31882. Adding a user preference isn't a blood oath to always support the feature in that particular implementation. Moving things out of core (and/or into gadgets) is fine sometimes.
(In reply to comment #2) > Aye: > <https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences>. So far that seems an inventory of preferences and personal opinions which disregards both my suggestions: 1) > Do we have any way to ship gadgets bundled with core? 2) > RfC to produce some criteria to decide [...]
Criteria would be useful.
(In reply to comment #3) > (In reply to comment #2) >> Aye: >> <https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences>. > > So far that seems an inventory of preferences and personal opinions which > disregards both my suggestions: > > 1) >> Do we have any way to ship gadgets bundled with core? > 2) >> RfC to produce some criteria to decide [...] It doesn't disregard your suggestions, it mostly side-steps them. Some functionality should be removed. Bundling the gadgets with core would defeat most of the purpose of (a) removing the user preferences from core (you don't lose the code weight); and (b) removing the user preferences generally (as you're essentially just moving the preferences from one tab in Special:Preferences to another). Regarding criteria for removal, there's an RFC in progress. Add a section about criteria for removal/gadgetization if you're concerned about that?
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #2) > >> Aye: > >> <https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences>. > > > > So far that seems an inventory of preferences and personal opinions which > > disregards both my suggestions: > > > > 1) > >> Do we have any way to ship gadgets bundled with core? > > 2) > >> RfC to produce some criteria to decide [...] > > It doesn't disregard your suggestions, it mostly side-steps them. Some > functionality should be removed. Bundling the gadgets with core would defeat > most of the purpose of (a) removing the user preferences from core (you don't > lose the code weight); and (b) removing the user preferences generally (as > you're essentially just moving the preferences from one tab in > Special:Preferences to another). > Indeed. Aside from that, it is imho technically a bad idea to ship gadgets by default (unless provided through a repository). Because gadgets are stored as pages, so they'd get out of date quickly and would only clutter people's repositories with hardcoded copies. Also note that Gadgets is an extension, not a core feature. We don't want more scripts floating around doomed to get out of date and not be used.
So we need a repository!
(In reply to comment #7) > So we need a repository! You have an interesting way of interpreting comments.
(In reply to comment #7) > So we need a repository! First off, not all preferences can be reproduced with css/javascript. Certain preferences really should be handled server side. Having that said, a gadget repository is probably not a good solution for this. As MZMcBride pointed out a little bit already, that would move the preferences from one tab to another. I'd say that's for the worse. It'll only clutter the gadgets tab. I'd say we can create an extension called "LegacyPreferences" that implements them exactly the way they used to be in core (be in server side, client side or both, whatever the implementation was in core). Then when preference is removed from core, but some people still want it, it can be moved there instead. Then you'd have something like this: -- LocalSettings.php require_once( "$IP/extensions/LegacyPreferences/LegacyPreferences.php" ); // By default each is false, enable the ones you want to bring back $wgLegacyPreferencesEnabled['cols'] = true; $wgLegacyPreferencesEnabled['highlightbroken'] = true;
(In reply to comment #9) > > First off, not all preferences can be reproduced with css/javascript. Certain > preferences really should be handled server side. > > Having that said, a gadget repository is probably not a good solution for this. Not a solution, but having a central repository of gadgets would help with at least getting some of the random styling tweaks people have grown fond of out of core. It would need to be easily searchable, however, as indeed such a thing would get very large very quickly. Rather like some wikis' lists of gadgets already, really. > I'd say we can create an extension called "LegacyPreferences" that implements > them exactly the way they used to be in core (be in server side, client side or > both, whatever the implementation was in core). Then when preference is removed > from core, but some people still want it, it can be moved there instead. Would that result in the preferences still showing up as regular preferences on any wiki using it, then? While that would be an improvement to core for new projects, it only solves part of the issue as there wouldn't be much of a usability improvement for those with an existing userbase that would demand it.
(In reply to comment #10) > > I'd say we can create an extension called "LegacyPreferences" that implements > > them exactly the way they used to be in core (be in server side, client side or > > both, whatever the implementation was in core). Then when preference is removed > > from core, but some people still want it, it can be moved there instead. > > Would that result in the preferences still showing up as regular preferences on > any wiki using it, then? While that would be an improvement to core for new > projects, it only solves part of the issue as there wouldn't be much of a > usability improvement for those with an existing userbase that would demand it. Yes, they would show up as regular preferences. MediaWiki has hooks to allow extensions to add additional preferences. The preferences provided by this (hypothetical) "LegacyPreferences" extensions would look and do exactly the same from a user perspective. They can (and should) also use the same preference key (so that users who had the old core option enabled will automatically now trigger the extensions' preference). Except for the order in which the preferences are listed on the preference tab, the user would not notice any difference (same key, same value, same label, same preferences section/tab, same functionality).
(In reply to comment #9) > I'd say we can create an extension called "LegacyPreferences" that implements > them exactly the way they used to be in core (be in server side, client side or > both, whatever the implementation was in core). Then when preference is removed > from core, but some people still want it, it can be moved there instead. I don't have opinions on the new summary, but I've read somewhere that the so-called "gadgetization" had as a purpose moving the preferences to another tab to reduce clutter in the others. If that were the purpose, just using the existing (almost empty) "Misc" tab would achieve it quickly.
I don't see anything being tracked here; removing "tracking".
