SUL homewiki selection question

List overview All Threads
Download

newer

older

Template parameter expansion...

Network downtime Friday June 6th,...

Anon Sricharoenchai

29 May 2008 29 May '08

5:13 a.m.

Hi, 1. Why still we let the SUL to auto select the homewiki in Special:MergeAccount? 2. Why not we let the wiki that do Special:MergeAccount as homewiki? Example, Assuming that it has user test123@testwiki (1000 edit counts) and test123@lowikibooks (500 edit counts) * If test123 do merge account at, http://test.wikipedia.org/wiki/Special:MergeAccount, then testwiki will be homewiki. * If test123 do merge account at, http://lo.wikibooks.org/wiki/Special:MergeAccount, then lowikibooks will be homewiki. 3. Why not prohibit creation of existing account that have not yet been merged on any wikis? Example, 1. Before SUL, if have test123 created on http://lo.wikipedia.org 2. test123@lowiki has not been merged on any wikis. 3. After SUL, should immediately prohibit the creation of test123 account on any WM wikis. (even that test123 has not yet been merged to SUL) 4. Considering the following situation, 1. Mr.A own "user123" at, * testwiki,meta,common,mediawiki: 100,500,500,500 edits count * enwikipedia,enwikibooks,enwikitionary,enwikisource,enwikinews: 100,100,100,100,100 edits count * lowikipedia,lowikibooks,lowiktionary,lowikisource,lowikinews: 500,100,100,100,100 edits count * totally, Mr.A has 3000 edits count 2. Mr.B own "user123" only at frwikipedia with 2000 edits count 3. When Mr.A use user123 on lowikipedia, and do http://lowikipedia/Special:MergeAccount, what will be the homewiki of user123? 4. Mr.A can successfully merge account? 5. If homewiki determined by the system is user123@frwikipedia, then what thing Mr.A could do to get his accounts merged? Regards, Anon.

Show replies by date

Anon Sricharoenchai

29 May 29 May

6:53 a.m.

5. In another situation, 1. Mr.A own user123@frwikipedia: 50000 edits count 2. Mr.A has ever been approved to be sysop on frwikipedia, but at that time, he refuse to be sysop 3. Mr.B own user123@lowikipedia: 10000 edits count 4. After SUL, user123 has not been merged by anyone 5. In someday later (after SUL), Mr.B has been elected to be sysop on lowikipedia 6. At that time (after Mr.B got sysop), who will get the homewiki? 6. The next situation, 1. Mr.A own user123@frwikipedia: 50000 edits count 2. Mr.A has ever been approved to be sysop on frwikipedia, but at that time, he refuse to be sysop 3. Mr.B own user123@lowikipedia: 10000 edits count 4. When SUL is enabled for sysop only, 4.1 Mr.A try to merge his account, but he can't, since he is not sysop 4.2 Mr.B is sysop on lowikipedia, and Mr.B successfully merge his user123 account (after Mr.A fail to merge) 5. When SUL is enabled for everyone, Mr.A try to merge his account again, but he got the message "user123 has already been merged by user123@lowikipedia"!!! 6. Can Mr.A request steward to delete global account of Mr.B?

Tim Starling

7:15 a.m.

Anon Sricharoenchai wrote:

...

Hi, 1. Why still we let the SUL to auto select the homewiki in Special:MergeAccount?

The "home wiki" is a concept used by SUL to improve the chances that the most active user of an account name will obtain the global account for that name. If the passwords don't match, only the user who has access to the home wiki will be allowed to merge. After merge, the home wiki has no significance and is not displayed publically.

...

2. Why not we let the wiki that do Special:MergeAccount as homewiki? Example, Assuming that it has user test123@testwiki (1000 edit counts) and test123@lowikibooks (500 edit counts) * If test123 do merge account at, http://test.wikipedia.org/wiki/Special:MergeAccount, then testwiki will be homewiki. * If test123 do merge account at, http://lo.wikibooks.org/wiki/Special:MergeAccount, then lowikibooks will be homewiki.

