Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update/expand CPython CODEOWNERS #344

Open
aeros opened this issue Jul 27, 2019 · 3 comments
Open

Update/expand CPython CODEOWNERS #344

aeros opened this issue Jul 27, 2019 · 3 comments

Comments

@aeros
Copy link

aeros commented Jul 27, 2019

This is specific to CPython, but I figured that it would still be relevant to this repository since the issue directly involves the workflow. If necessary, I can move it somewhere else.

In the CPython repository, the CODEOWNERS file is primarily used for automatically adding reviewers to PRs based on the files involved in the PR. However, there are frequently PRs which end up without having anyone automatically assigned to reviewing them. This most regularly occurs with documentation related changes.

Also, there are a number of people on the experts list who are not included in the code owners in their respective areas of expertise. For BPO, the star next to their name denotes whether or not they should be assigned issues, if it is not present, they should only be added to the nosy list.

On GitHub though, being assigned to a PR as a reviewer is pretty much the equivalent of being added to a nosy list, as the PR can accept an indefinite number of reviewers and it does not require explicit approval from everyone assigned to the issue. As a result, I don't think it would be an issue to add any active core developers on the experts list as code owners to their areas of expertise in the repository.

For the documentation files specifically, I think it would be appropriate to at least add the documentation experts as code owners. Based on a conversation on discuss, it would also be helpful to add the related experts as code owners to documentation files involving their areas of expertise. For example: pganssle, an expert in datetime, would also be added as a code owner to Doc/library/datetime.rst.

The following conversation on discuss.python.org motivated the creation of this issue: https://discuss.python.org/t/proposal-create-bug-triage-team-on-github/992/56?u=aeros167

@brettcannon
Copy link
Member

This is a general issue of figuring out how best to maintain a system to make sure people get notified as appropriate. Right now it's split between the experts index for bugs.python.org and CODEOWNERS for GitHub PRs. Once the issues move over to GitHub then we may need to re-evaluate how to handle all of this. Personally, I would like all of this managed in a single file and anything else is auto-generated from the master file (i.e. CODEOWNERS has a way through comments to denote which modules people are signing up to maintain).

@aeros
Copy link
Author

aeros commented Jul 30, 2019

@brettcannon I recently opened up a PR on the devguide for creating a JSON to better store the experts index data. Zware and Mariatta recommended doing that so we could add the github names to the experts index, currently bpo relies on the table formatting in experts.rst for the nosy list functionality. The scripts would be updated to extract from the JSON so that it was no longer dependent on the tables on experts.rst

Could that JSON (or a different one) be used to store information for the GitHub codeowners, and then use a script to extract the data from the JSON to build the actual codeowners file? That might provide a way to store information on the maintainers of all the modules in one central location.

I'll be out of town for the next couple weeks, but if you think that might be a potentially viable solution, I can start working on it when I get back.

@brettcannon
Copy link
Member

@aeros167 possibly. It depends on how the automation is going to work to make sure there isn't any manual steps beyond updating a single point of data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants