Machine-parsable developers list

[ezio-melotti]

We currently have several lists of developers, some manually maintained, some machine-generated, including:

• a machine-parsable list in the voters repo (private)
• a machine-generated (from the list above) developers.csv (in the devguide repo)
• a machine-generated (from the csv above) developer log (in the devguide)
• a separately-maintained list of experts (in the devguide repo)
• a machine-generated (from the list of experts above) nosy-list autocomplete on bpo (no longer used)
• a separately-maintained translators list (in the devguide)
• a separately-maintained CODEOWNERS file (in the cpython repo)
• possibly others (e.g. release managers), more or less related to list of core devs

I suggest to consolidate this into two lists:

• the one in the voters repo (private) can remain mostly unchanged
• a new list in this repo can be created to list experts

The new list could use a similar format: listing users and fields about:

• their GitHub username
  • and possibly the GitHub teams they belong to (to generate teams)
  • see Automate Python triage membership. core-workflow#350
• the modules they maintain (to generate the CODEOWNERS file)
• the modules, interest areas, platforms, translation languages they are interested in (to generate the expert index)
  • the translator table could be moved back into the expert list
    • see also Move the "Translations" section into its own page. #842
  • the release manager table in the main page could be generated from this too
• possibly flags like is_triager, is_core_dev, release_manager=<versions>, translator=<language>
  • these could be used to mark names in the expert index and to create RM and translator tables
  • we could also have an is_bot for bots

We should also move some info from the voters file to here, in particular the joined, left, notes info. This information is already public and by moving it here we will remove duplication and simplify the generation of developers.csv in this repo. The only remaining duplicated info between the two lists will be the GitHub username.

Some relevant links:

• PR that implemented a similar idea: Add JSON for storing expert data #517
• Issue where the idea was proposed: Add github usernames to the experts index #507
• Discourse message about listing maintainers
• Discourse message about notifying experts

[ezio-melotti]

It would also be useful to have a list/table of triagers. On bpo we had a flag, and we have a team on GitHub now, but as far as I know we don't have any such list/table in the Devguide. This could still be generated automatically alongside with the GitHub team.

[ezio-melotti]

It might be useful to expand the expert list to the whole org.
In the past few weeks I saw people trying to figure out who was responsible:

• for the deployment of the docs (after noticing the online docs weren't being updated -- https://docs.python.org/3.11/whatsnew/3.11.html has not updated since 25 Apr cpython#92532)
• for the deployment of bedevere (broken after some github/heroku issues -- Add contributing and maintenance guide bedevere#454)
• for issues related to miss-islington (asked on Discord and on a Discourse post)
• for pyfound.python.org (a missing image reported on Slack)
• for updating the codeconv app (Enable Codecov comments bedevere#432 and others)
• for a discourse moderator, to ask to split a thread into two
• for adding new triagers to teams (Update "Checklist for Triaging" for GH Issues #850)
• for a number of other things

We currently have three additional lists that list some more maintainers:

• https://devguide.python.org/devcycle/#current-administrators
• https://devguide.python.org/devcycle/#current-owners
• https://devguide.python.org/#status-of-python-branches

Centralizing everything in the same place (the machine-parsable file and the expert list) will make things easier to discover. If we want to keep specific lists/tables of users in other pages there are two options:

• the pages can link to specific tables in the expert page
• additional csv files can be created from the file and used to populate additional tables in other pages

[CAM-Gerlach]

Another related item is that of the Platform experts list, which is rather out of date, and partially duplicated by the more current information in PEP 11. Much of the list is obsolete platforms CPython has officially unsupported (per ) for a long time (e.g. HP-UX, OS2/EMX) or never officially supported (JVM/Java, Cygwin), all of which have no active experts listed at all, whereas others are missing the maintainers they have listed in PEP 11 and still others are missing entirely.

We want to be DRY here and avoid having to maintain two places at once, with them inevitably getting out of sync. Therefore, at the very least we should clean out the cruft, just list the Tier 1 or sub-Tier 3 platforms that have active experts (since they aren't listed on PEP 11), and single sourcing the rest with a link to PEP 11.

However, an equally simple but perhaps much better solution is to just make the tables currently in PEP 11 into a machine-parsable CSV on the devguide repo, and then use the csv-table directive both here and (via the :url: option) on the PEPs repo to display them here.

Since this can be done as one atomic component of this migration, I could open a separate issue to cover it if desired, assuming people (e.g. @brettcannon ) agree.

[encukou]

(For clarity: support for platforms CPython core devs can't handle can still be maintained externally. The current out-of-date table is probably not useful at all, but as long as non-core devs are listed in these tables, a sub-tier-3 platforms is a valid interest area.
It could probably be merged into the general “miscellaneous” instead of getting special treatment, though.)

For Tier-1 platforms, IMO it would be useful to add Contacts column in PEP-11, possibly listing a team (@python/windows-team) rather than people.

[CAM-Gerlach]

That should be fairly straightforward, but the disadvantage is that its not machine-parsable. However, we could always still move the table sources to CSVs in the PEPs repo at any point, with no further changes needed over here.

[brettcannon]

Since this can be done as one atomic component of this migration, I could open a separate issue to cover it if desired, assuming people (e.g. @brettcannon ) agree.

I don't have an opinion (sorry, been sick, so still recovering).

[CAM-Gerlach]

Hope you feel better soon @brettcannon ! Best wishes for a speedy recovery.