I logged into beta on SSH and ran the following:

mwscript CentralAuth:renameUsersMatchingPattern.php --wiki cswiki --dry-run --from '*Unregistered $1' --to '~Unregistered $1'

When the script ran, it printed the following immediately and then continued processing:

Would rename "*Unregistered 10181" to "~Unregistered 10181"

The reason the script waited is because on beta there are 17 renameuser jobs pending. This means that the script will wait forever until these are complete. Making this less than 15 means that the script should run as normal.

As such, this script can be used for the rename of temporary accounts.

• Make a recommendation of what we should do for beta in response to this config change:
  • Should we rename, and if not then what should we do?

I personally lean towards renaming. To go into more detail:

• While it may be useful from a testing perspective to have to deal with temporary accounts who don't match the pattern, I don't think it is worth the extra work making this possible to support. This is because the client side based detection of temporary account usernames would need to query the DB for the source of truth, or the configuration defining the valid patterns would have to support multiple patterns with one defined as pattern used for new temporary accounts.
• It would be good to work out if it is possible to do such a rename, in case this is desirable in the future. If it goes terribly wrong, then we can learn from it and there should be little harm done as the problems are just on betawikis (though I think it wouldn't be possible to go terribly wrong).
• On the other hand, renaming causes everyone logged in to a temporary account to be logged out (as mentioned by @Urbanecm_WMF). In my opinion, because this is on beta and we don't plan to change the pattern on production, this does not outweigh the first bullet point.

As such I suggest renaming as the option here and put this into the needs review column for feedback.

This all sounds sensible to me.

To expand on the potential work to allow the naming format to change after we deploy to production:

• The work that it would take to get the temp user status from the DB is a lot, and should wait for T336176: MediaWiki user types so that effort doesn't have to work around however temporary accounts was implemented.
• Supporting multiple patterns for $wgAutoCreateTempUser['matchPattern'] looks more doable - seems like it would mainly involve updating TempUser/Pattern.php to recognize a list of prefix/suffix combinations? I'm feeling a bit 50/50 about whether it's worth doing speculatively now... Might be interesting to confirm that we can get this working. (Though I agree it would also be interesting to see if a rename is feasible.)

@Niharika - we're assuming that a change to the naming format is highly unlikely after we deploy to production but not completely impossible. Do you have any thoughts on:

• The likelihood of this (e.g. do we actually have more rounds of user testing scheduled that might make it more likely?)
• Whether it's better to rename existing temp users (so users you were investigating have new names, but at least all temp users look the same) or supporting all old temp user patterns (so temp user names never change, but if the format changes, multiple patterns might be visible in the UI)?

One consideration is that if we want to rename the existing temporary accounts to use the year and hyphen format we will need to modify/create a maintenance script for this as the existing script doesn't do any transformations for hyphens. The year could be hardcoded into the new format as 2023 for all existing temp accounts if we act soon.

I've read/thought through all of this again and I'm inclined to go with supporting multiple patterns, rather than renaming.

Some fairly insurmountable disadvantages of renaming:

• Signatures would not be updated. (Note that temporary users can't customize their signatures, so they would always match their name, if no rename were performed).
• Log entries that mention user names within blocks of text would not be updated.

Supporting multiple patterns on the other hand would only require the configs to be set carefully. For this change we'd want something like:

$wgAutoCreateTempUser['genPattern'] = '~$1';
$wgAutoCreateTempUser['matchPattern'] = [ '~2$1', '*$1']; // Recognize the old pattern too
$wgAutoCreateTempUser['reservedPattern'] = '~$1'; // No need to reserve the old pattern as it's a match

In T349489#9437815, @Tchanders wrote:

I've read/thought through all of this again and I'm inclined to go with supporting multiple patterns, rather than renaming.

Some fairly insurmountable disadvantages of renaming:

• Signatures would not be updated. (Note that temporary users can't customize their signatures, so they would always match their name, if no rename were performed).
• Log entries that mention user names within blocks of text would not be updated.

Supporting multiple patterns on the other hand would only require the configs to be set carefully. For this change we'd want something like:

$wgAutoCreateTempUser['genPattern'] = '~$1';
$wgAutoCreateTempUser['matchPattern'] = [ '~2$1', '*$1']; // Recognize the old pattern too
$wgAutoCreateTempUser['reservedPattern'] = '~$1'; // No need to reserve the old pattern as it's a match

After some time of reflection and some further discussions, I also agree that we should allow other patterns to be recognised instead of renaming.