We don't do this because it would defeat the purpose of having a home wiki.

...

3. Why not prohibit creation of existing account that have not yet been merged on any wikis? Example, 1. Before SUL, if have test123 created on http://lo.wikipedia.org 2. test123@lowiki has not been merged on any wikis. 3. After SUL, should immediately prohibit the creation of test123 account on any WM wikis. (even that test123 has not yet been merged to SUL)

This is already the case, but we have had some reports that this protection sporadically stops working. If this is true, it should be fixed soon.

...

4. Considering the following situation, 1. Mr.A own "user123" at, * testwiki,meta,common,mediawiki: 100,500,500,500 edits count * enwikipedia,enwikibooks,enwikitionary,enwikisource,enwikinews: 100,100,100,100,100 edits count * lowikipedia,lowikibooks,lowiktionary,lowikisource,lowikinews: 500,100,100,100,100 edits count * totally, Mr.A has 3000 edits count 2. Mr.B own "user123" only at frwikipedia with 2000 edits count 3. When Mr.A use user123 on lowikipedia, and do http://lowikipedia/Special:MergeAccount, what will be the homewiki of user123? 4. Mr.A can successfully merge account? 5. If homewiki determined by the system is user123@frwikipedia, then what thing Mr.A could do to get his accounts merged?

The best idea is for Mr.A and Mr.B to have a friendly chat with each other about who they think should get the global account. Then, depending on the results of that conversation, either Mr.A can rename his many accounts to some new, unique username; or Mr.B can rename his fr.wikipedia account and Mr.A can get the global name. -- Tim Starling

Anon Sricharoenchai

7:34 a.m.

...

1. What if Mr.B don't want to negotiate with Mr.A? 2. What if Mr.A only speak lo, while Mr.B only speak fr? 3. If Mr.A and Mr.B have friendly chat, and end up with, * Mr.B willing to let Mr.A get global account of user123, since Mr.A really want to use many wikis than Mr.B * Mr.B willing to continue using his local user123 account (by not changing account name) * Mr.A also willing to let Mr.B continue to use local user123 account (by not changing Mr.B account name). * How can Mr.A and Mr.B do, to meet this?

MinuteElectron

7:39 a.m.

Anon Sricharoenchai wrote:

...

This is not permitted. MinuteElectron.

Anon Sricharoenchai

7:49 a.m.

On 5/29/08, MinuteElectron <minuteelectron(a)googlemail.com> wrote:

...

Anon Sricharoenchai wrote:

This is not permitted.

Why not permitted?

Tim Starling

8:21 a.m.

Anon Sricharoenchai wrote:

...

1. What if Mr.B don't want to negotiate with Mr.A?

I think you should cross that bridge when you come to it.

...

2. What if Mr.A only speak lo, while Mr.B only speak fr?

Maybe you can find someone willing to interpret for you.

...

3. If Mr.A and Mr.B have friendly chat, and end up with, * Mr.B willing to let Mr.A get global account of user123, since Mr.A really want to use many wikis than Mr.B * Mr.B willing to continue using his local user123 account (by not changing account name) * Mr.A also willing to let Mr.B continue to use local user123 account (by not changing Mr.B account name). * How can Mr.A and Mr.B do, to meet this?

Easy, Mr.A and Mr.B should both become MediaWiki developers, and write the relevant code by pair-programming. -- Tim Starling

Anon Sricharoenchai

8:29 a.m.

On 5/29/08, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

Easy, Mr.A and Mr.B should both become MediaWiki developers, and write the relevant code by pair-programming.

Anyone can easily become MW developer for WM?

Nick Jenkins

30 May 30 May

6:36 a.m.

...

1. What if Mr.B don't want to negotiate with Mr.A?

I think you should cross that bridge when you come to it.

