Page MenuHomePhabricator

Statistics about /active/ users of skins on the Wikimedia cluster
Closed, ResolvedPublic

Description

Request

What's requested:
Wikipedia's preferences offer you due to historical reasons under the Preferences > Appearance tab four skins to choose from besides the default Vector.

Why it's requested:
We're still offering CologneBlue, Modern, MonoBook options aside of Vector and it would be great to have a better understanding of our users.
I'm aware of the statistics provided by https://wikiapiary.com/wiki/Skin:Skins but from my understanding there are just installed skins counted. It would be interesting to get the number of active users (maybe something like skin setting and being repeatedly logged in during last 12 months)

When it's requested:
No current deadline to fulfill here.

Other helpful information:


Results

The skins listed are what the users actually see, which will be one of the four installed—old values like 'chick' that fall back to the default skin have been modified to reflect that. The users in each section are all the users who met the edit threshold when their edits from the past year were summed across all projects. Each user's skin was checked on the wiki where they made the most edits during the year (for both the edit threshold and home wiki identification, Wikidata edits were each treated as 1/10th of an edit to account for the greater granularity of edits there). Full data is in this spreadsheet.

Very active editors

Users with at least 600 edits during the past year.

skinusers% of total
vector21 25388.2%
monobook2 54410.6%
modern2431.0%
cologneblue490.2%
total24 089100.0%

Active editors

Users with at least 30 edits during the past year.

skinusers% of total
vector150 90394.5%
monobook7 4754.7%
modern1 0350.6%
cologneblue3240.2%
total159 737100.0%

All editors

Users with at least 1 edit during the past year.

skinsusers% of total
vector1 885 39097.5%
monobook39 8982.1%
modern6 2190.3%
cologneblue2 5440.1%
total1 934 051100.0%

Methods

Created an intermediate table using the following query:

create table staging.neilpquinn_editor_year
select
    user_name,
    # wiki relies on the DB system taking the first value in each group
    wiki as home_wiki,
    local_user_id as home_user_id,
    sum(edits) as adjusted_edits
from
    (select
    user_name,
    wiki,
    local_user_id,
    # special case to avoid unexpected choices of Wikidata as home wiki
    if(wiki = 'wikidatawiki', sum(edits) * 0.1, sum(edits)) as edits
    from staging.editor_month
    where 
    month >= '2015-11-01' and month < '2016-11-01' and
    local_user_id != 0 and
    bot = 0
    group by user_name, wiki
    order by user_name asc, edits desc
    ) user_wiki
group by user_name;

Ran the following query on all wikis using multiquery:

select
database() as wiki,
up_value as skin,
count(*) as users
from staging.neilpquinn_editor_year
left join user_properties
on home_user_id = up_user and up_property = "skin"
where home_wiki = database()
group by up_value;
multiquery ~/queries/skins_all_editors.sql -d ~/dblists/all_wikis.tsv -h analytics-store.eqiad.wmnet --defaults-file=~/.my.cnf > ~/data/skins_all_editors.tsv

Then repeated the multiquery, filtering first for >= 30 and then >= 600 edits.

Event Timeline

Volker_E created this task.Oct 7 2016, 11:51 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 7 2016, 11:51 PM

@Volker_E as I told you before, we're happy to help with this!

Would it work if we limited it to active editors—for example, users who've made at least 1 edit in the last year? We don't have much data on user logins, and in any case we wouldn't really cater to the niche preferences of people who never edit.

Neil_P._Quinn_WMF triaged this task as Low priority.Oct 9 2016, 1:16 AM

@Neil_P._Quinn_WMF I think this is a good start, works for me.

Is this just for Wikipedia or other Wikimedia sites too?

@Legoktm, I believe we're interested in all sites here, although the results will be weighted towards Wikipedia users since they're the most numerous.

For some legacy users, 0 means default (vector), and 2 means cologneblue.

(We really should clean up the preferences tables at some point.)

(We really should clean up the preferences tables at some point.)

The last time someone tried this it was very nasty: T114208. Related: T54777 and T54778, the latter of which got declined because of what a disaster T114208 was.

Neil_P._Quinn_WMF closed this task as Resolved.Dec 2 2016, 2:54 AM
Neil_P._Quinn_WMF claimed this task.
Neil_P._Quinn_WMF updated the task description. (Show Details)
Neil_P._Quinn_WMF updated the task description. (Show Details)
Kghbln added a subscriber: Kghbln.Dec 2 2016, 6:09 PM
Neil_P._Quinn_WMF renamed this task from Statistics about /active/ users of Wikipedia's skins to Statistics about /active/ users of skins on the Wikimedia cluster.Dec 5 2016, 7:44 PM

(We really should clean up the preferences tables at some point.)

The last time someone tried this it was very nasty: T114208. Related: T54777 and T54778, the latter of which got declined because of what a disaster T114208 was.

Yep, which means this statistic doesn't necessarily capture what users *wanted*.

The last time someone tried this it was very nasty: T114208. Related: T54777 and T54778, the latter of which got declined because of what a disaster T114208 was.

Yep, which means this statistic doesn't necessarily capture what users *wanted*.

While that was definitely a bad incident, I doubt it had much effect on this data. I looked only at the skin preferences of active users (using varying definitions of 'active') on the wiki where they're most active.

The preference corruption happened on September 30, 2015. I pulled this data on December 1, 2016. If an active user didn't change their preference back on the one wiki where they're most active given 14 months to do so, I think it's fair to say they don't care :)

I think it's fair to say they don't care :)

Or maybe they didn't know that they could switch back, e.g. they thought that monobook had been removed altogether. It's unbelievable how easy people get lost in preferences. :)

Cleaning up preferences: Yes.

Something I find also interesting is what Firefox does with "about:config", making the lesser used settings harder to discover but still changeable (and the overwritten entries could be easily listed somewhere more visible). Also, it comes with a "really want to do this?"-warning.

Something I find also interesting is what Firefox does with "about:config", making the lesser used settings harder to discover but still changeable (and the overwritten entries could be easily listed somewhere more visible). Also, it comes with a "really want to do this?"-warning.

I strongly agree. I put a similar note in the description at T70689 and have discussed elsewhere. (There used to be a great extension which added descriptions for each of those about:config lines.) As I wrote a few years ago:

I'm generally a fan of options, particularly advanced-options for advanced-users. Firefox does this Right™ with their "about:config" page. Ubuntu and Windows angered a LOT of their powerusers, in recent years, by trying to remove the "underutilized" advanced-options. Hiding them (whether by moving them to subpages, or CSS/JS visibility-toggling), or Rearranging/Restyling them (to be less overwhelming for newcomers), is vastly preferable to Removing them.

But that of course needs to be balanced with the pragmatic complexities, which I tried to list in the top half of https://www.mediawiki.org/wiki/Just_make_it_a_user_preference

@Jan_Dittrich, that's an interesting conversation, but to prevent annoyance and to increase future findability, I think would be better held in a task where it's more relevant. Perhaps T64559 or T54777?

Neil_P._Quinn_WMF raised the priority of this task from Low to Needs Triage.Mar 30 2018, 10:28 AM
Neil_P._Quinn_WMF moved this task from Neil's in progress to Done on the Contributors-Analysis board.
Restricted Application added a project: Product-Analytics. · View Herald TranscriptJun 11 2018, 2:24 PM