The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: heavyweight <kpapazov@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: TimothyBJacobs <timothyblynjacobs@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Thanks for contributing, @heavyweight!

Based on my experience, it might be better to propose exposing user roles via the REST API on Trac, where this component is developed and maintained.

The block editor usually adds shims for REST API data that it needs, but since there's no actual use case for the user roles, it's hard to justify merging this proposal.

Extenders can create their endpoints or modify existing ones and use the fetch API.

Thanks for contributing, @heavyweight!

Based on my experience, it might be better to propose exposing user roles via the REST API on Trac, where this component is developed and maintained.

The block editor usually adds shims for REST API data that it needs, but since there's no actual use case for the user roles, it's hard to justify merging this proposal.

Extenders can create their endpoints or modify existing ones and use the fetch API.

Thanks for taking the time to review.
I agree that currently there is no actual case for the user roles changes.
But the way that I see it is that this is basic data that is easy to expose. I could see use case for this for developers where they can easily fetch them instead of creating endpoints. I'm not familiar with the core wordpress development process but it seems slower and less streamlined than here, so I thought I can follow the same patterns to do extensions here while I create a PR there as well.

Creating a ticket on Trac will be a good start. That's also part of the backport process for similar PHP changes. See: https://github.com/WordPress/gutenberg/blob/trunk/backport-changelog/readme.md.

But the way that I see it is that this is basic data that is easy to expose.

The rest_index is usually used to expose a small amount of data about the site. I'm not sure if it's the best place for exposing user roles. The REST API component maintainer will have a better idea.

cc @TimothyBJacobs, @spacedmonkey

Yeah I agree with @Mamaduka. This isn't appropriate for the index. I'd model this as a standalone controller that also includes the list of capabilities assigned to the role.

And yeah, unless this is powering a Gutenberg feature, and the controller would need iterating, this should be made as a PR in Core.

Thanks for the confirmation, @TimothyBJacobs!

@heavyweight, please raise a ticket on Trac for this feature request. I'm going to close this as "won't fix" for now.