Contributors in plugins/update-check/1.1/

[blobfolio]

I am working on a Core enhancement (​https://core.trac.wordpress.org/ticket/42255) to notify site operators when a plugin they are about to update has changed contributor(s) since the last update. (Basically help deal with cases where a good plugin has been sold to bad people and turned evil.) Haha.

From the Core's point of view, the lightest way to receive the remote half of the equation would be to just have contributors returned from the ​http://api.wordpress.org/plugins/update-check/1.1/ call.

Is this a practical ask from the API side of things?

The format returned by plugins/info/1.0/ would work well, e.g:

"contributors": {
   "blobfolio": "https:\/\/profiles.wordpress.org\/blobfolio"
},

[blobfolio]

@ipstenu pointed me toward #2717, which covers the bigger issue of tracking plugin changes on the Meta side.

It might be better to wait for progress on that front, as it would then open up the possibility of reporting contributor changes from version X to Y, bypassing the need to parse that within the Core, and keeping the data more authoritative. :)

[Ipstenu]

So this is _already_ documented in the info API (see ​https://api.wordpress.org/plugins/info/1.0/akismet for an example) and shouldn't be too hard to port over if we wanted.

But that doesn't solve the tracking issue, which is not actually an API one, but ties back to a logging one. Really this should be tracked in the adult log - https://meta.trac.wordpress.org/ticket/2717

Adding the contributors to the update information doesn't strike me as beneficial in the long run, since we also grab the readme for data on the update anyway and that already has the authors. And since the devs can't change the 'owner' of a plugin (only plugin team admins can at the moment) that wouldn't actually be changing in a way that would be useful.

In the end, all this method would do is after the fact let people know there was a new author, which really they'd know by the changed from the readme, and could be grabbed, parsed, and stored in options if needed.

Ultimately, I don't think this solves the root of the issue, which really is "We need to track ownership changes because some people are naughty developers." This just pushes that down the road and would require people to actually notice the change. As we increase the reliability of updates, the more people automate those things, and the less beneficial that would be :/