I had an initial pass at filling out "yes", "no", "unsure" for the table; I'll hand it over to @Niharika @KStoller-WMF @RHo to decide :)

How would this integrate with the preferences system? Would we provide some way to have different default preferences for temp and normal users, hook into the loading of preferences, or just hardcode it in Echo without directly interacting with notification preferences (maybe modify the Echo user locator)?

Leaving this decision into the trusted hands of @KStoller-WMF and @RHo.

Successful mentions and edit reverts are off by default. Temp users have no preferences so we'd have to set a non-default preference on account creation, which might be problematic because of user_properties table bloat.

In T333531#8777764, @Tgr wrote:

Successful mentions and edit reverts are off by default. Temp users have no preferences so we'd have to set a non-default preference on account creation, which might be problematic because of user_properties table bloat.

Just so I'm clear:
Given Temp users receive notifications AND they don't have access to adjust preferences,
Then it would be ideal for them to just keep whatever preferences are default because then we aren't adding as much to the user_properties table bloat.

Is that correct?

@KStoller-WMF correct.

We might end up with support for dynamic defaults in MediaWiki core (T321527) and then arbitrary settings for new users, temp users, autoconfirmed etc. will be possible without any impact on user_properties, but so far it's not on anybody's roadmap.

In T333531#8777883, @KStoller-WMF wrote:

In T333531#8777764, @Tgr wrote:

Successful mentions and edit reverts are off by default. Temp users have no preferences so we'd have to set a non-default preference on account creation, which might be problematic because of user_properties table bloat.

Just so I'm clear:
Given Temp users receive notifications AND they don't have access to adjust preferences,
Then it would be ideal for them to just keep whatever preferences are default because then we aren't adding as much to the user_properties table bloat.
Is that correct?

In T333531#8778414, @Tgr wrote:

@KStoller-WMF correct.
We might end up with support for dynamic defaults in MediaWiki core (T321527) and then arbitrary settings for new users, temp users, autoconfirmed etc. will be possible without any impact on user_properties, but so far it's not on anybody's roadmap.

Based on the ideal being that we don't adjust preferences, I've updated the task description adding column for what I believe to the the default prefs, and then for each row where the proposal was to have different defaults for temp accounts, a comment/discussion starter for whether the deviation is needed. Pasting below only ones where deviation has been suggested:

• It seems like we could easily have it all map to the default, with an exception of GrowthExperiments one - is it possible we can opt out temp accounts from GrowthExperiments so that even if this is default on, they would never trigger a notification?

• Another one which I am surprised about requesting difference from default is the Edit revert. Is there a compelling reason why we think it more important for temp than accounts to be notified in this case?

In T333531#8780399, @RHo wrote:

• It seems like we could easily have it all map to the default, with an exception of GrowthExperiments one - is it possible we can opt out temp accounts from GrowthExperiments so that even if this is default on, they would never trigger a notification?

Yeah, I think it should be straightforward.

In T333531#8780399, @RHo wrote:

• It seems like we could easily have it all map to the default, with an exception of GrowthExperiments one

