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

RFE: default rules for new contributors #900

Open
keszybz opened this issue May 4, 2023 · 2 comments
Open

RFE: default rules for new contributors #900

keszybz opened this issue May 4, 2023 · 2 comments
Labels
enhancement next phase Will be done in the next phase of development

Comments

@keszybz
Copy link

keszybz commented May 4, 2023

Based on the discussion on fedora-devel: https://lists.fedoraproject.org/archives/list/[email protected]/message/DQRB4O6T4WPKRZDB5TKAXXUJMVCWGA75/

New users might be fully unaware that FMN is active, and unless they discover it by accident or going through some contributor docs, never use it. If they get at least some notifications, they can follow the link in the footer of the message and figure out if they want to have different rules.

Please consider creating some default set of rules that send a narrow set of notifications to users.

Additional points from the discussion:

  • the old FMN is still running, so we'll need to wait until we turn it off so that people don't get double
    notifications

For new users, maybe add them to new FMN only, and completely skip the old one? Having them set up there for ~1 year is not very useful.

  • we could add a default rule such as "my actions" for new users, but users are only registering their email at
    account creation time, FMN won't know about Matrix or IRC at that point
  • what about users who add a matrix / irc address later? Should it update the default rule? But only for users
    who recently created an account?

Would it be possible to have rules about Matrix or IRC independently of whether a target is configured? It would also be nicer to users, who may want to e.g. temporarily drop an IRC nick without losing their config. This would completely sidestep the issue how to update rules when delivery target is added or removed.

  • some important apps are not using FMN, such as Bohdi, and external applications. I'm afraid we may spam new users with duplicate notifications that they do not expect.

I don't think duplicate notifications are so bad. Users may just turn off the one they don't like.

  • the FMN notifications are still a bit rough around the edges, I'd be more confident if we let the dust settle
    a little bit, and we sanitized duplicates and incomplete messages before we enable it for new users by default

Ack.

@keszybz
Copy link
Author

keszybz commented May 4, 2023

default most users to no rules, but have a default set for packagers.

Hmm, that's more complicated, but I don't think it's needed. If we had one default set of rules, people who are not packagers would simply never apply those rules. If at any point they join the group or get added to ACLs for a package, the rule would stop being dormant.

And it would work the other way: if a packager gets involved in some new area, they might start getting notifications without further work.

@voxik
Copy link

voxik commented Jan 4, 2024

  • the old FMN is still running, so we'll need to wait until we turn it off so that people don't get double
    notifications

For new users, maybe add them to new FMN only, and completely skip the old one? Having them set up there for ~1 year is not very useful.

Old FMN is not running anymore and the current experience is tragic. I am not able to tell what messages I am supposed to receive, but I generally don't receive messages I was used to receive.

@abompard abompard added the next phase Will be done in the next phase of development label Jan 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement next phase Will be done in the next phase of development
Projects
Status: Todo
Development

No branches or pull requests

3 participants