I find Mr.B's lack-of-commitment to being evil disturbing. If wants to be bad, he should do it properly ... once more with feeling! For example, why couldn't Mr.B build a list of usernames who have not yet merged their global accounts, yet have a non-trivial number of edits (with some recent edits), register a user on another wiki with that same name, make about 10 edits, and repeat for 100,000 other accounts on many wikis. Then when contacted by a Mr.A he could offer to forgo his username for the tiny sum of $1 via PayPal as recompense "for inconvenience and psychological trauma caused by losing his online identity". Are you going to argue for a dollar? I wouldn't. Plenty of people pay much more that $1 to domain name squatters, and people can get quite attached to their usernames, and can want to "own" that name across all the projects. Assume 25% of people feel the same way, and you've got $25k via nefarious means. The easiest way to stymie this (in addition to the current captchas which slow down account creation) would be to prevent new registrations of a user name that is already used on another project but which has not done any account merging. -- All the best, Nick.

Anthony

11:25 a.m.

...

Easy, Mr.A and Mr.B should both become MediaWiki developers, and write the relevant code by pair-programming.

Why code it when you can implement it by hand in those cases: Sysop Mr. A. Desysop Mr. B. Run MergeAccount. Return sysop privileges to original. Anthony

Anon Sricharoenchai

1:46 p.m.

On 5/29/08, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

Anon Sricharoenchai wrote:

1. What if Mr.B don't want to negotiate with Mr.A?

I think you should cross that bridge when you come to it.

2. What if Mr.A only speak lo, while Mr.B only speak fr?

Maybe you can find someone willing to interpret for you.

Easy, Mr.A and Mr.B should both become MediaWiki developers, and write the relevant code by pair-programming.

You mean the patch are welcome? Well, I have just written the patch, that give privilege to group 'mergeaccount', in my previous email.

Rotem Liss

2:09 p.m.

On Fri, May 30, 2008 at 4:46 PM, Anon Sricharoenchai <anon.hui(a)gmail.com> wrote:

...

On 5/29/08, Tim Starling <tstarling(a)wikimedia.org> wrote:

Anon Sricharoenchai wrote: >> > 4. Considering the following situation, >> > 1. Mr.A own "user123" at, >> > * testwiki,meta,common,mediawiki: 100,500,500,500 edits

count

>> > *

enwikipedia,enwikibooks,enwikitionary,enwikisource,enwikinews: > >> > 100,100,100,100,100 edits count

>> > *

lowikipedia,lowikibooks,lowiktionary,lowikisource,lowikinews:

>> > 500,100,100,100,100 edits count >> > * totally, Mr.A has 3000 edits count >> > 2. Mr.B own "user123" only at frwikipedia with 2000 edits count >> > 3. When Mr.A use user123 on lowikipedia, and do >> > http://lowikipedia/Special:MergeAccount, what will be the

homewiki of

>> > user123? >> > 4. Mr.A can successfully merge account? >> > 5. If homewiki determined by the system is user123@frwikipedia

>> > then what thing Mr.A could do to get his accounts merged? >> >> >> The best idea is for Mr.A and Mr.B to have a friendly chat with each

other

>> about who they think should get the global account. Then, depending

on the

>> results of that conversation, either Mr.A can rename his many

accounts to

>> some new, unique username; or Mr.B can rename his fr.wikipedia

account and

Mr.A can get the global name.

1. What if Mr.B don't want to negotiate with Mr.A?

I think you should cross that bridge when you come to it.

2. What if Mr.A only speak lo, while Mr.B only speak fr?

Maybe you can find someone willing to interpret for you.

Easy, Mr.A and Mr.B should both become MediaWiki developers, and write

the

relevant code by pair-programming.

You mean the patch are welcome? Well, I have just written the patch, that give privilege to group 'mergeaccount', in my previous email.

