Note that with the exception of GrowthExperiments, the other extensions are in our list of "non-maintained projects". On the other hand, we do say that for "non-maintained projects":

Bugs and issues coming up on this projects will ONLY receive attention if the issue is urgent, affects a large number of users and needs to be unbroken immediately.

... which is probably the case for IP masking work.

That aside, addressing IP masking issues across all of these projects might be a significant chunk of work, depending on what product decisions we make, so I assume we will want to clarify scope in Q3, in order to implement the needed changes in Q4, to support a rollout of IP masking work in Q1/Q2 of FY2023-2024.

Coordinating all of the teams and moving pieces for this release will be extensive. I suggest that rather than add more complexity at this point by attempting to provide certain Growth features for temporary accounts, we clearly decide that isn't part of the MVP release. In other words, IP editors currently don't receive Growth features and neither will temporary accounts for the initial IP Masking MVP release. Once the MVP is out, we can decide if we should prioritize "teaser" Growth features for temporary accounts (and we could likely conduct A/B testing with less confusion at that point too). Does that seem logical, or do others strongly feel we need to prioritize allowing temporary account access to a subset of Special:Homepage as part of the MVP?

I don't think that simplifies the other work we need to do though, it sounds like we will still need to review all of the extensions / projects we maintain.

In T326877#8533226, @KStoller-WMF wrote:

Coordinating all of the teams and moving pieces for this release will be extensive. I suggest that rather than add more complexity at this point by attempting to provide certain Growth features for temporary accounts, we clearly decide that isn't part of the MVP release. In other words, IP editors currently don't receive Growth features and neither will temporary accounts for the initial IP Masking MVP release. Once the MVP is out, we can decide if we should prioritize "teaser" Growth features for temporary accounts (and we could likely conduct A/B testing with less confusion at that point too). Does that seem logical, or do others strongly feel we need to prioritize allowing temporary account access to a subset of Special:Homepage as part of the MVP?

I don't think that simplifies the other work we need to do though, it sounds like we will still need to review all of the extensions / projects we maintain.

Agree that the 'teaser' features should wait till after post-MVP needed tasks. Per off-Phab discussion, should we create some sub-tasks to do a high-level product, QA, and Eng review of the impact of the change for Growth maintained projects?

In T326877#8533226, @KStoller-WMF wrote:

Once the MVP is out, we can decide if we should prioritize "teaser" Growth features for temporary accounts (and we could likely conduct A/B testing with less confusion at that point too). Does that seem logical, or do others strongly feel we need to prioritize allowing temporary account access to a subset of Special:Homepage as part of the MVP?

That makes sense. In practice, that will mean updating a bunch of code to check not just if the user is logged-in, but also if the account is a non-temporary one. We could probably make a task for that and start it whenever we have time.

In T326877#8533824, @RHo wrote:

Agree that the 'teaser' features should wait till after post-MVP needed tasks. Per off-Phab discussion, should we create some sub-tasks to do a high-level product, QA, and Eng review of the impact of the change for Growth maintained projects?

That sounds like a good idea to me!

Other non-maintained projects that will be affected:

• RC and watchlist (the "user type" filter will need to be extended with the new type)
• NewUserActions, NewUserNotif? I'm not really sure what these are used for, but we should make sure they interpret "new user" in a way that makes sense for their use case
• Nuke - it can mass delete edits by IP, that functionality probably needs to be adjusted (maybe this is a good time to transition it to the Moderator Tools team?).

OTOH PageTriage will be owned by Moderator Tools at that point, I think?

In T326877#8533824, @RHo wrote:

Per off-Phab discussion, should we create some sub-tasks to do a high-level product, QA, and Eng review of the impact of the change for Growth maintained projects?

We definitely should. It might also be helpful to brainstorm some general guidelines / suggestions on what to look for (e.g. engineering-wise the usage of the LocalUserCreated hook needs to be reviewed).

We also need more clarity on some of the technical implementation plans, I think. E.g. what does it mean that preferences are not accessible for temp users? (Will a direct link to Special:Preferences still work? Will an options API request work?) What happens when a user without a session makes a write API request (a common scenario in Flow)?

In T326877#8539351, @Tgr wrote:

Other non-maintained projects that will be affected:

• RC and watchlist (the "user type" filter will need to be extended with the new type)
• NewUserActions, NewUserNotif? I'm not really sure what these are used for, but we should make sure they interpret "new user" in a way that makes sense for their use case
• Nuke - it can mass delete edits by IP, that functionality probably needs to be adjusted (maybe this is a good time to transition it to the Moderator Tools team?).

OTOH PageTriage will be owned by Moderator Tools at that point, I think?

In T326877#8533824, @RHo wrote:

Per off-Phab discussion, should we create some sub-tasks to do a high-level product, QA, and Eng review of the impact of the change for Growth maintained projects?

We definitely should. It might also be helpful to brainstorm some general guidelines / suggestions on what to look for (e.g. engineering-wise the usage of the LocalUserCreated hook needs to be reviewed).
We also need more clarity on some of the technical implementation plans, I think. E.g. what does it mean that preferences are not accessible for temp users? (Will a direct link to Special:Preferences still work? Will an options API request work?) What happens when a user without a session makes a write API request (a common scenario in Flow)?

I created an initial rough draft of testing from Product/Design perspective here as a start, and included questions in there about what happens when specific URL is accessed when that person is a temp account. Please feel free to edit and add if it is useful.

Thank you @RHo that document will be extremely helpful!

I created subtasks: T327419: Growth: Product testing for IP Masking & T327420: Growth: Engineering testing for IP Masking to cover the testing / audit work that needs to be completed. Perhaps engineers can brainstorm and add to T327420?

@MShilova_WMF Should we convert this task to the Epic that all Growth + IP Masking work falls under?

@KStoller-WMF , yes, that is a great idea. Especially, given that we now have a new dedicated IP-Masking bar on our roadmap. I converted this task to an epic and added related tasks as child tickets.

In T326877#8539351, @Tgr wrote:

Other non-maintained projects that will be affected:

• RC and watchlist (the "user type" filter will need to be extended with the new type)
• NewUserActions, NewUserNotif? I'm not really sure what these are used for, but we should make sure they interpret "new user" in a way that makes sense for their use case
• Nuke - it can mass delete edits by IP, that functionality probably needs to be adjusted (maybe this is a good time to transition it to the Moderator Tools team?).

OTOH PageTriage will be owned by Moderator Tools at that point, I think?

I met with Kirsten last week and mentioned that we'd likely be happy to tackle the PageTriage work for this. I'm not sure about Nuke but happy to discuss.

Just a note that any special pages that call SpecialPage::requireLogin can be updated to call SpecialPage::requireNamedUser if necessary. From a quick search, it looks like this may affect GrowthExperiments and Echo.

I updated the task description to add more details and clarify that the AHT team conducted an initial audit that helped identify work that would be needed by the Growth team, but that ultimately the Growth team will be responsible for all features and extensions that we own or maintain (even if they weren't listed in that initial AHT audit).