-
-
Notifications
You must be signed in to change notification settings - Fork 568
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
Add CODEOWNERS #3591
Add CODEOWNERS #3591
Conversation
@brosaplanella, @Saransh-cpp, @agriyakhetarpal This is from our discussion in Slack. I set up the simplest code owners file. Making it works requires settings, so we would have to merge this PR, then do some additional testing when the settings are changed. Not sure how the maintainers feel about being pinged for each PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, thanks @kratman! I would like to note that I am not sure how I feel about an entire team getting tagged on new PRs. In my experience, there is a lot of noise in my GitHub notifications despite the fact that I watch repositories selectively... is there a workaround? I have seen other repositories and teams work with CODEOWNERS without automatic review requests: they show up in a tooltip instead with the words "@user
requested a review from a team as a code owner" – does that require GitHub Enterprise?
@agriyakhetarpal I have only worked on a single project that used CODEOWNERS. I was not admin for that repo, so I do not know how configuring notifications works with it. I know a bunch of people who setup custom email filters to handle github notifications. I put my notification/watch settings pretty high for projects I work on, but I know it annoys some people. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this, @kratman! I'll streamline this in the upcoming days to avoid sending notifications to everyone on every PR. I'll probably push to this branch itself.
Seems like that is a lot of fine grained control that needs to be edited and maintained over time. I did the one line version to keep it simple. Do we really need to restrict certain modules to specific users rather than just the team as a whole? I would hope all maintainers can be trusted with the entire codebase. |
Ended up working on this, haha! @pybamm-team/maintainers please go through the file and make suggestions / changes. @rtimms @priyanshuone6 I could not find your response in the "maintainer areas" form floated a while back. Please let me know if there are any folders that you are comfortable maintaining, or feel free to add yourself to the file. Edit: I cannot add maintainer trainees to the file as they do not have write access to pybamm. I'll look into the workflow permissions. |
I don't think they should be in there. The original purpose was to let the trainees get more access while still restricting what they can do with the code. Once a basic code owners file is in place the trainees can safely have their rights elevated. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #3591 +/- ##
========================================
Coverage 99.59% 99.59%
========================================
Files 258 258
Lines 20811 20823 +12
========================================
+ Hits 20726 20738 +12
Misses 85 85 ☔ View full report in Codecov by Sentry. |
The best option would be to give write permission to trainees who are about to transition to the maintainer status, as suggested by @brosaplanella. |
It seems like half the maintainers would get notified with this option as well. That is sort of why I was pushing for the simpler solution. |
Unrelated to the general discussion here, but should we move In #3596 I moved |
For CI/CD, benchmarks, scripts, and files in the root directory
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Saransh Chopra <saransh0701@gmail.com>
Co-authored-by: Agriya Khetarpal <74401230+agriyakhetarpal@users.noreply.github.com>
@Saransh-cpp Since #3641 is stalled, can we merge this so it can be tested and update it later? |
Co-authored-by: Saransh Chopra <saransh0701@gmail.com>
Let's wait for a couple of days for the remaining approvals from SC. |
@tinosulzer @brosaplanella @martinjrobins |
* Adding a basic codeowners file * style: pre-commit fixes * Refine CODEOWNERS * fix CODEOWNERS * add rtimms to CODEOWNERS * Remove /pybamm/step * Alphabetical order * Add @agriyakhetarpal to CODEOWNERS For CI/CD, benchmarks, scripts, and files in the root directory * Add self to code owners * Add Arjxn-py * Update .github/CODEOWNERS Co-authored-by: Saransh Chopra <saransh0701@gmail.com> * Update .github/CODEOWNERS Co-authored-by: Agriya Khetarpal <74401230+agriyakhetarpal@users.noreply.github.com> * style: pre-commit fixes * Update .github/CODEOWNERS * style: pre-commit fixes * Update .github/CODEOWNERS Co-authored-by: Saransh Chopra <saransh0701@gmail.com> --------- Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Saransh Chopra <saransh0701@gmail.com> Co-authored-by: Robert Timms <robertwtimms@gmail.com> Co-authored-by: Agriya Khetarpal <74401230+agriyakhetarpal@users.noreply.github.com>
Description
Change
Code owners are now specified in
.github/CODEOWNERS
and can be configured as required reviewers. This can help make it easier for maintainer-trainees to help with the project maintenance. The code owners can be required to approve pull requests, but the trainees can be granted write permission (merge approved PRs, trigger workflow runs, etc). This will make the trainees more involved in the process.Side effects
All members of the pybamm-team/maintainers group will be requested to review on new PRs. This can be avoided by making PRs drafts. The review requests happen only when a PR is marked as ready for review.
Next steps
In order for this to work properly some settings need to be adjusted by a maintainer.
The maintainer-trainees group should have permissions upgraded to
write
access. This should let us merge approved PRs and trigger workflows.The following four options should be enabled in the repo after this PR is merged. These settings will prevent non-code owners from merging code that is not approved by a code owner. Dismissing stale reviews prevents changes being pushed post-review.
Key checklist:
$ pre-commit run
(or$ nox -s pre-commit
) (see CONTRIBUTING.md for how to set this up to run automatically when committing locally, in just two lines of code)$ python run-tests.py --all
(or$ nox -s tests
)$ python run-tests.py --doctest
(or$ nox -s doctests
)You can run integration tests, unit tests, and doctests together at once, using
$ python run-tests.py --quick
(or$ nox -s quick
).Further checks: