Special:Emailuser/Catrope would be another option for emailuser, although probably more semantical than useful.

How practical/desirable (technically-speaking) would it be to just associate them with a non-page? e.g. a group called "Other notifications" in the filters section of T115316: Better organisation of the Notification Page would probably be fine (in that I could access them if wanted, and ignore them otherwise). The eventual search functionality, should solve the rest of it.

Filtering by page is a reflection of our belief that most users think primarily about content, rather than process. So we've provided this content-focused approach to sorting messages.

The fact that it won't surface every message is interesting. I hadn't thought of that. But is it a flaw? That's to say, will users expect the page links to add up to a comprehensive view?

But is it a flaw? That's to say, will users expect the page links to add up to a comprehensive view?

Yes, I would want to (and previously have needed to) be able to access my old user-rights notifications, and it seems logical to want to be able to quickly access the list of people who've sent me an email before.
The single welcome notification at our homewiki is less important, but some people might want to find it again, without clicking back in the history 50 messages at a time.

In T137502#2370186, @Quiddity wrote:

How practical/desirable (technically-speaking) would it be to just associate them with a non-page? e.g. a group called "Other notifications" in the filters section of T115316: Better organisation of the Notification Page would probably be fine (in that I could access them if wanted, and ignore them otherwise). The eventual search functionality, should solve the rest of it.

That would be completely fine. In fact that's precisely my preferred solution, because of the hairiness with potentially missing user pages.

On wikis where a welcome system exists with a nominative system (detailed on T130356), welcome should be associated to the welcomer user page.

According to the examples it seems that the notifications not associated with a specific page are very connected to the current user.

In T129366, there is a special entry labelled as the user ("Cronopio" in the example) that was intended to represent the notifications associated with the user page and user talk page. I think this filter can be used with the non-page notifications.

Instead of creating a specific filter for them, the "user" filter can be used for user (talk) pages and notifications without associated page. In this way, we avoid creating an additional entry that may generate confusion.

Yes, I would want to (and previously have needed to) be able to access my old user-rights notifications, and it seems logical to want to be able to quickly access the list of people who've sent me an email before.

It's worth noting that the filters described in T129366 are intended to provide a cross-wiki view of the pending items (i.e., which new itms I got and what I should focus on?), not for archival exploration (i.e., did Ludmilla gave me admin rights last month?). The later may be better supported by search in the future.

It looks like we're closing in on a consensus solution, which is to associate the following notifications with the user page:

• welcome
• user-rights

the following with the sender's user page:

• emailuser

The following with the Welcome page "On wikis where a welcome system exists with a nominative system (detailed on T130356)"

• Welcome

Did I miss anything?

But what about @Catrope's observation that "this probably won't work too well"? Have we answered these concerns?

