feat: Fine-grained watch on repos #7254

Needs and benefits

I'd like to watch only some of the activity on a repo, in particular, releases and security issues. However, there's only a wholesale "watch" or "unwatch" button that leaves me with either needing to manually check on the project status, or possibly be drowned in a plethora of not too interesting messages on a busy repo. Having a more fine-grained watch functionality, similar to what Github has, would be very nice!

Feature Description

I'd like to have a more fine-grained repo "watch" functionality l ike the one found in Github.

Screenshots

No response

There was work regarding this. But until then: Do you mean forgejo security issues? There is a specific repo to inform about upcoming security releases: https://codeberg.org/forgejo/security-announcements/issues

In Github, I tend to subscribe to releases and security announcements. At first, this would be most relevant to the forgejo repo for me, but once I'd want to subscribe to more repos, that'd become relevant for those other repos as well.

This feature is on my radar for implementation. I assume that it interacts with #7461 -- the repo-level settings becoming a default of the notifications on an issue -- and so I'm not sure that these two issues are truly separate features.

It would be helpful if anyone interested in it could document their first-hand experience that makes them desire it, so that it can feed into an appropriate design that meets people's needs. There are many 👍, but few details, and I'm not inclined to just copy another system's design and assume it's the right fit for Forgejo users. 🙂

Here's mine:

• I watch forgejo/forgejo to be aware of things that I might be able to be helpful with, but haven't been pinged on.
• In my email, I filter out cascading-pr emails because these are never interesting.
• {{ user }} force-pushed the {{ branch }} from {{ commit }} to {{ commit }} emails are the most noisy emails that I wish I didn't receive. Ideally I'd receive these on a PR that I had reviewed, but no others -- and even there, I'd be OK with just receiving a follow-up "review requested" when someone is done a review-requested change.
• Most other repos that being part of the Contributors team grants access to (and therefore auto-watches) are low volume and, while I might not be involved with each change, I don't mind seeing them come through my inbox.

