Personally, I really like the specific suggestion that kipod describes above.

Note: This was also discussed at https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Archive_5#Proposal_-_Notifications_delivered (with a few tangents and misunderstandings and alternatives).

What may not be clear from the description is that the main issue here is over ping and mention notifications. These can be troublesome if they fail, and they often do fail for a variety of reasons. Often, it is failure on the part of the pinger meet all the requirements, but sometimes it is for inexplicable reasons, There is currently a discussion of the latter at Wikipedia Village Pump which will eventually be archived [https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_133 here] (probably, or maybe https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29/Archive_133 here). Whatever the reasons for the delivery failure, the sender really needs some kind of confirmation that the notification has been sent.

Here is an attempted ping that was missed today by my notifications. The user did nothing obviously wrong to cause the ping to be missed. There is plenty of anecdotal evidence that this is happening regularly to other users.

Don't forget to include the number of users, which cannot be pinged, because they have pings disabled:
{{ping|Alice|Bob|Carol|Dafne}} => 2 editors were notified; Bob and Dafne have disabled mention notifiactions.

I think there should be a permanent record of the ping being sent in the notifications log. It is very easy to miss the transient "your edit was saved" message and one might only start thinking about missed pings after there is no reaction to one's post.

Good idea, Spinningspark. I would append it to the edit summary instead to associate it with the edit and make it publicly visible.

In T68078#978741, @petr.matas wrote:

Don't forget to include the number of users, which cannot be pinged, because they have pings disabled:
{{ping|Alice|Bob|Carol|Dafne}} => 2 editors were notified; Bob and Dafne have disabled mention notifiactions.

I believe this preference is private (like most preferences).

Oops, then we should write
{{ping|Alice|Bob|Carol|Dafne}} => 4 editors were mentioned
to avoid misleading reports on suppressed notifications.

Note: This was mentioned and endorsed recently, in https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#Ping_log

In T68078#984442, @Mattflaschen wrote:

In T68078#978741, @petr.matas wrote:

Don't forget to include the number of users, which cannot be pinged, because they have pings disabled:
{{ping|Alice|Bob|Carol|Dafne}} => 2 editors were notified; Bob and Dafne have disabled mention notifiactions.

I believe this preference is private (like most preferences).

i do not think this is a real consideration.
to draw an analogy: a user can either allow on disallow incoming emails from other users.
on the face of it, this is a "preference" and should be private, but in reality, it's exposed (the user page does or does not have an "email this user" link).

IMO, willingness to receive pings is analogous to willingness to receive emails, and exposing it (by telling me or not telling me that "one user was pinged" or "N users were pinged") should not be a problem.

peace.

It is, in any case, quite perverse to want to keep secret that one does not receive communication by a particular method and have people uselessly try and make contact that way. It is a bit like having one's house phone removed because it is desired not to have communication directed to one's house, but then to insist the number stays in the phone book so no one knows the phone has been removed.

In T68078#1162988, @Kipod wrote:

IMO, willingness to receive pings is analogous to willingness to receive emails, and exposing it (by telling me or not telling me that "one user was pinged" or "N users were pinged") should not be a problem.

There are many web sites that allow you to mute emails or notifications and deliberately do not inform the sender:

• Gmail Mute
• App.net: Mute
• Facebook: Unfollow
• Twitter: Mute

This is actually a more mild version of the feature. Someone is just choosing not to be notified when someone links to their username (and yes, that means they may miss some stuff). They still see all content (if they go there) and see anything posted directly on their talk page (or emailed, if they have user->user email enabled).

Also, "Talk page message" is a required notification type on the web, so you always have the option to directly post on someone's user talk page if it's important.

Could it be implemented in a way that when the user presses "preview" it'll show up under the edit box "This edit will send notifications to User:AAA, User:BBB, ... like the edit summary does? That way people don't have to guess if it will work and don't have to hit send to see if they actually sent. They'll know before save is pressed (assuming they press preview which I'm guessing they would do if it would help them ensure important notifications are sent out). Also, it could send them a notification too so they know if they got one, everyone else probably did too.

From reading the comments, it seems like this is just a work-around the fact that currently mention notifications have a lot of non-obvious requirements that are easy to get wrong.

Another ongoing discussion about this, at https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications#Why_didn.27t_it_work.3F

Some people at the german wikipedia rated this as very useful, because there are often unsure, if a notification is displayed, if they tried to ping a user. Can someone of the collaboration team look at this, if this is really "low"? At a community survey at dewiki there are not few people supporting this: https://de.wikipedia.org/wiki/Wikipedia:Umfragen/Technische_W%C3%BCnsche_2015/Echo-Benachrichtigungen#Bei_Speichern_Hinweis_.C3.BCber_abgegebene_Benachrichtigungen.

I think there are several aspects to consider here:

• Support for mentioning. Some of the issues described are related to mentions being plain text elements (e.g. misspelling of the mentioned editor's username) without specific support for creating and representing them. Support such as auto-completing usernames, making it easy to select common users relevant to the context and representing the mentions in a way that users can check what they are about will not only facilitate input but provide confirmation feedback. For example, Flow supports several of these strategies: when adding a mention, initial suggestions are based on users that participated in the current conversation (making it hard to select a different user with a similar name), auto-completion is used to search for any username, and keyboard shortcuts (typing "@") are available to support keyboard-only scenarios.
• Tracking user actions. From a communication perspective, it makes sense to have some access to the messages you send, not only those you receive. This can take many forms (e.g., a section on the user page where I can view my interactions with her, a specific sent" section in the notifications page, etc.) and we need to consider this scenario in combination with other related cases (e.g., the thanks you sent, the replies you made, etc.). In any case, I think it makes sense to have access to what you send but not to what others receive for the privacy reasons discussed above.

+1 for this being a significant and persistent issue. The fact that you can't add a ping to an existing chunk of text is a very easy constraint to miss.
+1 for previews indicating whether the save will trigger pings. It vastly reduces the risk of trying to ping and not realizing you failed, and if a ping attempt is failing you very much want to fix it during the preview phase. Adding a new edit to send a ping after ping-fail can get a little messy.

I'm skeptical that there's a real privacy issue regarding disabled notifications, but reporting "mentions" that ping-qualify seems sufficient.

@Alsee:
+1 generally

I'm skeptical that there's a real privacy issue regarding disabled notifications, but reporting "mentions" that ping-qualify seems sufficient.

+1 Yes, if there is really a privacy issue, it could anyway nevertheless theoretically be displayed "mentioned".

The WMDE-TechWish has worked on mention success and failure notifications in the past month (see T139962: When saving, be informed about mentions you sent (#9)).
Due to performance reasons we could not implement it as part of the "your edit was saved" message, but as an opt-in notification feature (see also T139962#2579953).
The feature to receive notifications whenever notifications could be sent and the feature to receive notifications whenever notifications could not be sent can currently be tested on test.wikipedia.org and we are looking forward to feedback!

Based on comments elsewhere, it appears that the mention information isn't available until about 1/3 of a second after the "your edit was saved" message is sent. Could we send the "saved" message, leave the connection open, and send the mention results when they become available? This should visibly update the screen even if there are zero mentions.

Related question, would mention information be available on a preview?

In T68078#2581732, @Alsee wrote:

Based on comments elsewhere, it appears that the mention information isn't available until about 1/3 of a second after the "your edit was saved" message is sent. Could we send the "saved" message, leave the connection open, and send the mention results when they become available? This should visibly update the screen even if there are zero mentions.

Hmm, maybe? But the mention parsing goes through a few layers of deferrals, so I don't know how feasible this is.

Related question, would mention information be available on a preview?

Interesting idea! I think there might be deferral issues with that too, and I don't know if the mention parsing code likes dealing with edits that don't actually exist (i.e. haven't been saved yet and may never be saved), but I like that idea.

In T68078#2584419, @Catrope wrote:

Related question, would mention information be available on a preview?

Interesting idea! I think there might be deferral issues with that too, and I don't know if the mention parsing code likes dealing with edits that don't actually exist (i.e. haven't been saved yet and may never be saved), but I like that idea.

Clearly, performance still needs to be carefully considered though. Many people preview often as well (maybe more often than saves depending on the person).

as far as i'm concerned, closing T139623 is a good enough implementation of this feature, and the ticket can and should be closed.

peace.

@Kipod, I strongly disagree.

While I'm sure somebody will be happy with the notifications version, for myself and I'm sure most people, the notifications version has no value. It's not a usable option.

There are two non-options for using the notification version. Option one: you work as normal, let the notifications pile up, and only check them occasionally. That doesn't work because humans cannot realistically recall every mention they tried to send that day. It's particularly unrealistic to spot a notification-that-doesn't-exist (which should have been there). Option two: After each and every message, stop and do an extra step to fiddle with the notification panel. And 99% of the time, it's a waste of time showing you what you expected. That's not a sustainable pattern.

And especially significant, the people who most desperately need this would be new users. The fact that this is opt-in makes that a complete fail. I'm not enthusiastic for having notification-spam be opt-out, but it pretty much has to be opt-out if you want to help new users doing their first pings.

The desired functionality is that you just work as normal. You send a message, you save, and the confirmation information is just right there... exactly when&where it's relevant. This task should stay open, in the hope that some day someone will pick up and solve this valuable task.

I have removed the sentence about performance issues from the description. It seemed to imply that this enhancement is not going to happen, but in fact it is just a problem that has to be solved as part of this task. Some of you already dipped in it above.