It might be worth notifying those listed directly in the Experts Index to the existence of CODEOWNERS as a recent thread on python-dev surfaced that there are core developers unaware of it.
Label subscription maps nicely to the interests tables in the Index, but it the stdlib table does seem to match to CODEOWNERS in spirit. Being requested for review does not mean required and would have the same effect as auto-nosy. Although each developer may have their own meaning attached.
Its my understanding that a triager would have, in a perfect world, gone through and added the interested developer(s) to the PR. I see both @-mentions (nosy) and ârequested review fromâ (CODEOWNERS) on the PRs. Not having write access, I do not know which is easier for a triager.
At any rate, the more automation that can be applied here, the better as, in reality, there is never enough eyes to keep up with the influx of new issues/PRs.
I certainly didnât know it was something I was expected to update manually. And Iâm a little concerned about getting the match pattern right given the comments here that some of the existing lines are wrong
@-mentions requires actually making a comment on the PR with the mentions, which pings everyone subscribed in addition to the person mentioned, increases clutter, and is somewhat more effort, whereas simply requesting review is quicker, only pings the people requested and doesnât add an extra comment (though if the triager wants to actually say something, thatâs less of an issue). The UI and sorting is a little nicer and more tailored on GitHubâs end for the reviewer.
Of course, the great majority of experts index entries are for specific modules, which map directly to files/dirs in CODEOWNERS and thus could be easily automated without requiring manual triager effort to look up and tag the expert(s). But there certainly are still cases, like cross cutting themes and special circumstnaces, where manual triage is still helpful. On the other hand, it does mean they are tagged as soon as users mark the PR âready for reviewâ, rather than after an initial review by a traiger, so it could somewhat increase the number of pings experts get in some cases.
The key thing to understand is those two lists are in separate repos. Probably the closest you could come is some GHA that tries to open a PR on the other repo when the key file has been opened.
Or we can eliminate experts.rst and point people at CODEOWNERS. When I first added CODEOWNERS I think that idea was shot down due to some people not wanting to be tagged on reviews or not all groups tying into code cleanly, but it would simplify things.
Instead of eliminating one or the other, or letting them continue to duplicate one another, Iâd suggest focusing each on their respective unique strengths.
CODEOWNERS is a machine- and mostly-human readable means of listing the developers and maintainers of each specific module and sub-componet of the code and automating a number of triage processes and exposing that in the UI. The detailed listing of those, which comprises most of the line length of the current Experts Index, can be transferred there, for those core devs who are active and want to continue to share that responsibility, and exposed both through automation, reading at least mostly human-parsable file for those really interested, and potentially, if thereâs sufficient interest, through an autogenerated document (given the simple and consistent source format, and GitHub now offering full support for automatic validation and specific feedback on it).
Meanwhile, the remaining experts index could focus more specifically on the experts and core devs interested in the larger, cross-cutting and higher-level areas of focus, rather than getting bogged down with the maintainers of every module, which is likely more generally useful for interested contributors who want higher-level guidance on a contribution, as opposed to a detailed issue or PR review of an implementation (which would be handled by the automation above). Of course, it would still link to either the CODEOWNERS or a more human-focused file generated from it.
It might be possible to edit the first message to add mentions, similarly to what bedevere does when adding a link to the bpo issue, however Iâm not 100% sure that works. I think edited lines and re-evaluated and should trigger @mention notifications, but they wonât send emails to other subscribers. This is a bit tricky to test since it requires multiple accounts and itâs also affected by the âwatchâ settings and other things. There is also no way to see the list of subscribers afaik.
IOW, the CODEOWNERS file could replace the stdlib section (and the section could be removed from the expert index), but not the other sections. For the other sections, the only ways to automate subscriptions are:
Create even more labels people can subscribe to
Create GitHub teams and @mention the team
Have triagers directly @mention experts from the list
Note that in all cases we would have to rely on triagers to either add the right labels, or mentioning the teams/users. In addition, labels also allow external people to follow certain issues, whereas teams and direct mentions donât. The downside is that the more labels there are, the more difficult the triaging becomes.
I see that âAuthorâ account names on bugs.python. org (Iâm mangling the rest of the links here, as Iâm not allowed more that 2 per post) are mapped to GitHub account names (whenever avaialble?), e.g. on
bugs.python. org/issue47259#msg416997
(Author) rhettinger is mapped to (GitHub account) rhettinger on
github. com/python/cpython/issues/91415#issuecomment-1093947835
I donât see how to do this without e.g. GitHub access tokens for the GitHub
accounts you want to link. Did you use GitHubâs help here, not some standard tools?
The migration was done with GitHubâs help. When the issues were imported the comments were owned by âmannequinâ users with the same usernames as BPO. For members of the Python org on GitHub, the mannequin is associated with their account and becomes indistinguishable from other actions taken by that user. For everybody else it stays as a mannequin.
We worked with GitHub and used their Enterprise Cloud Importer to migrate data from bugs.python.org to GitHub Issues. This allowed us to map bpo users to their GitHub accounts, but only if they belonged to the python organization on GitHub (so only core devs could be mapped).
Thanks, yes, weâre also taking the route via Importer - first debugging it on a trial copy of GitHub Enterprise Server. Hopefully weâll be done in February.
