While working on this issue, it might also be appropriate to spend some time updating the list so that any currently inactive experts are removed and currently active experts are added. Any active core developer who has experience reviewing PRs in a given category and is interested could be added.

I also prefer option 1.

I believe there is an existing mechanism to automatically +nosy people in experts list to issue in bpo. Not sure if changing the format will break anything. Perhaps someone more familiar with bpo can chime in.

The experts list is read to populate the nosy auto-complete options, see here for the code that reads it. Any change to the experts list should either be made to conform to the existing code, or come with a pull request to that code to parse the new format (if done before PEP 588 is implemented).

@zware

Any change to the experts list should either be made to conform to the existing code, or come with a pull request to that code to parse the new format (if done before PEP 588 is implemented).

Alright, I could start working on this and test it by locally hosting the raw experts page and attempting to extract data from it. I have some experience working with urllib and json parsing in general.

Alternatively, would it be practical for us to setup an API which contains just the expert data in json format? This would allow for separation between the webpage and data extraction. It would likely result in an increase in extraction performance and allow the webpage's UI to not be dependent on a specific format for data extraction. As an example of what I'm talking about:

webpage: https://www.reddit.com/r/Python
API: https://www.reddit.com/r/Python.json

I'm not sure as to how involved it would be to do something similar with the existing RST pages. It wouldn't have to be done for every page by any means, just the ones that we specifically we have a use for frequent data extraction, such as the experts index. For now though I'll just work on allowing for compatibility with the existing extraction.

It would be quite useful to have something similar for GitHub labels. Currently the type labels such as type-documentation don't actually have any functionality other than organization, but preferably they'd be able to extract the data from the experts list and add any of the experts in a given category to the PR reviewers. This would result in a significant workflow improvement, and increase the benefit that the new GitHub triager role could provide.

I don't know about setting up an API, but I think it would be reasonable to store the experts data in JSON format, and generate both the nosy auto-complete and the table in experts.rst from the JSON data.

It can just be a .json file within this repo on GitHub. Bpo can then read from it. Automatically converting to .rst is great too.

I don't know about setting up an API, but I think it would be reasonable to store the experts data in JSON format, and generate both the nosy auto-complete and the table in experts.rst from the JSON data.

It can just be a .json file within this repo on GitHub. Bpo can then read from it. Automatically converting to .rst is great too.

Yeah I'm thinking this might be the best way to do it. An API probably wouldn't be necessary since we're really the only ones making use of the data. Would it be preferable for me to start working on that first or should I work on just making the current data extraction compatible with the GitHub usernames in parenthesis?

For the first option, I could start by figuring out a the best way to organize the JSON. I was thinking of having the top level be the expert categories, with the immediate children being the real name of the experts. Their real name would contain a property for each site's username. For example, to specifically get Carol Willing's GitHub username it would look something like this:

documentation.carolWilling.github -> willingc

When the type-documentation tag is added, a list would be constructed from the github properties of any immediate children of documentation.

Usually within Python the preference is to use underscores for spacing (also my personal preference), but JSON typically uses camelCase. I'm not certain if we have any examples of existing JSON files within the Python repos, I'll have to look around.

The main thing I'm unsure of is reading the JSON data into the table of experts.rst, just because I haven't done anything like that before with reST.

@zware Let me know if you have any feedback for the experts JSON: #517

There might be a few entries to be updated (if the experts weren't on the BPO committers list, I used that to create the JSON), but that can easily be adjusted. I'm primarily concerned about ensuring the formatting is correct before moving on any further with this issue.