However, this probably won't work too well, because the user's user page (or the sender's user page, in the emailuser case) may not exist. While we can associate notifications with nonexistent pages, we don't usually do that because it doesn't make much sense, and we are not able to filter by such pages. If we only associate with the user page if it exists (or even if we don't, but notifs associated with nonexistent user pages aren't findable through the user page filter), that may be confusing for the user, especially because their user page probably won't exist on wikis they don't frequent.

(Don't even anonymous users have a user page? Can't we use that?)

If we use the editor's own userpage for some, I think we should do that for all of these? As Pau says, "we avoid creating an additional entry that may generate confusion".
E.g. the individual emailuser notification themselves will already link to the sender's userpage.

In T137502#2380495, @jmatazzoni wrote:

(Don't even anonymous users have a user page? Can't we use that?)

Anonymous (unregistered) users currently do not get Echo Notifications at all. They only get the old Orange Bar of Doom (full-screen-width orange message box), and that is if and only if someone edits their user talk page.
There is a task to investigate giving Echo Notifications to unregistered accounts, at T58828: Provide access to Notifications for anonymous users, but it's complicated. (Because many people can share a single IP (sometimes a whole country!), and because a single user can frequently change IPs (e.g. roaming mobile, e.g. dynamic IPs)).
There is a userpage associated with each IP, but (at least on enwiki) it is rarely used, and not encouraged to be used.

In T137502#2380495, @jmatazzoni wrote:

But what about @Catrope's observation that "this probably won't work too well"? Have we answered these concerns?

The problem is that we can't associate notifications with nonexistent pages. Or, more accurately: we can associate notifications with nonexistent pages, but we can't then search for them by page, so it seems like a bad idea to do that. It would be weird for some people to have one experience and other people a different one, especially if your experience changes when you create your user page (or when someone who sends you email creates their user page!), and then only for notifications that occurred after the user page was created.

(Don't even anonymous users have a user page? Can't we use that?)

Anons usually don't. Registered users often do, but not nearly always. User pages are just pages, they don't exist until somebody creates them. If you are a new user, you start out not having a user page. If you are on a wiki that's not your home wiki, you also initially won't have a user page (your global user page will be shown instead, but that's not enough for our purposes here).

What I think we have to do is associate these notification types with "no page", as we already do currently (and we'd probably want to clean up user-rights notifications that were associated with the main page until recently). Then we could either add a "No page" item at the bottom of the list, or group all these notifications in with the user page (so that "user page" really means "notifs associated with my user page, or my user talk page, or with no page").

Then we could either add a "No page" item at the bottom of the list, or group all these notifications in with the user page

For notifications of this kind my preferred option is to keep them under the "user" group. A notification such as Welcome seems less surprising to be found associated with your user than in a "no page" group which requires an understanding of the internals of the system.

Full list of notification types that are page-less:

• welcome
• emailuser
• user-rights
• thank-you-edit (once it stops defying the laws of nature and we turn it back on)
• cx-{first,tenth,hundredth}-translation
• cx-suggestions-available
• unsubscribe-bouncehandler (sent when we stopped sending you emails because they bounced too often)
• gather-hide (but Gather's been undeployed, so we don't care)
• EducationProgram-related notifications about you having been added to a course in a certain role (only in rare cases, probably a bug)

These all seem reasonably user-related, so I think putting them in the "user" group is OK.

In T137502#2393610, @Catrope wrote:

(and we'd probably want to clean up user-rights notifications that were associated with the main page until recently).

I just did this.

OK then, it sounds like we have a new plan. I think Roan's and Pau both agree that the following will be associated with the user page, which seems reasonable to me.

List of notifications to add to the user page:

• welcome
• emailuser
• user-rights
• thank-you-edit (once it stops defying the laws of nature and we turn it back on)
• cx-{first,tenth,hundredth}-translation
• cx-suggestions-available
• unsubscribe-bouncehandler (sent when we stopped sending you emails because they bounced too often)
• gather-hide (but Gather's been undeployed, so we don't care)
• EducationProgram-related notifications about you having been added to a course in a certain role (only in rare cases, probably a bug)

I'm moving this to RFP, unless someone says no.

Change 295591 had a related patch set uploaded (by Catrope):
[WIP] Implement subject talk and null user page grouping in the API

https://gerrit.wikimedia.org/r/295591

@Pginer-WMF @jmatazzoni How does this look?

In T137502#2409862, @Catrope wrote:

@Pginer-WMF @jmatazzoni How does this look?

Looks good. A missing aspect is that we were considering giving the current user group more priority by placing it on top, since checking the pending messages of your talk page seems to be a high priority from what we heard from users. In any case, this can be a separate adjustment since it's not critical.

Change 295591 merged by jenkins-bot:
Implement subject talk and null user page grouping

https://gerrit.wikimedia.org/r/295591

Presently, in betalbs, pageless notifications grouped in wiki title. Clicking on the pageless notifications will redirect to various page - e.g. user right notification redirects to https://en.wikipedia.beta.wmflabs.org/wiki/Special:ListGroupRights, email user does not redirect to anything; 'welcome' redirects to Welcome page.
The screenshot with pageless notifications grouped under wiki name

Change 304873 had a related patch set uploaded (by Catrope):
Follow-up 4e64643eb: Count pageless notifications when counting pageless notifications

https://gerrit.wikimedia.org/r/304873

Change 304873 merged by jenkins-bot:
Follow-up 4e64643eb: Count pageless notifications when counting pageless notifications

https://gerrit.wikimedia.org/r/304873

Re-checked - after the fix https://gerrit.wikimedia.org/r/304873.

The following notification types were checked:
emailuser
welcome
user-rights
thank-you-edit
cx-first-translation
ep-campus-add-notification
ep-course-talk-notification
ep-instructor-add-notification
ep-online-add-notification
ep-student-add-notification

The screenshots show how page-less notifications will be associated with pages.

• user talk page Notification types is associated with the following type of notifications: emailuser (in the the second screenshot)

welcome
user-rights
thank-you-edit
cx-first-translation

• thank-you-edit is associated with the page on which the first (etc)edits occurred.

• ep-course-talk-notification (not page-less) is associated with Education Program talk page e.g. https://en.wikipedia.beta.wmflabs.org/wiki/Education_Program_talk:Bar1/Bar1_Course_1_(Spring)