Agreed, it seems to me that keeping the default for temp accounts seems fine (although admittedly I haven't audited the language of every single message).

In T333531#8780419, @Tgr wrote:

In T333531#8780399, @RHo wrote:

• It seems like we could easily have it all map to the default, with an exception of GrowthExperiments one - is it possible we can opt out temp accounts from GrowthExperiments so that even if this is default on, they would never trigger a notification?

Yeah, I think it should be straightforward.

Great!

@RHo - should I update this task to reflect the decision, and make a subtask for the Growth effort of disabling the Growth features notification for temp accounts?

In T333531#8780427, @KStoller-WMF wrote:

In T333531#8780399, @RHo wrote:

• It seems like we could easily have it all map to the default, with an exception of GrowthExperiments one

Agreed, it seems to me that keeping the default for temp accounts seems fine (although admittedly I haven't audited the language of every single message).

In T333531#8780419, @Tgr wrote:

In T333531#8780399, @RHo wrote:

• It seems like we could easily have it all map to the default, with an exception of GrowthExperiments one - is it possible we can opt out temp accounts from GrowthExperiments so that even if this is default on, they would never trigger a notification?

Yeah, I think it should be straightforward.

Great!

@RHo - should I update this task to reflect the decision, and make a subtask for the Growth effort of disabling the Growth features notification for temp accounts?

Yes please! We should also create a task to remove links to preferences from Notifications too thanks.

Then Failed mention would be a specific message? As a way to encourage users to create an account?

In T333531#8793962, @Trizek-WMF wrote:

Then Failed mention would be a specific message? As a way to encourage users to create an account?

https://en.wikipedia.org/wiki/Help:Notifications#Failed_mentions

As I understand it, all accounts should be able to mention temp accounts. Having this notification disabled by default simply means that temp accounts won't receive a notification if they attempt to mention someone and it isn't sent...

These notifications are sent when:

• trying to mention anonymous user or user that does not exist, or
• exceeding the limit of mentioned users in a single edit (currently 50).

Slightly unrelated, sorry!
I was reading the documentation on Mentions and I understand that Echo manages them and they are not part of a discussion tool or MediaWiki. I wanted to understand - apart from the usual link to the user's page (or the ping template) is there something different about mentions in how they'll be made for temporary users, or how they'll look once they've been posted?

In T333531#8803521, @Prtksxna wrote:

Slightly unrelated, sorry!
I was reading the documentation on Mentions and I understand that Echo manages them and they are not part of a discussion tool or MediaWiki. I wanted to understand - apart from the usual link to the user's page (or the ping template) is there something different about mentions in how they'll be made for temporary users, or how they'll look once they've been posted?

Hi @Prtksxna - afaict the mentions are three Alert notification types (Mention, Failed mention, Successful mention) that are triggered when a user mentions another user (Success/Fail) or is mentioned by another user on any page (Mention). The username would look the same as the Alert notification for both temp and standard accounts, but possibly we will change the avatar icon for whatever temp account user icon is determined where the user page link appears as a secondary action. I believe we should explore this as part of the UI modifications for temp account notifications (along with removing links to preferences).

Part of this task (or a subtask?) will be to QA that mentions to/from a temp account are being triggered correctly though, since from the help page you linked for example, it says that currently mentions to an anon account will fail.

Were those the questions you had about mentions, or am I missing something?

The username would look the same as the Alert notification for both temp and standard accounts, but possibly we will change the avatar icon for whatever temp account user icon is determined where the user page link appears as a secondary action. I believe we should explore this as part of the UI modifications for temp account notifications (along with removing links to preferences).

Thanks for the explanation. This makes a lot of sense.

Were those the questions you had about mentions, or am I missing something?

Just one more thing, does the actual mention like on a talk page or within a discussion tool look different from a normal link? Both for normal mentions now and temp users going forward. Is this something that Echo handles or is that a different piece of the puzzle?

In T333531#8806492, @Prtksxna wrote:

The username would look the same as the Alert notification for both temp and standard accounts, but possibly we will change the avatar icon for whatever temp account user icon is determined where the user page link appears as a secondary action. I believe we should explore this as part of the UI modifications for temp account notifications (along with removing links to preferences).

Thanks for the explanation. This makes a lot of sense.

Were those the questions you had about mentions, or am I missing something?

Just one more thing, does the actual mention like on a talk page or within a discussion tool look different from a normal link? Both for normal mentions now and temp users going forward. Is this something that Echo handles or is that a different piece of the puzzle?

Hi, I would not expect that to be the case but @kostajh can confirrm. Echo only handles detection of mentions and the generates the relevant alert notification accordingly. The mention itself would be whatever user links look like in the specific page.

The mention itself would be whatever user links look like in the specific page.

That's right. I've attached some screenshots, if it is helpfu:

Thank you so much both of you! Answers all my questions.

In T333531#8797874, @KStoller-WMF wrote:

In T333531#8793962, @Trizek-WMF wrote:

Then Failed mention would be a specific message? As a way to encourage users to create an account?

https://en.wikipedia.org/wiki/Help:Notifications#Failed_mentions

As I understand it, all accounts should be able to mention temp accounts. Having this notification disabled by default simply means that temp accounts won't receive a notification if they attempt to mention someone and it isn't sent...

These notifications are sent when:

• trying to mention anonymous user or user that does not exist, or
• exceeding the limit of mentioned users in a single edit (currently 50).

Mentions are so used that users forget the fact that they can't ping IPs. Providing mentions to temp account would be useful, we both agree on this.

My point is on the temp accounts side: I would not provide the ability to mention users to temps account, just to avoid harassment cases. If we provide a failed mention notification to temp account, I suggest telling them that they can't mention others and that they should create an account to be able to mention others.

In T333531#8820528, @Trizek-WMF wrote:

My point is on the temp accounts side: I would not provide the ability to mention users to temps account, just to avoid harassment cases. If we provide a failed mention notification to temp account, I suggest telling them that they can't mention others and that they should create an account to be able to mention others.

Thanks for the clarification!

I assume we should match the current IP editing functionality, which I believe allows IP editors to mention users, correct?

Pinging @Niharika in case you want to provide the AHT perspective.

Yeah, I don't think it makes sense to make temp users' communication ability less powerful than anon users'. It wouldn't be trivial, either - we would have to modify the behavior of the DiscussionTools and Flow mention tools, because it makes no sense to disallow mentioning but still provide an editing tool that gives the user the impression that they are about to ping someone.

In T333531#8821452, @KStoller-WMF wrote:

I assume we should match the current IP editing functionality, which I believe allows IP editors to mention users, correct?

IPs can't mention users.

In T333531#8824003, @Trizek-WMF wrote:

In T333531#8821452, @KStoller-WMF wrote:

I assume we should match the current IP editing functionality, which I believe allows IP editors to mention users, correct?

IPs can't mention users.

If the intention of the IP Masking project is to turn on Echo notifications as the one exception to the overall "same as IP editors" rule for MVP because the big selling point is to help editors communicate to unregistered editors, then it makes sense to have the default preferences including allowing mentions.

Thinking on the positive case, if a temp account leaves a message on an article talk page to a registered editor explaining why a change was made, isn't it a good thing for that registered editor to receive the mention ping so that they can respond?

In T333531#8824003, @Trizek-WMF wrote:

IPs can't mention users.

IPs can mention users, they just cannot be mentioned.

In T333531#8824466, @Tgr wrote:

IPs can mention users, they just cannot be mentioned.

🤔
Then, I learned something.

In T333531#8824080, @RHo wrote:

If the intention of the IP Masking project is to turn on Echo notifications as the one exception to the overall "same as IP editors" rule for MVP because the big selling point is to help editors communicate to unregistered editors, then it makes sense to have the default preferences including allowing mentions.

Thinking on the positive case, if a temp account leaves a message on an article talk page to a registered editor explaining why a change was made, isn't it a good thing for that registered editor to receive the mention ping so that they can respond?

I agree. I was sure that IPs couldn't mention other users. It drastically changes my perspective on the question.

Tested Mentions

• temp users can mention other users and can be mentioned
• no failed/success sent Mention notifications according to the default settings
• temp users can be muted by registered users (via Special preferences - Muted users:Do not display notifications from these users)

Tested on dewiki and cswiki on beta cluster.
@KStoller-WMF - the table below is not complete yet, but there are couple of issues that probably need discussion. I highlighted them in the table and add more details below the table.

Notes:
(1)

Special:ContetnTranslations doesn't work on beta cluster, but a temp user sees the Translate menu item and can go to the page.

(2)

This is correct behavior: temp users cannot add items to their watchlist (because they do not have access to it).

A slight issue: a temp user will have notification of the following type event_type: watchlist-change recorded in db for three cases:

• when a temp user posts a topic on their own user talk page
• when a temp user creates a page (the default setting: Add pages I create and files I upload to my watchlist)
• when a page created by a temp user is deleted

It's recorded in db only; there is no implications to a temp user - no notifications, no popup messages or anything ( temp users do not see the "add to watchlist" star icon or "subscribe to a topic" link).
There are already two relevant tasks (thx, @Urbanecm_WMF for the reference!) - T221258 and T308084.
(3)

Not receiving notifications for pages linked to the pages created by temp users is not expected behavior. The db records page-linked notification, but a temp user doesn't recieve it.

I checked for a normal user on cswiki betalabs - page link notifications work as expected.

That sounds like temp users are getting system defaults (revert on, page-linked off), not new user defaults (revert off, page-linked on).

Structured discussion (Flow) notifications are not listed in the task description. Adding the info on Flow notifications here. Flow extension is enabled on dewiki betalabs:

There are couple of issues with Flow pages:

• a temp user cannot make their first edit on a Flow page. The warnings incorrectly inform a temp user about its status.

• A temp user can "add" any topic to a watchlist, although watchlist is not reachable for temp users. A Flow page has the watchlist star ison that can be clicked by a temp users:

Thanks, @Etonkovidova!

We haven't started to tackle Flow, but I've created an initial task and included your notes: T342831: Temporary Accounts: Update StructuredDiscussions (Flow)

As for the other discrepancies you noticed with Notifications, I wonder if @Tgr is right and temp users are simply getting system defaults currently. Although that's not what we initially specified in this task, perhaps that's not a problem? @RHo and I discussed and it seems like from the user perspective I don't think any of those system defaults are problematic.

Am I correct in thinking that keeping system defaults is more ideal from the user_properties table bloat perspective?

TempUserCreator calls AuthManager::autoCreateUser(), so $autocreate will be true in LocalUserCreated for temp users. I haven't thought of that.

In T333531#9046724, @KStoller-WMF wrote:

Am I correct in thinking that keeping system defaults is more ideal from the user_properties table bloat perspective?

That's correct.

In T333531#9046743, @Tgr wrote:

TempUserCreator calls AuthManager::autoCreateUser(), so $autocreate will be true in LocalUserCreated for temp users.

Filed T343149: No way to tell in a LocalUserCreated hook handler for a temporary account whether its central account is freshly created about that. Not really sure if it's a problem or just a quirk we don't really care about, but worth considering.

I first thought this would block applying new user defaults to temp users, but actually it doesn't - for a temp user, new user defaults make sense whether it's their first wiki or not. (For normal users, if it's not their first wiki, they might be a long-timer so it's safer to give them the "old user defaults", or at least that's the thinking behing the current behavior AIUI.) So if we don't mind the table bloat this is an easy fix.

FWIW the differences between system defaults and new user defaults are:

• new users don't get notified about reverts (on the assumption that it harms retention)
• new users get notified when their articles get linked to
• new users get email notifications about @-mentions while the system default is web-only (temp users have no email address so this doesn't apply to them)

In T333531#9056631, @Tgr wrote:
FWIW the differences between system defaults and new user defaults are:

• new users don't get notified about reverts (on the assumption that it harms retention)
• new users get notified when their articles get linked to
• new users get email notifications about @-mentions while the system default is web-only (temp users have no email address so this doesn't apply to them)

Thanks, that's a very helpful summary. It seems like it's really the revert notice that editors have strong opinions on.

I started a thread on Metawiki to see if any community members following the IP masking discussions have any thoughts on this:
Talk:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation: Should_temporary_accounts_get_notified_of_reverts.

I'll move this to blocked while we wait for community feedback.

@KStoller-WMF - here are the final testing results (testing done on dewiki and cswikibetalabs):

It is not the task where we can decide on this, but as we work on a very visible part with notifications, I prefer to publicly document things.

I still wonder why temp accounts would have access to Special:ContentTranslation.

Most communities have that love/hate relationship to Translations, the most common critique is the fact that newcomers rush and don't work properly. As IPs (and consequently temp accounts) are often considered as low-quality contributors, opening Content translations to temp accounts might not be well perceived by big communities.

Also starting a translation locks it to the account for a year. I guess that the same applies to temp accounts.

Thank you, @Etonkovidova for the thorough testing! The test results seem to be in alignment with what we would expect; I don't see anything that concerns me with the results.

@Trizek-WMF if you want to escalate that concern, I think the right audience/task would be: T326879: Update Language Team-owned products that may be affected by IP Masking.

I'm moving this to Test in Production / Watching, as I don't think anything is blocked here. @Etonkovidova please move if that's not correct.