[Feature request] Notification option to only get notified on new tags or releases (unless issues / merge requests are subscribed)
Problem to solve
Currently there is no way to only get notifications on new tags/releases on Gitlab. I am often interested in projects that I see in various Git hosts, but not enough interested to get dozens of emails per day from them (which gets worse as more notifications are subscribed).
Sidney (Systems Administrator)?
Who will use this feature? If known, include any of the following: types of users (e.g. Developer), personas, or specific company roles (e.g. Release Manager). It's okay to write "Unknown" and fill this field in later. Personas can be found at https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/
two three use-cases coming to my mind are:
- F-Droid client
Gitlab CE itself
- Added ten minutes after opening the issue: Before I opened this issue I attempted to find the button I am requesting and set notifications as "Global". Now I see that I had gotten 22 emails from Gitlab between 18:34 and 19:06 (both times UTC+2). If I was self-hosting Gitlab CE, I would be interested in new releases/tags, but if there are 22 emails within half an hour, I would be overwhelmed very quickly.
Adding an option to notifications (or at least custom notifications) to allow getting notifications only from new releases/tags in order to not overwhelm interested parties with email flood.
Permissions and Security
What permissions are required to perform the described actions? Are they consistent with the existing permissions as documented for users, groups, and projects as appropriate? Is the proposed behavior consistent between the UI, API, and other access methods (e.g. email replies)?
I think being able to see the repository and being the user are enough.
Sorry, I am giving up trying to follow the issue template at this point, I think my request is very simple and doesn't fit these long complicated questions, but if I am wrong, please help me! Github also has this feature and I think it may even be my favourite feature of their service.
See the Feature Change Documentation Workflow https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html Add all known Documentation Requirements here, per https://docs.gitlab.com/ee/development/documentation/feature-change-workflow.html#documentation-requirements
What does success look like, and how can we measure that?
Define both the success metrics and acceptance criteria. Note that success metrics indicate the desired business outcomes, while acceptance criteria indicate when the solution is working correctly. If there is no way to measure success, link to an issue that will implement a way to measure this.