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:

Do we have any way to ship gadgets bundled with core?

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:

Do we have any way to ship gadgets bundled with core?

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:

Do we have any way to ship gadgets bundled with core?

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".

The RFC associated with this task (Core user preferences) has another task associated with it as well: T54807. The other one has become the main place for discussion about that RFC, however.

This task has has been narrowed down in its scope to discuss whether and how to retain deprecated user preferences.

Discussion about the general removal (or deprecation) of various legacy preferences continues at T54807.

Are there any examples of what's being requested in this task actually?

The summary talks about "user preferences that were removed from core" (and hence are not around anymore) while the task description talks about "track bugs about specific MediaWiki user preferences that could be gadgetized".
Clarification welcome.