Please make it easier to distinguish email notifications by subject and within discussions

• Email notifications are hard to distinguish by their subject. Currently the only way to distinguish between an issue and a merge request related notification is the “(#” or “(!” in the subject line. However, it is a the end of the subject line making it hard to find for long issue names. A suggestion would be to prefix the subject with IS and MR or something similar.

• Email notifications indicating new comments only contain information about the comment. This makes it hard to follow a larger discussion in context of an issue or merge request. Adding information about the the user and time when he/she added the comment could improve this

Related issue: https://gitlab.com/gitlab-org/gitlab-ce/issues/27299

@schlauch Thanks for the proposal.

@dimitrieh What do you think? Could we be doing a better job of separating email notifications concerning different types of resources in GitLab? I've gotten used to searching the subject for a # or a ! but I could see how it could be confusing

added 874211 19492 gitlab-foss405125 gitlab-foss14213 notifications in GitLab FOSS labels

Thanks for looking into this! This issue gitlab-ee#1954 is related to this. I accidently put it into the gitlab-ee issue tracker.

changed title from Please make it easier to distinguish email notifications by subject to Please make it easier to distinguish email notifications by subject and within discussions

I added the aspect of "discussions" again as I think it is an important point.

Any ideas on this issue?

@sarrahvesselov I feel like this one needs some UX in GitLab FOSS input. Thank you!

Thanks for the ping @markglenfletcher. My first step was to look at my inbox. Here is what I see:

Two things jump out at me here. One, the 'View Issue' and 'View Merge Request' helps to differentiate between the two email types. Two, the ! and # are difficult to see and often get pushed to the end of the subject.

Moving the ! and # to the beginning of the email subject line will ensure that it is always seen. I don't believe adding IS or MR will be more effective.

Adding information about the the user and time when he/she added the comment could improve this

I can agree with this.

@sarrahvesselov: I fear that additionally depends on your email client. We are still using Outlook and in this case I miss some of the extra information like the "View Issue" link.

Excellent point @schlauch. Do you think moving the issue / mr # to the beginning of the subject line will be sufficient to help identify them better?

Also, thoughts on this related issue https://gitlab.com/gitlab-org/gitlab-ce/issues/27299 ?

@sarrahvesselov: This would be a step forward for my specific case as you can identify the type directly by the subject. The notification type is really interesting. E.g., a ready-to-review merge request might have a higher priority than a commit in a branch. As this depends on the specific context, I think it could be really useful to make it easier to distinguish different notification events already by the email subject (as suggested in gitlab-foss#27299 (moved)).

Excellent @schlauch. We will handle moving the reference # up in the subject line here. Please add your thoughts and support to gitlab-foss#27299 (moved) if you have not already.

@markglenfletcher, @victorwu is still away so I am not sure how quickly this can get implemented. Thoughts on who else to approach? I have assigned myself to it so that I can keep track of the issue.

assigned to @sarrahvesselov

On a related note, I seem to remember the browser title being changed to display the issue reference number first (in the past) and this was reverted because with several tabs open all that was displayed was the number. In projects with a large number of issues the reference number becomes less of an identifier and the issue/mr title is actually more useful. I'm unsure whether this would have the same effect in an email client.

I think that @smcgivern would be the best person to involve in the conversation if Victor is away.

Yes, we did this in the browser's title bar, and people hated it: https://gitlab.com/gitlab-org/gitlab-ce/issues/21179 / https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6503 / https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/6983

For me, I don't really care about issue numbers, so I'm not sure I'm the right person to comment on this, but I think this would be a weird change:

1. If we add it right at the beginning of the title, then it's before the project name, and we should use the full reference instead gitlab-org/gitlab-ce#29727, but then we probably don't need the project name as well, even though the reference is less friendly.
2. If we add it after the project name, then there is this odd combination of symbols in the middle: Re: GitLab Community Edition | #29727 Please make it easier to distinguish email notifications by subject and within discussions, and that doesn't match the title on the issue page itself.
3. The actual request isn't to expose the number - I don't think even @schlauch cares about the number, just about what the email is about.

Given that gitlab-foss#27299 (moved) is apparently a good idea, and that does not change the email's subject header at all, would it not be possible for you to filter / tag by header already, @schlauch? We already provide an X-GitLab-Issue-ID header for issues, and X-GitLab-MergeRequest-ID header for MRs, etc.

Adding information about the the user and time when he/she added the comment could improve this

@schlauch I'm sorry, I don't understand this. The user's name is the sender's name of the email, which I see visible in your screenshot. Would you want that in the subject as well? That seems redundant.

1. You are right. I do not care about the ID but just the notification type. Your suggestion with filtering via the mail headers is fine for me. But it was not so obivious from the documentation. In addition, in Outlook 2010, it takes you a while to find the right options. However, I think we can provide some additional docs for our users to clarify this. Thus, we should just leave the subject header as it is.

2. The sender email address seems to be a problem with our GitLab EE instance configuration. In that case, emails are sent from a genreric email account. Thus, we miss this information. Could you please give me a pointer to documentation which describes the setup?

(@smcgivern)

@schlauch thanks. We can certainly add documentation about these headers - good idea!

For 2, I'm not talking about the email address, but the sender name. We don't send it from someone's email address because we allow reply by email.

@smcgivern: for 2: I fear we run exactly into this problem here: https://social.technet.microsoft.com/Forums/office/en-US/3a911877-aaa1-44a9-babd-45ade7addc6b/outlook-2010-displays-the-from-friendly-name-from-ad-instead-of-from-an-email-header

• In case of an external email address it takes the "from" header from the email (as shown in my screenshot).
• In context of our GitLab instance, we use an internal email address which results into the problem that the email "from" header is ignored.

@schlauch oh, that is annoying

I think we could include the $username commented text that we have for discussion emails for 'regular' comments:

@smcgivern: Good idea! I would be great if you could do this.

You are right. I do not care about the ID but just the notification type. Your suggestion with filtering via the mail headers is fine for me. But it was not so obivious from the documentation. In addition, in Outlook 2010, it takes you a while to find the right options. However, I think we can provide some additional docs for our users to clarify this. Thus, we should just leave the subject header as it is.

I think we could include the $username commented text that we have for discussion emails for 'regular' comments

Fantastic, thanks for the input on this @smcgivern and @schlauch. Glad we could come to some easy conclusions here.

removed assignee

removed UX in GitLab FOSS label

@victorwu here's a small, helpful change

changed milestone to %Next 2-3 months in gitlab-foss

moved from gitlab-foss#29727 (moved)