Page MenuHomePhabricator

Inform community on changes to images API
Closed, ResolvedPublic


Inform community on the following changes to images API:

  1. Allowing hovercards to display free and non-free images: T131105: Pageimages should return both free and non-free images with 'free-ness' denoted as a property
  2. Allowing PageImages to only select images from infobox and lead T87336: PageImages shouldn't return images that are not in the lead section
  3. Allowing logged in users to select PageImages T91683: Allow editors control of the page image

Event Timeline

Qgil added a subscriber: Qgil.

Are these API changes to be communicated to developers only, or should we also involved editors?

Do we know the impact about these API changes? Is there a possibility of breakages elsewhere, especially in volunteer-driven projects? Are we marking existing APIs as deprecated? Is there a compatibility path? Has this been discussed with other engineering teams, wikitech-l, TechCom...?

Also a question caused by my own ignorance. Is this images API part of the MediaWiki API or are they provided by Hovercards / another extension?

@ovasileva I am very sorry for all these questions. :) Hopefully everything is under control. I'd rather play safe, considering how things went in some occasions where we changed APIs too lightly.

@Qgil - no worries :) I think the changes will be rather small. Basically we want to:

  1. Prevent images from showing if they're not in the lead section of the article
  2. Allow editors to select the image appearing in the hovercard (this is tentative based on how much space/time we have)

@ovasileva one question: you assigned this task to yourself, does it mean that you will go ahead and complete it or are you expecting the Community-Relations-Support to do it?

@Qgil - this one is assigned to me as it still needs some product requirements - once those are done, I'll update the task description and hand it off to the community liaisons.

Hi again-just wanted to reiterate the suggestion to have one task per person-you can even establish a relationship between the two, so the CL one would depend on yours.

I just want to reiterate on @Elitre's advice. If someone needs to complete something before the community liaisons can start their work, then that something needs to be reflected as a blocking task.

This might sound a bit bureaucratic, but actually helps reflecting better the reality as is. For instance, in this task it might look that as soon as @ovasileva has completed her part, a liaison will step in and take it. However, the reality is that as of today, there is no liaison committed for that task. This would become evident if there were separate tasks, now it is a hidden problem.

@Qgil - I understand. Sorry for the delay - updating task description now, and it should be ready to be picked up.

ovasileva updated the task description. (Show Details)
Moushira triaged this task as Medium priority.

@Qgil - not stalled - this was a task to make a community announcement reflecting the pageimage changes.

Is this announcement waiting for any other event, or is it a matter of conducting it?

@Qgil - just a matter of conducting. We are planning on making the announcement and proceeding with the changes live immediately afterwards

I am not sure whether this task belongs to @CKoerner_WMF or @ovasileva right now. In any case, I am removing Moushira as owner to reflect the current situation.

Hi - sent an update yesterday - I think this can be resolved.