Single sign-on transition

This is an archived technical transition plan and technical working document of implementation details for single user login. For more information, see the single login documentation page.

The following are proposed approaches to the assorted problems which must be solved. Note that the problems tend to be common to Indefinite-transition approaches (see Single login).

Legal stuff

The contributor information must be retained and associated with all edits. If this is not done, the license has not been complied with. US law also prohibits removing copyright management information.

We must retain the individual user tables for each project for forensic purposes.
If the account name changes:
1. The contributor field in cur and old (current article and article history) must be updated with the new account name.
2. Ideally (not requirements, desirable):
  1. All talk and Wikipedia: namespace pages, including old revisions, should be updated and the signatures changed to the new name with the original name in a HTML comment for archival and error recovery purposes. (without this the contributor stats would be affected considerably)

Linking from outside projects

User pages can be linked from outside the project (the one for the first author of this page is). If an external link is followed and the account has been given to another contributor, the original user of that user page may have their reputation harmed.

This risk can be reduced by adding a notice to the user page and leaving it to the user with the changed name, not the new owner, to remove it.

Name selection

Summary

policy	conditions
assume same	same password / same email
likely the same - generate report	same IP
assign to most active	no edits on others
discuss	otherwise

No duplicates

If there are no duplicates the name can be used as is, no changes needed; no potential for disagreement.

Duplicates with the same password and/or email address

We assume that these are the same person.
We may be able to check IP address ranges to support this and identify possible problems.
We can generate reports to demonstrate that this is safe, and to identify possible problems. We can use these reports to ask people to change email address and password to avoid a possible name conflict, without identifying the specific problem, to reduce the chance of a compromised account.

Duplicates with the same IP address (if known)

IP addresses are often shared, so an IP address is not sufficient evidence of being the same user.
An IP address is good enough to support a human claim that the accounts are held by the same person.
We should seek to avoid this case by contacting users and informing them that there is a duplicate and asking them to change email address and password to avoid a possible name conflict.
This message should be the same as in the duplicate password and email cases, to reduce the chance of compromised accounts in those cases.

Duplicates with no edits, without the same password, email or IP address

No GFDL or other legal requirement to preserve these.
Many may be accounts of contributors on non-home wikis, registered to avoid name conflicts or impersonation.
If there is an active contributor, active gets the name, inactive gets _wikicode added, like _de or _en.
Contact the users as with the previous cases, to eliminate as many as possible. If one changes in response and other don't, give the responder the name - assumed to be active account and others inactive.
If still duplicate, allocate name to most recently active of the no edits accounts, assuming that's the one most likely to be still of interest to the registrant.
No need for the same process as for duplicate contributing accounts - unlikely to have external links to the user page which probably doesn't exist (no edits by the account).

Duplicates without the same password, email or IP address

We have no reliable automated solution.
We can ask all of those affected to change their email addresses and passwords to be the same on all of the wikis they use. Should be the same message as used for the other cases. This will cause many of these will become duplicate password or email address cases.
- If one has not been used for a long time or has no contributions, it's less disruptive to change that one - less conversion work and time, less chance of upsetting someone.
When there is still a conflict, we can ask the humans to discuss the situation and find a mutually acceptable solution.
- We should encourage those who use their real name to have precedence over those using the same name as a pseudonym, because copyright law gives pseudonyms a shorter copyright term than those using real names and it's convenient to have a real name be obviously a real name, with obviously different copyright term.
If there is still a conflict, we must decide what to do and must enforce a solution in some way.
- Try the real names approach first.
- Seek community discussion and persuasion.
- Avoid breaking external links. If one has extensive links from outside, we should break the fewest links. Since the user page will belong to a different person, there is potential for harm to the reputation of the person with the external links, since those not from the project will be unaware of the name change situation.
  - Use the day this text first appeared as the cut-off day if there are disputes about external links, so neither person can create more to influence the decision.
- Perhaps force both to change and prevent either from having the name with the conflict.
- When a name change must be forced, the new name should be oldname_wiki_code (name_fr, name_en etc.). But better to have done a name change by human request, even if coerced, first.
- Where there has been a name conflict, some notification should be placed on the user page at the wiki where the changed name resides. So if fr user A gets the name, and en user A had their name changed, en user page for name A should say that the en user called A is now user A_en. A_en can choose to remove that notice when they find out about the change. A from fr should leave the notice there. This resolves two problems:
  - How A_en can find their new name easily.
  - How those following a link to the user page can be informed that they may not be looking at the page of the person they are expecting, and where they may find that page now.
- Trolling may be attempted. Use date of first publication of this page to resolve conflicts with new accounts, so trolling is unlikely to be successful. Try to resolve through discussion anyway: new users will mostly just be new users.
- Use requested name changes to remove as many same name cases as possible before the big change.
- During the final transition developers will need to use their judgement to avoid duplicates. May consider blocking new account creation for a day or so before transition, to give time for reports to be run and conflicts resolved. The community can review these decisions later and ask for name changes as necessary.

What to change

Ideally: every reference to the old name.
In practice:
- cur, old and all other tables where the user name text is stored. Old can be done after the down time, by creating a table recording which versions have been converted and using that to work through them all.
- Signatures, if the signature is default or in the user details. Will be very slow for old, use the table to record changes approach. Record the original signature in a HTML comment in case there is a problem. Change which namespaces? All talk, Wikipedia namespace articles?
- Add notice to user pages to notify former account holder and outside linkers. Hopefully few enough that humans can do this by hand.

Comments by JeLuF

If, for example, A is taken by different people on en and fr, none of them can keep that name.

If you assign A to en:A, and A_fr to fr:A, first thing that happens is that fr:A is angry. Than you have to options how to proceed:

replace all occurences of A in the entire fr.wiki by A_fr, for meta data and articles. This is difficult, because it's not always obvious whether some text is about the letter A or the user A. Don't forget meta, user might have signed there using an interwiki link. You'll violate the GFDL by changing the history.
don't replace the old entries, but have a message on fr:User:A pointing to A_fr. Users reading an older discussion and knowing en:A, which now is A, might confuse the old A with the new one. Reading the old article, they might not know that accounts have been renamed and the old discussion might have influence on A's reputation. Without checking the user page, they'll never know.

In my eyes, the only possibility is to require that both en:A and fr:A choose a new name and redirect the old User:A pages to the new ones, without changing the history of the wiki.

The number of users that share usernames is not small, the process should be fully automatic, or only require manual intervention in case of vandalism.

Could you please integrate this into the body of the text? Is it possible? -- Kowey 12:11, 24 Mar 2005 (UTC)

The Third Way

Moved to Single login/Kate