I'd like to have more fine-grained controls as right now, repo watching is just all or nothing. This is fine for low-traffic repos, but in ones where issues are active (be that be popular issues, automations, etc), I get notified about every single event. Even just ignoring the obvious "notification overload" problem, this has also caused issues with a particular forge's mailserver being blocked by my own provider (I use iCloud, so I can't control rules) for sending too many emails in a short period of time. Most of these emails were registering a vote, so they were just "yes" and "no" - I don't need to know about the individual comments on the issue, just the issue itself.

Also, some repos I just don't care about as much as others. For example, I'd like to watch the forgejo repo to be notified of new tagged releases, but don't really care about too much else. Meanwhile, this may be the complete opposite for another issue, an example being a repo of my own - I'd like to be notified of all activity (aside from things like pushes) rather than just a preset.

I would also like if notifications to third party endpoints (e.g. email) could be chosen individually of what is delivered to the forgejo inbox. I don't mind having a billion things in the notification inbox web UI because I can gradually work through those. But with email, i'm more likely to miss a notif or forget to mark it as done etc. I'm sure someone out there would find use for the inverse also.

One thing I like about Discourse's tracking/notification system is the ability to be notified of the first post in every new thread on a given category or tag, but not of subsequent posts, unless I subscribe to that thread.

In the context of a forge, that'd be equivalent to, say, be able to subscribe to notifications about any new issues opened or closed, but not about comments in them. Ideally, this would be filterable by label (e.g. bugs vs. feature requests), but even simple open/close notifications for issues (and PRs) would be nice already.

I too would very much like to be able to subscribe to releases. I maintain the FreeBSD Forgejo ports and need to be notified when a new release comes out, but watching this repository subjects me to a firehose of commits, issues, pull requests, and comments, when all I need is one or two notifications every few weeks.

#10598 did some significant progress but was closed. Nevertheless those interested in this feature should feel free to play with it locally, try to break it and pick up development / submit a new PR based on that one.

Should we consider implementing this in combination with #954 ?
I guess we should at least think about how those two things should work together.
So, e.g., there could be different ways of watching a Repo. Then a Team in an Org (or the Org itself) could set a default way of watching any Repo a member is added to.

In relation - yes, makes sense to consider how these should work. But the smaller separate PRs are the easier it is for reviewers, so don't put them into one 😅

Yes, yes, of course! Even bigger than this PR, please don't xD.

This could also be extended with a fine-grained setting for workflow failure mails.

I like GitHub's sensible default watch setting: "Participating and @ mentions"
As far as I understand it you get notified to all PRs and Issues you have subscribed to, been tagged or sent a message to.
That's what I like to use.

While #10598 implements them, I'm against a user setting for defining default notification behavior. Again, I like how GitHub does this: There are no user-wider notification settings dictating what should notify at all. There only are settings on how a notification should reach the user, e.g., via mail or the ui.
I believe these default notification settings could find a place in the teams settings.
What do you think?

@christopher-besch wrote in #7254 (comment):

I believe these default notification settings could find a place in the teams settings.

I don't think teams should be anyhow related to notifications settings. User should be in full control of notifications without hidden settings discoverable though confusion of something happening (being added to a repo).

Either not starting to watch anything when being added to a repo or a user-configurable default.

But you don't have to include such changes in a PR aiming to resolve this particular issue. The defaults of external events (org admin adding a user) can remain as is. This issue is mostly concerned about user's ability to manually watch or unwatch a specific repo unit.

User should be in full control of notifications

I agree but I'm not talking about whether someone is watching a repo or not. I'm just talking about the defaults that apply to new or newly accessible repos. And I'd really like a system as proposed in #954. #954 would mean notification settings either in the org or team settings. Personally, I prefer the org owner or system admin should choose a sensible default watch setting. When a user doesn't like that, she can change it for each repo. You disagree on this point, right, @0ko ?

But you don't have to include such changes in a PR

Yes, of course. Though, I think we should figure out a bigger vision before implementing anything. I feel adding little things one by one without a clear path ahead won't lead to a cohesive notification system.
I have to admit, I don't quite know where to start with all this. There's just so little to go by.

@christopher-besch wrote in #7254 (comment):

Personally, I prefer the org owner or system admin should choose a sensible default watch setting. When a user doesn't like that, she can change it for each repo. You disagree on this point, right, @0ko ?

I need to say, I'm on the side of @0ko . I as an user want to define my default notification settings. If I'm added to a team and get repos assigned I don't want to get spammed by notifications just because some team Admin decided it would be good when I receive a notification for everything.
And when I then need to go through each repo to "fix" the settings it just means work for me.

Thanks for the input, @Beowulf ! @fnetX I remember you to have some strong opinions on notifications. What would you like?

Also, I'd like to hear your opinion, @mahiso: should the default notification setting for new or newly accessible repos be in:

• Team settings for the org owner,
• Org settings for the org owner or
• User settings for the user?

Only in user settings. The user should have full control over it.

Okay, you all convinced me. Though, I still worry about #954. I propose this:

• The user can choose "Global Settings" or a combination of "Issue", "PR", "Release". Notice how there is no "Don't watch" option. That is realized by choosing a combination but then not selecting anything to be notified for.
• The user can set the "Global Settings" in her user settings (also a combination of "Issue", "PR", "Release").
• When migrating to this feature the Forgejo instance's user settings all select to be notified for everything.
• When migrating to this feature the Forgjeo instance's repo watch settings all select "Global Settings".
  #954 might become obsolete when the users choose "Global Settings" the way they like them. What do you think, @fnetX ?

If we want GitHub's behavior with only being notified for issues the user was mentioned in. We could make mentioned users auto-subscribe to those issues. That's something for a separate PR.

EDIT: I don't like the name "Global Settings" as these settings don't apply instance-wide. They apply to a single user. I haven't come up with a better name yet, though.

#issuecomment-9999606

@mahiso, no need to restrict where such preferences can be exposed. All that matters is that the user's preferences override all else.

As in all discussions about potentially federated preferences, observe WikiMedia's GlobalPreferences as an example: allowing organisations and repositories to define defaults can be sensible, when not every employee in an organisation wants to learn how to configure their own preferences to match that of their team's. However, the team shouldn't ever be able to override what that user wants; they should only set defaults, which the user can override.

it would also be useful to have a list of labels/keywords per repository that cause you to be subscribed to issues/PRs when those labels/keywords are applied (unless you previously unsubscribed to that issue/PR). so I think each issue/PR should have several different per-user states:

• explicitly unsubscribed so you don't ever get automatically subscribed to notifications
• explicitly subscribed
• default which automatically changes to explicitly subscribed when some event you're interested in happens. this should send you all messages in an issue/PR if you were automatically subscribed close to when the issue/PR was created -- for things like bots that automatically add labels/mentions.

teams/orgs should be able to set default lists of things people are interested in, e.g. forgejo could have a actions team that defaults to users in that team getting automatically subscribed whenever actions-specific labels are applied and maybe if someone mentions "forgejo actions" or something?
that way teams/orgs can configure some complicated list of labels to listen to and users joining those teams/orgs don't have to manually replicate that in their per-user settings.

@programmerjake, I believe that that's very similar to what GitLab does for their own repositories; they utilise bots to subscribe groups of users to specific labels. ¹

However, this would need to be an addition to the basic preferences.

Currently, there are the AutoWatchOnChanges and AutoWatchNewRepos settings in the app.ini. They configure if users should be made watchers of repos once they contribute to them in the first case and when the repo becomes accessible in the second case.

Do we need those settings? When we allow the user to choose whether to watch or not watch new repos I'd say that's enough. I'd like to remove those settings from the app.ini file and move them to the user settings. Having both is quite complex, I fear. I like simplicity.
However, I don't know if this could be a pain to migrate to. Would such a change break peoples' setup?

I have fully implemented and written tests for granular repo watching, see: #10927
I'm curious as to what you have to say!

Note that while it is not a perfect solution, it is already possible to follow a project's release with RSS (e.g. https://codeberg.org/forgejo/forgejo/releases.rss)

As a first step, #10927 seems great. But I hope the plan is to further expand the granularity down the road — for example, when I watch a repo for just issues, what level of activity in issues would I get subscribed to?

I'd like to be able to choose between various levels of "verbosity" for each category, rather than a binary all-or-nothing approach. For example:

• For issues: "everything" (including labeling, edits, etc.), "new comments", "only status changes" and "none";
• For PRs: "every commit" (even those done without PRs), "PR activity" (creation, merging, closing, comments), "PR status changes" (open/close/merge), and "none";
• For releases: and "all tags", "only releases" and "none".

I suppose this may call for a radio button or tri-state toggle (or button-set) for each category, instead of checkboxes, in a future implementation. Or perhaps we'd actually want to allow people to choose-and-pick their notification categories — e.g. say I'd like to get notified of labels added to issues, but not comment edits (or vice-versa). But that could make the subscription UI rather complex, warranting perhaps a separate "advanced notification subscriptions" page.

That said, this is already a great improvement over the current situation :)

@waldyrious the backend is very much extendible to more and more granular categories. My migration approaches are also easily adaptable for future categories.