Thinking the other day, I came up with my own process for migration, that in many ways is similar to tha one at single login, in that it assumes a transition period, rather than attempting a "big bang". However, I was thinking of a more human way of resolving "same username, different people" scenarios, in the hope that this would not be too common occurrence. [After all, the usernames that are first to go in one language, won't be the first to go in another: I shouldn't think many Japanese users will have registered as John_Smith!]

Combining some of my thoughts with some mentioned there, we could proceed as follows:

Create a list of all users for each wiki (including e-mail addresses, where supplied)

Reserve all these names in the new DB; we don't want conflicts arising between newly created accounts and accounts waiting to be migrated.

Auto-migrate all users with globally unique names to the new database

Create a table of users with names already taken on other projects

If more than one user with a given name have entered the same e-mail address, mark them as "probably matching"

Possibly, if all users with a given name use the same address, we can auto-migrate, although that would probably require the passwords to match as well, otherwise we wouldn't know what to choose. If not, they could be asked at logon to confirm that the accounts can be merged, typing the password for each one, and the new password desired. They could then tick a box if they weren't the same person after all, and the next step would come into play.

If a name looks to be used by multiple people (i.e. there are at least some accounts with no/non-matching e-mail addresses), use a bot to alert those people on their User_talk: pages that they need to sort this out. Alternatively, we could alert them at logon, but basically we want to give them a chance to either:

confirm that they are actually the same person, holding multiple accounts - this could be done via a Special page where they can enter the passwords for all the synonymous accounts, allowing them to continue editing on a one-project login in the mean-time

or

get in touch with the other users with the same name, to decide who should keep it. I think this is better than using a mechanical rule, since various things can be taken into account: old/new, regular/casual, recent/departed, well-known to the community/no real name-recognition built up yet...

This obviously requires some central place where settlements can be brokered for problem usernames, providing: a)interpretters, to make sure that disputing users understand each other properly; and b)a mechanism for manually enacting the transfer of one user to the same-named account, and the other to a new name. This seems over the top in some ways, but I think it will save more problems than it will create; I also think it's more in the Wikimedia spirit.

I see there as being the following cases:

case

procedure per suggestion above

globally unique username

automigration

N accounts w/ same name, 1 e-mail address

automigrtion

N accounts w/ same name, 1 actual user

manual confirmation by password

N accounts w/ same name, X distinct active users

resolution process: discussion

N accounts w/ same name, 1 active user, Y ex-users

wait for time-out

N accounts w/ same name, X active users, Y ex-users

ack! discuss and wait?

As you can see, we need some kind of time-out: this is because, if we go down the "resolve by discussion" route, we can't just let one user claim the name because the other one hasn't shown up yet. I guess it may sometimes be obvious that one account is more worth the name than the other; and there's no reason that someone can't leave the name to whoever else has it, and pick a new one. But in more complicated cases, we'd need to set a limit for a user who doesn't reply to requests to respond before they have to pick a new name by default.

Hopefully, a lot of this wouldn't be necessary, because there wouldn't be that many genuinely overlapping usernames. Indeed, the more chances we give people to assist the username resolution process, the less we need to worry about copyright issues, because names that point to the same person will not need clarifying. - IMSoP 19:34, 19 Sep 2004 (UTC)

An indefinite transition period is preferable, because it allows users to continue logging in with their old username until their account has been migrated successfully. In fact, any forced name-change will create a problem here: the user will have to be told to try their old password with a new name, or given a specific "migrate disabled account" link.

I think the main technical issue with this approach will be the need to constantly deal with two parallel sets of users everywhere in the software. The software could special-case if(user_id < $FIRST_SSO) for everything like history listings, so that the info could be looked up in the local database instead of the global one; but that's not nice for software maintainability.

Thinking about it, this can be avoided if the lookup to the user database can "know" what project it is being called from: it can then do the if(user_id < $FIRST_SSO) check, and return data from either the global user table, or the appropriate local one (which would have been imported from the separate project databases). Similarly, usernames marked as pending (i.e. reserved for existing user(s), but not yet migrated) in the central DB can be re-resolved to the appropriate entry before the function returns.

This way, I don't think we'd need to force migration before editing (although obviously we'd encourage it), or have any kind of "this is a new-style login" box: if the user name was marked as pending, it would put up a reminder, but log in using the old table. Attributions for and references to unresolved duplicate usernames would also remain correct, only needing to be changed and disambiguated when users agreed to give up their old name in favour of a new one. [Note that it won't matter if fr:User:A and en:User:A carry on coexisting forever; they already do!] - IMSoP 19:34, 19 Sep 2004 (UTC)