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

Enhanced Level of PR Notifications #1088

Closed
scrasmussen opened this issue Sep 25, 2024 · 2 comments
Closed

Enhanced Level of PR Notifications #1088

scrasmussen opened this issue Sep 25, 2024 · 2 comments

Comments

@scrasmussen
Copy link
Member

scrasmussen commented Sep 25, 2024

Description

Sometimes PR notifications for CCPP-Physics get lost in the large amount of notification noise.

Solutions

Here are a list of possible solutions, depending on the preferred avenue for notification. All of these can be added to a Github action that will be performed when a PR is created.

  • comment action: add comment to PR to mention specific @foo-username
  • assign action: automatically assign @foo-username
  • email action: send special email every time a PR is created.
  • modify email setting to highlight specific message
  • more difficult but also more fun ways to do this, automatically send a slack message or tweet

Related to (optional)

This got brought up in Wednesday's CCPP physics management meeting on the behalf of @climbfuji. Does this issue accurately reflect this problem and what do you think of the possible solutions, @climbfuji?

@climbfuji
Copy link
Collaborator

My first reaction is that there's probably a misunderstanding of the word CODEOWNERS. I think that Github chose a very unfortunate name, since being listed as a codeowner is basically a good mechanism for being notified, requested to submit a review, and thereby signal to the repo managers (those with admin/maintainer privilege to merge code) that the code was reviewed and the changes are ok. If that file had a different name, this discussion might not even be needed. Any of the solutions listed above are (a) additional work compared to using a tool that's already out there, and (b) fail to give the repo managers a quick way to see if the folks who should be looking at the code changes did so.

@scrasmussen
Copy link
Member Author

Didn't realize the overarching issue is already being discussed in Issue #1078 and handled through PR #1086, closing this issue

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

No branches or pull requests

2 participants