Created attachment 15872
database output of logged preference changes since 2013-07-13

Attached:

(In reply to Jared Zimmerman (WMF) from comment #0)

Based on preference change logs (since 2013-07-13) users across all wikis
overwhelmingly change thumbnail size to be 250-300px (see attached database
output graph)

we should update the default to be 300px

This shouldn't affect users who have purposefully changed the value, only
readers, and users who have not changed the default

Do you mean we should do this for MediaWiki software itself, for Wikimedia sites, or both?

We have numbers for wikimedia sites, but my inclination is to think that these small image settings were added back when bandwidth and screensize was more of an issue than it is now, so at minimum I'd recommend that we do it for mediawiki sites, and if there is no major reason not to, then mediawiki itself.

Have created bug 67709 for the Wikimedia sites part of the request.

Before changing the default (which we want to do as infrequently as possible), it might make sense to add larger options to the user setting, to see whether users pick 300px because that's the ideal size, or simply because that's the largest on the list, and they would prefer even larger sizes if they existed.

See also [[mw:Requests for comment/Standardized thumbnails sizes]].

(In reply to Tisza Gergő from comment #5)

Before changing the default (which we want to do as infrequently as
possible), it might make sense to add larger options to the user setting,

This was wontfixed for WMF cluster quite recently in bug 63440. Not sure that I quite understand what was going on there... I suspect this needs to be revisited by all involved (ops etc).

Gergő see the other bug i logged https://bugzilla.wikimedia.org/show_bug.cgi?id=67695 I'd prefer we choose a sensible "largest size" based on the users device, and page layout and kill the preference all together. But we can take this step by step.

Community consultation is here — https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Time_for_the_semi-annual_enlarging_of_thumbnail_images

and should wrap up on Wednesday July 16th.

Tisza Gergő, earlier this year, I asked for *one* larger image size to be added to preferences at bug 63440.

Actually, the plan was to *remove three* smaller sizes and *add one* (one, that not coincidentally is already in use at two projects, whose stats you might be able to check). The bug was WONTFIXed because one minus three equals positive two (because less is more, even when we're not talking about u*ix help pages?).

There was also a discussion in e-mail at http://lists.wikimedia.org/pipermail/wikitech-l/2014-April/thread.html#75849

This still needs an Ops/performance review before it can go out.

I think this should be fine, as long as a) we do it consistently across all wikis, and b) it's done in a somewhat slow, staged rollout, with smaller wikis first.

Yes, this will initially grow the amount of thumbnails on the Swift storage cluster, but that shouldn't be a big deal. We can eventually try to remove the older 220px thumbs.

I'll see if I can generate some stats on what percentage of originals already have a 300px thumb today...

(In reply to Mark Bergsma from comment #11)

I'll see if I can generate some stats on what percentage of originals
already have a 300px thumb today...

14:28 < godog> 220,xxx,5515811
14:28 < godog> 300,xxx,7330212

That's the number of thumbnails on the swift cluster in the relevant size. Looks like a bunch of 300px images have already been generated (more than the 220? crazy).

From everyone I've talked to today (Mark and Filippo), flipping the switch on this should be fine. Feel free to put it on the calendar for the week of the 25th sometime. (fyi: I'm on vacation all next week)

Change 154409 had a related patch set uploaded by Jforrester:
Set default setting for thumbsize to 300px (index 5) not 180px

https://gerrit.wikimedia.org/r/154409

(In reply to Greg Grossmeier from comment #12)

(In reply to Mark Bergsma from comment #11)

I'll see if I can generate some stats on what percentage of originals
already have a 300px thumb today...

14:28 < godog> 220,xxx,5515811
14:28 < godog> 300,xxx,7330212

That's the number of thumbnails on the swift cluster in the relevant size.
Looks like a bunch of 300px images have already been generated (more than
the 220? crazy).

From everyone I've talked to today (Mark and Filippo), flipping the switch
on this should be fine. Feel free to put it on the calendar for the week of
the 25th sometime. (fyi: I'm on vacation all next week)

I assume you meant this for bug 67709. Will schedule. ;-)

matthiasbecker1967 wrote:

I don't think this should be done without further verification. It is the primary sense for preferences that registered users can set values but unregistered users cannot. I am not sure wether is is helpful in areas with unsufficient bandwidth and/or where providers limit bandwidth and/or set different prices if tresholds have been used out.

(In reply to Matthias Becker from comment #15)

I don't think this should be done without further verification. It is the
primary sense for preferences that registered users can set values but
unregistered users cannot. I am not sure wether is is helpful in areas with
unsufficient bandwidth and/or where providers limit bandwidth and/or set
different prices if tresholds have been used out.

People hosting MediaWiki should always consider how they configure the wiki for their target audiences, including bandwidth appetite, I agree. However, I don't think that this should block a change for the MediaWiki software.

Maybe you're concerned about changing this for Wikimedia sites? That's bug 67709 and is separate from this.

Change 154409 merged by jenkins-bot:
Set default setting for thumbsize to 300px (index 5) not 180px

https://gerrit.wikimedia.org/r/154409

Note that the merged changes above doesn't affect Wikimedia wikis, as the configuration for both $wgThumbLimits and the 'thumbsize' preference is overridden. A separate configuration patch is going to be needed for that; it seems like deploying one is tracked on bug 67709.

Thanks, Bartosz.