Improve notifications by making better use of standard headers

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

I follow gitlab email notifications for a couple of projects and often have a hard time to distinguish urgent and interesting messages from the bulk of irrelevant ones. I often do not have the time to open all unread messages immediately, but would like to be able to distinguish the most likely relevant ones already from a summary view of the mailbox.

In contrast, on mailing lists (even high-volume ones) identifying relevant content at a glance is easier. This is because mailing list messages make a better use of standard email headers to convey "metadata". I believe that gitlab notifications could be improved by emulating this behavior.

Here are some concrete ideas:

• The notification subjects could indicate the type of action that triggered them. For example instead of all messages for a certain issue having the same subject Re: kwant | Suggestion for a little fix in the documentation (#295) we could have: kwant | #295 new discussion (Suggestion for a little fix in the documentation) or kwant | #295 closed (Suggestion for a little fix in the documentation). This topic is already raised in gitlab-ce#29727.

• Discussions in gitlab have a two-level-deep thread structure (top-level comments and discussions with replies). That structure should be reproduced in the threading of the notifications (using In-Reply-To:). This way, I can immediately see if someone replied to a discussion that I marked because I am interested in.

• Currently, all messages have a To: <my email> header. Cc: is not used. Gitlab could set these headers differently depending on how direct the notification is. In a reply to a discussion that I participate in or when my username is mentioned using the @ syntax, my email could be in To:. In other cases, it could appear only in Cc:. One could even consider a third lower level of implication for messages in MRs/issues where I haven't been involved in any way. Such messages could avoid mentioning my email address both in To: and Cc:.