I think it is a good idea to allow the Stewards to set a certain account as the home account, not necessarily with a special user group (which is not the right tool for such a one-time task), but with a drop-down box in Special:CentralAuth, shown if the global account does not exist. This drop-down box will create a global account with only the selected account attached (and maybe also users with the same [confirmed] e-mail?). Then the user will be able to attach anyone else via Special:MergeAccount.

Anon Sricharoenchai

2:43 p.m.

On 5/30/08, Rotem Liss <rotemliss(a)gmail.com> wrote:

...

Easy, Mr.A and Mr.B should both become MediaWiki developers, and write

the

relevant code by pair-programming.

You mean the patch are welcome? Well, I have just written the patch, that give privilege to group 'mergeaccount', in my previous email.

It may not be a one-time task. The global account may be revoked later, and given to another account, back and forth :)

...

the right tool for such a one-time task), but with a drop-down box in Special:CentralAuth, shown if the global account does not exist. This

But it need too much coding which is unnecessary?

...

drop-down box will create a global account with only the selected account

Just setting the home wiki flag, by not creating a global account, may be more suitable.

...

attached (and maybe also users with the same [confirmed] e-mail?). Then the user will be able to attach anyone else via Special:MergeAccount.

It currently support attaching the orphan account into the existing global account?

Anon Sricharoenchai

6:44 a.m.

On 5/29/08, Anon Sricharoenchai <anon.hui(a)gmail.com> wrote:

...

