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

Setting to disable email notifications of comments #3059

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

AndrewKvalheim
Copy link
Member

@AndrewKvalheim AndrewKvalheim commented Jun 18, 2022

Checklist

  • I have read the Contribution & Best practices Guide.
  • My branch is up-to-date with the upstream master branch.
  • The tests pass locally with my changes.
  • I have added tests that prove my fix is effective or that my feature works (if appropriate).
  • I have added necessary documentation (if appropriate).

Short description of what this resolves

SeaGL uses comments during a specific review process in which email notifications aren’t appropriate. Previously we’d simply disabled notifications by removing that code, but a runtime setting for this would be more convenient.

Changes proposed in this pull request

Add a new setting, defaulting to enabled:

  • E-Mails → Proposal → Send an email to all organizers and CfP team members when a comment is added?

Concerns

  • Is Proposal the right place to put this, or should there be a Comments tab?
  • This was the simplest solution to implement, but it might be preferable to instead allow more fine-grained control over which roles get notified, or to expose separate notification settings to each user.

@hennevogel
Copy link
Member

SeaGL uses comments heavily during a specific review process in which email notifications aren’t appropriate

Why? I mean comments are appropriate obviously, notifications are just helping people to not loose track. Can you explain?

@AndrewKvalheim
Copy link
Member Author

It’s been tedious to get an explanation but I think the review process is:

  1. Individually, each reviewer on their own time:
    1. For each proposal:
      1. Outside of OSEM, read a copy of only the title and abstract.
      2. Outside of OSEM, decide on a vote.
      3. Within OSEM, submit the vote and optionally comment to explain your decision.
  2. Collectively, all reviewers in a meeting:
    1. For each proposal:
      1. Within OSEM, read the entire proposal, including its votes and comments.

The reviewers avoid exposure to comments until after they’ve decided on their vote, and active notifications of comments work against that goal.

@hennevogel
Copy link
Member

The reviewers avoid exposure to comments until after they’ve decided on their vote, and active notifications of comments work against that goal.

We already have a setting for that "behavior". It's called Program.blind_voting. Instead of another configuration we should apply this to comments and sending emails about comments in Program.voting_period? too.

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

Successfully merging this pull request may close these issues.

2 participants