Also note that, as explained in more detail on the ticket[1], gadgetizing will be a bad idea. We might as well not remove it at all. A preference is a lot better than a gadget because (at least for now) its label will be localised a lot better, and more importantly: The option will show up in the relevant preferences section. For reasons explained elsewhere, shipping gadgets by default with the Gadgets extension is not an option and generally counter-productive and bound to cause unwanted/unmaintained scripts to rot in wikis after being injected upon installation. That's now how the Gadgets extension work, and imho it should stay that way. Instead of gadgetization, a better option would be to move them into an extension (not the Gadgets extension). Which means the extension can: * add it to the preferences section where it used to be * use the same key as the old preference in core, so that users don't have to reset their preferences (as opposed to "gadget-foo"). Especially the latter is in my opinion a must-have for the smooth migration of any wiki that decides to install this "LegacyPreferences" extension after upgrading their MediaWiki-install. Besides, most of the preferences discussed here aren't worth a gadget (I guess most communities will not want them in the preferences section after voting to have them disabled/removed from core). They don't add any significant features, only silly visual options that someone afraid of change insisted on in the past. That is, of course, referring to preferences we would end up removing after some kind of consensus. I'm not talking about all preferences or any preference in particular . In other words: If the story is "remove them from core, add as default-available[2] gadget". Then please, *please*, keep them in core. Because that wouldn't be an improvement over the current situation. If we have good ground to remove them (because they're silly options that we don't want end-users to be thinking about), then we remove them. Don't move them from one junkyard to another. -- Krinkle [1] https://bugzilla.wikimedia.org/40346 [2] default-available != default-enabled

On Mon, Oct 8, 2012 at 11:12 PM, Erik Moeller &lt;erik(a)wikimedia.org&gt; wrote: Dario Taraborelli has kindly made a detailed dataset of preferences available. He can chime in with details if needed. The dataset can be found here: http://thedatahub.org/dataset/wikipedia-user-preferences These datasets capture the following: - user_properties set to '' from the default -> active_prefs_0 - user_properties set to 1 from the default -> active_prefs_1 -> NOTE: This can be very misleading for non-boolean prefs - user_properties set to !='' from the default -> active_prefs_all This is based on a dataset of _active_ users which is included. Unchanged prefs aren't included, specific non-boolean settings aren't included, and prefs with < 5 users aren't included. This is en.wp, other languages to follow. Note there's all kinds of funkiness with how prefs may be serialized to the DB - prefs names and defaults may have changed, prefs may have been removed, and some stuff is serialized when it doesn't need to be (suggesting that prefs have been changed, when in fact the user has just performed a pref save). But for a lot of the more obscure prefs this should be good initial guidance. Will post some initial observations to https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate

Just reiterating that discussing individual preferences (not to mention touching them) is a very bad idea before we have good criteria of some sort to evaluate them. Usage stats are a requirement but such criteria are not only about them because some preferences may be of small harm for many and of great use for "a few" (like thousands or dozens of thousands of users) who may also happen to be the most active users, making such prefs a net positive. Oh, and of course "gadgetization of preferences" means (almost) nothing. Nemo

William Allen Simpson wrote: The virtue of gadgetization comes from the idea that MediaWiki, following the development of Wikipedia, contains a number of user preferences that were tailored to a specific problem or a specific need on (the English) Wikipedia that might be better handled nowadays by a local solution (such as a JavaScript gadget). Yes, of course, gadgetization ultimately moves the user preference from one tab to another and there are still code maintenance costs, but gadgetization can reduce the complexity of MediaWiki (in terms of code and UI clutter). I think the usage stats will be illuminating. And, of course, having global (Wikimedia-wide) gadgets or a gadgets repository for any MediaWiki installation to use would mitigate some of the other pitfalls of gadgetization. That doesn't mean it's evil, that just means gadgetization needs to be used sensibly. Much like anything else. MZMcBride