Document and automate updating of static/project-logos in mediawiki-config
Open, Needs TriagePublic

Description

Status:

  • Decide where to document the logo updating process (e.g. https://meta.wikimedia.org/wiki/Requesting_wiki_configuration_changes, or maybe a README in mediawiki-config.git).
  • Decide on the requirements for updating a logo, and agree on how to meet those requirements. (e.g. file must be on Commons?, create 1.5x and 2x PNGs thumbs, optimise with optiPng/zopfli?, submit via SWAT, remember to purge)
  • Document the process in the decided location and ensure it is well advertised and links from various places.
  • Automate part of the process (e.g. a bash script that takes a Commons file name, and does download/optimisation).
  • Decide how to verify the commits in Gerrit (against malice and mistakes). E.g. a Jenkins job to run the script and confirm the committed file is the same or smaller (to confirm optimisation), and visual comparison by hand? Or also automated (SSIM?).
Original description by @ori

Change I8c9a6a567 moved the image files for project logos into the operations/mediawiki-config repository. Doing so allows us to set far future expires cache headers for these images. The impact of the change was bigger than I anticipated because it had social consequences which I did not fully understand.

  • Communities use the ability to upload a new version for a local file to set a temporary logo to mark some occasion. With I8c9a6a567 deployed, admins are still able to override the logo, but only via a Common.css rule. This needs to be communicated. @gpaumier is taking care of that. (Thanks!)
  • The use of Common.css hacks should be discouraged. Communities should follow the process described in meta:Requesting wiki configuration changes instead, and we should make sure we respond to such requests promptly. Note, configuration requests have always failed to work: see T28992, T7532, T28993.
  • The mapping of image files in the config repository to the Commons images from which they derive should be preserved. I propose to do that by having the Commons URL for each project's logo declared in a configuration file, and having a build script that (re-)populates the project-logos directory by retrieving each image from its canonical location and applying lossless image optimization.
ori created this task.May 8 2015, 9:01 PM
ori updated the task description. (Show Details)
ori raised the priority of this task from to Needs Triage.
ori claimed this task.
ori added subscribers: ori, Nemo_bis, Krenair and 2 others.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 8 2015, 9:01 PM
Krenair set Security to None.
Krenair added subscribers: Glaisher, Dereckson.

Has this changed been discussed with the communities anywhere?

ori added a comment.EditedMay 8 2015, 9:11 PM

Has this changed been discussed with the communities anywhere?

@Peachey88: No, because I did not anticipate the community impact, out of ignorance. @gpaumier is adding a write-up for Tech News.

  • The use of Common.css hacks should be discouraged. Communities should follow the process described in meta:Requesting wiki configuration changes instead, and we should make sure we respond to such requests promptly.

There's potentially some discussion that needs to happen here:

  • Should we still be OK with using common.css for temporary logo changes on smaller wikis?
  • Should we require community consensus for logo changes (as is the norm for most config change requests) or allow it to be approved by a local wiki admin (who can presumably just edit common.css, except I guess in "those" circumstances)?

I'd say:

  • commons.css is fine, as long as the logo is served from the static host and not from commons
  • getting an image on the static host does not need community consensus
    • but maybe requires being a sysop
  • changing the /default/ logo (i.e. the url in the configuration file) needs some sort of community consensus
    • which can maybe also be shown with 'we've used this logo for ages via commons.css now'
  • getting an image on the static host does not need community consensus

Changing (or planning to) a community logo, really does need census.

valhallasw added a comment.EditedMay 8 2015, 9:28 PM
  • getting an image on the static host does not need community consensus

Changing (or planning to) a community logo, really does need census.

Storing, not overwriting. After it is stored there, it can be used via commons.css without any performance implications, and it's up to the communities to regulate changes in commons.css.

Bawolff added a subscriber: Bawolff.May 8 2015, 9:36 PM

The use of Common.css hacks should be discouraged. Communities should follow the process described in meta:Requesting wiki configuration changes instead, and we should make sure we respond to such requests promptly

If the logo is for a short temporary event doing changes in the config files might not get through various caches fast enough to properly mark the event (Thinking of varnish for anons). Common.css has the benefit of being pretty instant

gpaumier moved this task from Backlog to Triaged on the Notice board.
gpaumier moved this task from To Triage to Announce in next Tech/News on the User-notice board.

@ori I've added a note to https://meta.wikimedia.org/wiki/Tech/News/2015/20 , to be delivered to subscribers on Monday. Please check that the wording is accurate and appropriate (keeping in mind that we need to use very simple language to preserve readability). I'll freeze the text in a couple hours so it can be sent to translators.

ori added a comment.May 9 2015, 12:55 AM

Please check that the wording is accurate and appropriate

LGTM. Thanks again.

I think we should make sure all of the files get marked as no longer in direct use as actual wiki logos. And pages like https://commons.wikimedia.org/wiki/Commons:Auto-protected_files/global/logos could do with a note at the top.

Nemo_bis updated the task description. (Show Details)May 9 2015, 8:35 PM

Centralised logo management is a PITA and I don't have suggestions on how to handle it. Removing myself.

Nemo_bis removed a subscriber: Nemo_bis.May 9 2015, 8:36 PM

Communities should follow the process described in meta:Requesting wiki configuration changes instead, and we should make sure we respond to such requests promptly.

With SWAT deploy windows, urgent changes (by tasks opened wih a priority set to high) requested Mon-Thu could be processed the same day. For example, T97281 were handled in 4 hours (deployed during the next SWAT window).

He7d3r added a subscriber: He7d3r.May 14 2015, 4:09 PM
gpaumier moved this task from Triaged to Archive on the Notice board.May 29 2015, 8:21 PM
Krinkle added a subscriber: Krinkle.Jun 3 2015, 9:09 PM

If the logo is for a short temporary event doing changes in the config files might not get through various caches fast enough to properly mark the event (Thinking of varnish for anons). Common.css has the benefit of being pretty instant.

"Common.css" updates and configuration updates are both instantaneous. Configuration updates actually roll out slightly faster even.

What matters is whether we change the file or upload a new file, and whether we use upload.wikimedia.org or "/static". If one overwrites a file, users with a pre-existing cache will continue to see the old logo for a while. If one uploads a new file, the update will be instantaneous for everyone.

For short-lived overrides, we can upload a new file to "/static" (e.g. dewikinews-20K.png for the 20,0000 article celebration) and update wgLogo configuration to point to that instead.

For indefinite changes, the default logo file should be overwritten. Server caches will update instantly thanks for Last-Modified and ETag. Browser caches may take a while to update (though users can clear their own cache) but that's inevitable. Given the change is indefinite, the rollout can be a bit slower.

@ori wrote:

The mapping of image files in the config repository to the Commons images from which they derive should be preserved. I propose to do that by having the Commons URL for each project's logo declared in a configuration file, and having a build script that (re-)populates the project-logos directory by retrieving each image from its canonical location and applying lossless image optimization.

Sounds great.

Mjbmr added a subscriber: Mjbmr.Jun 16 2015, 9:12 PM
Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptNov 15 2015, 1:06 AM
Krinkle renamed this task from Articulate workflows (technical and social) for project logo management to Document and automate updating of static/project-logos in mediawiki-config.Mar 9 2017, 10:22 PM
Krinkle edited projects, added Deployments; removed Wikimedia-Site-requests.
@ori wrote:

The mapping of image files in the config repository to the Commons images from which they derive should be preserved. I propose to do that by having the Commons URL for each project's logo declared in a configuration file, and having a build script that (re-)populates the project-logos directory by retrieving each image from its canonical location and applying lossless image optimization.

Sounds like this could be a build script in mediawiki-config that takes a static file that maps wikis to a commons url. Right now changes are made to it and where they came from and whether (and which) optimizations are applied is a hard to verify. In addition because Gerrit doesn't show images.

The build script could run from a Jenkins job to also verify the contents are up to date. (e.g. fail if dirty; which will happen if the image isn't the one from Commons or if the optim wasn't run)

hashar removed ori as the assignee of this task.Mar 17 2017, 11:18 PM

Change 346234 had a related patch set uploaded (by Krinkle):
[operations/mediawiki-config@master] [WIP] Document and automate sources of static/project-logos

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

Change 346234 abandoned by Krinkle:
[WIP] Document and automate sources of static/project-logos

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

gpaumier removed a subscriber: gpaumier.Jul 18 2018, 5:56 PM