Some thoughts on:
https://www.mediawiki.org/wiki/Requests_for_comment/Core_user_preferences
and associated patchsets:
https://gerrit.wikimedia.org/r/#/c/27259/ https://gerrit.wikimedia.org/r/#/c/27258/ https://gerrit.wikimedia.org/r/#/c/27257/ https://gerrit.wikimedia.org/r/#/c/27197/ https://gerrit.wikimedia.org/r/#/c/27206/ https://gerrit.wikimedia.org/r/#/c/27202/ https://gerrit.wikimedia.org/r/#/c/27201/
I'm 100% in favor of de-cluttering prefs. IMO this ought to be done on the basis of proper metrics of current usage, so that we actually understand who is using these options today and why.
Do we have a more complete report than https://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences ? If not, could someone pull one? It would be ideal to not only have prefs listed by frequency, but to also exclude users from the set who've not been recently active.
Erik
Erik Moeller wrote:
I'm 100% in favor of de-cluttering prefs. IMO this ought to be done on the basis of proper metrics of current usage, so that we actually understand who is using these options today and why.
Some of the RFC is also trying to focus on the history of some of these user preferences. A lot of these preferences are very old and pre-date the Gadgets extension, for example. Some of them would make more sense implemented differently (client-side v. server-side) while some of them ought to simply be moved to a MediaWiki extension or possibly be removed altogether.
Do we have a more complete report than https://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences ? If not, could someone pull one? It would be ideal to not only have prefs listed by frequency, but to also exclude users from the set who've not been recently active.
That report is based on the Toolserver's MySQL view of the user_properties database table called "user_properties_anonym" (the report's Python source code can be found one layer below at /Configuration). To get aggregate stats about user preferences, it requires someone with shell access querying the database. I think everyone who's commented on the RFC agrees that stats would be helpful. Does this require an RT ticket or a Bugzilla ticket or an e-mail to the analytics people or something else?
MZMcBride
On Mon, Oct 8, 2012 at 5:49 PM, MZMcBride z@mzmcbride.com wrote:
Some of the RFC is also trying to focus on the history of some of these user preferences. A lot of these preferences are very old and pre-date the Gadgets extension, for example. Some of them would make more sense implemented differently (client-side v. server-side) while some of them ought to simply be moved to a MediaWiki extension or possibly be removed altogether.
Agreed. But we should be clear that "gadgetize" right now would likely mean removal of these features from most if not all wikis, because re-implementing them as gadgets everywhere is such a pain. This may be OK for most or all of these prefs, but IMO still requires a bit more data and visibility before we make that call. I've pinged analytics to see if they can get us a better prefs report.
Erik
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 Tue, Oct 9, 2012 at 3:53 AM, Krinkle krinklemail@gmail.com wrote:
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").
I'm not sure if making it a Gadget is a good idea (and you make a good case that it's not), but this idea would be worse in many cases. Many preferences, if removed from core, would require a hook in order for LegacyPreferences to handle it. A hook that we would then have to support for the foreseeable future.
-Chad
On Mon, Oct 8, 2012 at 11:12 PM, Erik Moeller erik@wikimedia.org wrote:
I've pinged analytics to see if they can get us a better prefs report.
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
Le 09/10/12 01:52, Erik Moeller a écrit :
Do we have a more complete report than https://en.wikipedia.org/wiki/Wikipedia:Database_reports/User_preferences ? If not, could someone pull one? It would be ideal to not only have prefs listed by frequency, but to also exclude users from the set who've not been recently active.
We have the maintenance/userOptions.php script which can give usage for all user preferences or just for a specific one. Example on my local development wiki:
$ php userOptions.php --usage gender Usage for <gender> (default: 'unknown'): 2 user(s): 'female' 1 user(s): 'male'
Done. $
It does not filter by user age though, but I guess that will be trivial to implement by using `user.user_touched`. Will be happy to review and validate any change made made to improve that script.
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
On 10/9/12 5:25 PM, Federico Leva (Nemo) wrote:
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.
Admittedly, having started circa 2003, I've not revisited or reset most of those settings very often -- and didn't notice some even existed.
But I don't usually run with JavaScript (rather, I use NoScript by default), so "gadgetization" seems like a terrible idea to me!
You're not saving anything by moving from one place to another. It's just another chance for further bit-rot.
William Allen Simpson wrote:
On 10/9/12 5:25 PM, Federico Leva (Nemo) wrote:
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.
Admittedly, having started circa 2003, I've not revisited or reset most of those settings very often -- and didn't notice some even existed.
But I don't usually run with JavaScript (rather, I use NoScript by default), so "gadgetization" seems like a terrible idea to me!
You're not saving anything by moving from one place to another. It's just another chance for further bit-rot.
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
wikitech-l@lists.wikimedia.org