In this scenario, can we create a special privileged group named 'mergeaccount', so that this group will take precedence over sysop. Then both Mr.A and Mr.B agree to request steward to assign Mr.A to group 'mergeaccount' in some wiki that Mr.A has account. $priorityGroups = array( 'sysop', 'bureaucrat', 'steward' ); $workingSet = array(); $mergeaccountSet = array(); foreach( $migrationSet as $wiki => $local ) { if( array_intersect( $priorityGroups, $local['groups'] ) ) { if( $local['editCount'] ) { // Ignore unused sysop accounts $workingSet[$wiki] = $local; } } elseif (in_array('mergeaccount', $local['groups'] ) { $mergeaccountSet[$wiki] = $local; } } if( $mergeaccountSet ) { $workingSet = $mergeaccountSet; } if( !$workingSet ) { // No privileged accounts; look among the plebes... $workingSet = $migrationSet; }

Anon Sricharoenchai

29 May 29 May

9:19 a.m.

On 5/29/08, Tim Starling <tstarling(a)wikimedia.org> wrote:

...

Anon Sricharoenchai wrote:

Hi, 1. Why still we let the SUL to auto select the homewiki in Special:MergeAccount?

The most active user on only one wiki doesn't mean that he deserve to get global account. The main objective of global account is to benefit the user that have accounts on many wikis. (Am I correct?) If Mr.A (see below) spread out his activeness across many wikis, comparing to Mr.B (see below) that only active on only one wiki, Mr.A will lose global account to Mr.B, since the activeness of Mr.A is divided into many wikis, while Mr.B focus only on one wiki, then win the edits count. Do you think that Mr.A will get more benefit from global account than Mr.B?

...

We don't do this because it would defeat the purpose of having a home wiki.

The purpose of home wiki is to estimate the activeness? Trying to do http://lo.wikibooks.org/wiki/Special:MergeAccount by user test123, is also the evidence that test123(a)lo.wikibooks is an active account.

...

This is already the case, but we have had some reports that this protection sporadically stops working. If this is true, it should be fixed soon.

You mean that this is a bug? The real intention is to also block account creation of unmerged username? My experience is that, 1. I have tried create new account named testwiki.test@testwiki 2. While there's no user named testwiki.test on any other wikis, why I'm not automatically get the global account for testwiki.test? 3. Why I still can create new account testwiki.test on lowiki? The next case, 1. User testxyz already exists on enwiki before SUL, http://toolserver.org/~vvv/sulutil.php?user=testxyz 2. After SUL, testxyz have not yet been merged. 3. However, why I still can create new account testxyz on enwikibooks? The above two cases is a bug?

...

Anon Sricharoenchai

9:32 a.m.

...

Sorry, I mean lowiki.test username, http://toolserver.org/~vvv/sulutil.php?user=lowiki.test 1. I first create on lowiki, http://lo.wikipedia.org/w/index.php?title=%E0%BA%9E%E0%BA%B4%E0%BB%80%E0%BA… 2. Then I still can create new one with the same name on testwiki, http://test.wikipedia.org/w/index.php?title=Special:Log&user=Lowiki.test Is this a bug?

Platonides

31 May 31 May

8:54 p.m.

Anon Sricharoenchai wrote:

...

No, automatic global account creation is not happening (yet). It would be a bug if after lowiki.test has a global account, a new lowiki could be created outside.

Anon Sricharoenchai

5 Jun 5 Jun

1:44 p.m.

On 5/29/08, Anon Sricharoenchai <anon.hui(a)gmail.com> wrote:

...

We don't do this because it would defeat the purpose of having a home wiki.

I think I now understand why using FCFS method to usurp global account is not suitable with the current system. Since, currently, the local account creation of the existing username is not blocked, FCFS will enable anyone to be able to usurp global account from existing unmerged user. However, could you please answer the following questions? 1. Is there a plan to prohibit local account creation of existing ununified username? 2. While the selection is still depend on edit count, but why you not collect the edit count of the subset sharing email or password, as stated in http://meta.wikimedia.org/wiki/Single_login_specifications ? (``GROUP 2: If an account name exists in multiple subsets, the subset with the highest edit count "wins".'') While the edit count still be used for activeness measurement, I'm please to write a patch for counting the subset's edit count, to make the selection be more reasonable. 3. Why haven't you told me why sysop should take precedence in getting global account? On 5/30/08, Anon Sricharoenchai <anon.hui(a)gmail.com> wrote:

...

On 5/30/08, Brion Vibber <brion(a)wikimedia.org> wrote:

Anon Sricharoenchai wrote:

By default, it would go to Mr. B, as Mr. B has a privileged account while Mr. A does not, and the heuristic gives preference to privileged accounts if they exist. If they choose to swap positions, that can be easily taken care of.

Why sysop should always take more precedence than user? Mr.A may not want to be sysop, because he really want to have the same equality as most other user. Mr.A may believe and respect in equality of wikipedian, so he try to be equal to others as much as possible.

6. The next situation, 1. Mr.A own user123@frwikipedia: 50000 edits count 2. Mr.A has ever been approved to be sysop on frwikipedia, but at that time, he refuse to be sysop 3. Mr.B own user123@lowikipedia: 10000 edits count 4. When SUL is enabled for sysop only, 4.1 Mr.A try to merge his account, but he can't, since he is not sysop 4.2 Mr.B is sysop on lowikipedia, and Mr.B successfully merge his user123 account (after Mr.A fail to merge) 5. When SUL is enabled for everyone, Mr.A try to merge his account again, but he got the message "user123 has already been merged by user123@lowikipedia"!!! 6. Can Mr.A request steward to delete global account of Mr.B?

Sure, he can ask. :)

However, after Mr.B is revoked global account, the home wiki is still owned by Mr.B, and only Mr.B can create global account again :(

Note that it would be rude for Mr. Steward to do so without the agreement of Mr. B, who has legitimate claim to the account. But if they

What is legitimate? Who can judge which one is legitimate? Who can judge the sysop status and edit count is legitimate?

agree, or there is other very good reason to switch the account ownership, it can be easily taken care of.

Brion Vibber

6:45 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anon Sricharoenchai wrote:

...

However, could you please answer the following questions? 1. Is there a plan to prohibit local account creation of existing ununified username?

Not presently as such, however at some point automatic migration of all remaining accounts may be initiated. Prohibiting local account creation of existing ununified usernames would be essentially equivalent, as it would require people wanting to create such accounts to (manually) initiate a migration before continuing with the additional account setup.

...

2. While the selection is still depend on edit count, but why you not collect the edit count of the subset sharing email or password, as stated in http://meta.wikimedia.org/wiki/Single_login_specifications ? (``GROUP 2: If an account name exists in multiple subsets, the subset with the highest edit count "wins".'') While the edit count still be used for activeness measurement, I'm please to write a patch for counting the subset's edit count, to make the selection be more reasonable.

It's not possible to group multiple wikis by password until all passwords have been manually entered, but we need to make a selection ahead of time in order to determine if the presently logged-in account matches the home account. So it's perhaps a bit of a catch-22 there. :) I suspect it's fairly unlikely that the results would change significantly based on making such a change, though of course there may be some outlying cases.

...

3. Why haven't you told me why sysop should take precedence in getting global account?

To avoid disruption, impersonation, etc, privileged accounts are given priority. - -- brion

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhINDoACgkQwRnhpk1wk47BhACfY/b4dDwraXZJik2FYorf1E3n L7MAoNTqeWfHv70+BGUilnbQe19tbOd1 =Bzar -----END PGP SIGNATURE-----

Simetrical

7 p.m.

On Thu, Jun 5, 2008 at 2:45 PM, Brion Vibber <brion(a)wikimedia.org> wrote:

...

Anon Sricharoenchai wrote:

However, could you please answer the following questions? 1. Is there a plan to prohibit local account creation of existing ununified username?

I think the question was: is there any plan to prohibit the creation of a local account, when an ununified account with that name exists on *another* wiki? This is not equivalent to unifying all remaining accounts, although of course doing so would make the question moot.

...

To expand on this, passwords are stored as a hash salted with the user id. We can't answer the question, "Is the password for user X the same as the password for user Y?" We can only answer the question, "Is the password for user X 'abcd'? Is the password for user Y 'abcd'?" This improves security, in that a malicious Wikipedia admin would find it hard to figure out what passwords anyone has, but it also causes difficulty when you're trying to do something legitimately.

Brion Vibber

7:06 p.m.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Simetrical wrote:

...

I think the question was: is there any plan to prohibit the creation of a local account, when an ununified account with that name exists on *another* wiki?

I know; that's the question I answered.

...

This is not equivalent to unifying all remaining accounts, although of course doing so would make the question moot.

It pretty much is in effect, as I went on to explain. - -- brion vibber (brion @ wikimedia.org)

...PGP SIGNATURE...

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkhIOTwACgkQwRnhpk1wk44UewCghz64QliAjHMaBUm/otgyB524 O1MAnjh+HxOUbtz3JV8DaxBZ9yl1cl8J =EZJX -----END PGP SIGNATURE-----

Platonides

8:40 p.m.

Anon Sricharoenchai wrote:

...

Do you refer to First Come, First Serve for _requesting_ the global account or _creating_ the first account with that name?

...

However, could you please answer the following questions? 1. Is there a plan to prohibit local account creation of existing ununified username?

It is supposed to be blocked :)

...

Sysops are usually more important than just registered John Doe. A method as biased as editcount. :)

Platonides

9:55 p.m.

Platonides wrote:

...

Anon Sricharoenchai wrote:

Do you refer to First Come, First Serve for _requesting_ the global account or _creating_ the first account with that name?

However, could you please answer the following questions? 1. Is there a plan to prohibit local account creation of existing ununified username?

It is supposed to be blocked :)

Sorry, i read unified.

5804

days inactive

5811

days old

wikitech-l@lists.wikimedia.org

Manage subscription

22 comments

9 participants

tags (0)

participants (9)

Anon Sricharoenchai
Anthony
Brion Vibber
MinuteElectron
Nick Jenkins
Platonides
Rotem Liss
Simetrical
Tim Starling