WordPress.org profiles: fix the credits API to correctly reflect release squads

[annezazu]

I was on the release squads for WP 5.9 to 6.6 yet my profile just shows one of those releases (6.0):

Digging into this, it's due to the Credits API and its limitations. In talking to @desrosj he helped clarify that the profile code is only showing those with a label in the core-developers key as part of the squad whereas starting in 6.8 we returned to noting everyone on the squad. For WordPress 6.0, the one release it has me as, I am listed as being a part of the Core Developers. Jonathan noted that we could retroactively add labels, but the issue is the strings are not guaranteed to be present or translated in older versions.

IMO, until this is fixed, I think it's worth manually getting right considering it's really helpful to see people's release experience, especially when evaluating folks for release squads.

[desrosj]

I've been thinking this through a bit. I think it's certainly desirable to add a higher level of fidelity for the credits API. In addition to squad names, there's currently no way to distinguish between those who contributed to the minor releases for a given version (7.0.1, 7.0.2, etc.). Instead, contributors who did not contribute to the major release are just folded into the X.Y credits.

Back filling and returning new data in the current endpoint is a bit risky, though. It's possible, even with an associative array, that code somewhere will break if the ordering of the returned data changes. And as Anne mentioned, adding the squad titles for older releases is definitely not an option as the strings will be untranslated in older (added in 6.8 through r59545).

However, I do think it's preferable to add the data to the same general API endpoints. A few approaches come to mind:

• Only return the squad data for releases < 6.8 when a query parameter is included. Maybe release_team=1 or with_team=1.
• Add a new endpoint path (say https://api.wordpress.org/core/credits/1.1/release-team/?version=6.8) that returns only the release team details.
• Add the data to new releases only (WP >= 7.1).
• Create a new version of the endpoint (core/credits/1.2/).

I don't know enough about the history behind this API, though. I would love to get some thoughts and initial reaction to these options from @dd32.

[jeffpaul]

👋🏼 👿 Devils advocate here

The concerns with strings and potential breakings on rendering is primarily (ONLY?) limited to the Credits page. And more specifically, credits pages on older releases. What's the total number of users you really expect to update to an old version and hit the credits page AND have an actual issue here? That's got to me fairly close to 0. Thus, given some data improvements to the credits API can immediately improve our rendering on profile pages (and not require us to have another JSON store or a credits v2 which is all just more work) I think these are acceptable "risks" to accept to have improved credit data available.