Last modified: 2014-11-18 17:40:21 UTC
From the (un)-archived discussion at meta (http://meta.wikimedia.org/w/index.php?title=Wikimedia_Forum&diff=next&oldid=3619272), [[User:JohnnyMrNinja]] writes (in part): I am proposing that account unification be completed for all eligible accounts without requiring the user to take any additional steps. This would make UL the rule rather than the exception that it currently is, and bring us closer to the goals of universal watchlists, recent changes, interwiki page moves, etc. This would be especially helpful on Commons, which has so many images that were originally uploaded at another WMF wiki, enabling better attribution without interwiki links. I propose that it be carried out as a one-time process rather than a continuous automatic software process, allowing users to still adjust ULs as they see fit. [...]what I mean by "eligible accounts" was all accounts without existing conflicts, as these can be taken care of by an automated process. Accounts that have conflicts would be unaffected by this specific proposal. Conflicts could not be solved by any automated process, as each case would be different. Looks like it has enormous support on meta. I'm not sure about the ins and outs here, so I'm going to add people who I think know more as well as post this bug to wikitech-l.
Started a thread for discussion of this on Wikitech-l: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60388
This bit was broken off of the thread but had important information: http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/60484
Right now I do not get what specifically that user asks. I am not even sure if he understands what he is talking about. Could you elaborate, please?
(In reply to comment #3) > Right now I do not get what specifically that user asks. I am not even sure if > he understands what he is talking about. Could you elaborate, please? In the past, all accounts were local. Users who still have local accounts can go to the page "Special:MergeAccount" at any WMF project whilst logged in to create an SUL account. Some users have not gone to "Special:MergeAccount" (possibly because SUL is unknown to these users). The proposal is to automatically do the "Special:MergeAccount" joining for the remaining users (as long as there are no conflicts). I don't see why there would be issues with indefinitely locked accounts. Some of them might only have been active on one project (in which case SUL would have no advantage but also no disadvantage as the user probably wouldn't start editing at other projects anyway, and they could just register for a local account if they wanted). Other users might have been active on multiple projects, and in that case SUL would give the advantage that the users could be globally locked.
(In reply to comment #4) > In the past, all accounts were local. Users who still have local accounts can > go to the page "Special:MergeAccount" at any WMF project whilst logged in to > create an SUL account. Some users have not gone to "Special:MergeAccount" > (possibly because SUL is unknown to these users). The proposal is to > automatically do the "Special:MergeAccount" joining for the remaining users (as > long as there are no conflicts). You cannot really merge accounts automatically, since you do not know whether all those users are the same users in different projects. The reason why we ask for password on Special:MergeAccount is that otherwise we cannot even check if two password hashes are the same, since they are hashed and salted (and each has a different salt). It is true that you could look for alternative criteria of equivalence like all accounts having the same confirmed email address, or check the password and do an auto-merge on login, or merge all single-wiki accounts, but I personally do not believe that the benefits of such a feature (which are not apparent to me) would outweigh its costs of implementation.
(In reply to comment #5) > (In reply to comment #4) > > In the past, all accounts were local. Users who still have local accounts can > > go to the page "Special:MergeAccount" at any WMF project whilst logged in to > > create an SUL account. Some users have not gone to "Special:MergeAccount" > > (possibly because SUL is unknown to these users). The proposal is to > > automatically do the "Special:MergeAccount" joining for the remaining users (as > > long as there are no conflicts). > > You cannot really merge accounts automatically, since you do not know whether > all those users are the same users in different projects. The reason why we ask > for password on Special:MergeAccount is that otherwise we cannot even check if > two password hashes are the same, since they are hashed and salted (and each > has a different salt). > > It is true that you could look for alternative criteria of equivalence like all > accounts having the same confirmed email address, or check the password and do > an auto-merge on login, or merge all single-wiki accounts, but I personally do > not believe that the benefits of such a feature (which are not apparent to me) > would outweigh its costs of implementation. This bug isn't suggesting that we automatically merge User:A on en.wp and User:A on de.wp automatically. It's suggesting that we automatically make User:A global if there is no User:A on de.wp, etc... Just like we do with new user creation.
Any updates on this one?
<blinks w00tingly>
This doesn't remotely block bug 36939. Noting that this is assigned to me and actually happening now.
I've lost track for when this is planned to be done and cannot find dates on https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement or https://meta.wikimedia.org/wiki/Help:Unified_login . Could somebody enlighten me?
(In reply to comment #10) > I've lost track for when this is planned to be done and cannot find dates on > https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement > or > https://meta.wikimedia.org/wiki/Help:Unified_login . Could somebody enlighten > me? I wondered too as I saw this change from "August 2013" to "sometime", so I asked James Forrester this week, but no reply up to now. Would love an answer.
(In reply to comment #11) > (In reply to comment #10) > > I've lost track for when this is planned to be done and cannot find dates on > > https://meta.wikimedia.org/wiki/Single_User_Login_finalisation_announcement > > or > > https://meta.wikimedia.org/wiki/Help:Unified_login . Could somebody enlighten > > me? > > I wondered too as I saw this change from "August 2013" to "sometime", so I > asked James Forrester this week, but no reply up to now. Would love an > answer. https://meta.wikimedia.org/w/index.php?title=Single_User_Login_finalisation_announcement&diff=5726233&oldid=5643305 (sorry, forgot to add the link)
WMF's Release manager told me that this is postponed to an unknown date, as currently https://meta.wikimedia.org/wiki/HTTPS binds resources.
(In reply to comment #13) > WMF's Release manager told me that this is postponed to an unknown date, as > currently https://meta.wikimedia.org/wiki/HTTPS binds resources. Thanks Greg for the update! Now that the most hectic phase of current [[m:HTTPS]] plans is over, could we get more information and maybe a little urgent work on this? Specifically, the biggest community concern is the lack of time after notifications. The notification system was already coded and notifications don't need 100.00 % perfect lists of affected users, so sending them should require little effort and make things much, much easier in a few weeks or months when resources will be found to actually implement the change.
(In reply to comment #14) > Thanks Greg for the update! Now that the most hectic phase of current > [[m:HTTPS]] plans is over, could we get more information and maybe a little > urgent work on this? There is a note at [[User talk:Jdforrester (WMF)#SUL Finalisation]] which suggests that it won't take place within "the next few weeks" (as of 28 September). Also, does the information in that discussion mean that this bug is assigned to the wrong person?
(In reply to comment #15) > Also, does the information in that discussion mean that this bug is > assigned to the wrong person? {{fixed}}
I'm wondering how hard it would be for some community member to run a database query and produce a partial list of accounts which will be interested by this unification, so that we can start warning them and avoid last-minute panic. The 114,604 local accounts (as of 2013-05-16) clashing with a global accounts look like ideal candidates for a first batch of community notifications.
dgarry: Any input / opinion on Nemo's last comment? Wondering how to move forward / what is currently blocking this ticket (and bug 39817).
(In reply to comment #19) > dgarry: Any input / opinion on Nemo's last comment? Wondering how to move > forward / what is currently blocking this ticket (and bug 39817). I saw something regarding global rename (and thus SUL unification) here: https://en.wikipedia.org/wiki/Wikipedia:Bureaucrats%27_noticeboard/Archive_29#CHU.2FS_.26_CHUU
(In reply to comment #19) > dgarry: Any input / opinion on Nemo's last comment? Wondering how to move > forward / what is currently blocking this ticket (and bug 39817). The blocker is basically me. I'm still new to product management and I need to sit down face to face with another product manager and be walked through this. Realistically this can't start until I'm relocated to San Francisco, which (fingers crossed) is next month.
(In reply to comment #17) > I'm wondering how hard it would be for some community member to run a > database query and produce a partial list of accounts which will be interested > by this unification, so that we can start warning them and avoid last-minute > panic. It would be fairly simple to generate such a list. My concern is that someone, acting in good faith, would take the list and notify tens of thousands of accounts and create a false panic, particularly before the ability to globally rename a user exists (bug 14862).
(In reply to comment #22) > (In reply to comment #17) > > I'm wondering how hard it would be for some community member to run a > > database query and produce a partial list of accounts which will be interested > > by this unification, so that we can start warning them and avoid last-minute > > panic. > > It would be fairly simple to generate such a list. My concern is that > someone, > acting in good faith, would take the list and notify tens of thousands of > accounts and create a false panic, particularly before the ability to > globally > rename a user exists (bug 14862). Hm? The sooner local accounts are renamed, the better.
Given that it's now about 7 months with no movement here, FYI I'm available to act as (volunteer) product manager for this if WMF people are too busy with other things. It's simpler for someone with years of experience in SUL as well as local, cross-wiki and global rename practices and otherwise (stewards are another group where it's easy to find such people).
I've got a plan afoot. Stay tuned for more information.
(In reply to Dan Garry from comment #25) > I've got a plan afoot. I don't believe you. > Stay tuned for more information. I don't want to stay tuned, I have limited battery. Just transmit.
(In reply to Dan Garry from comment #25) > I've got a plan afoot. "Before the game is afoot, thou still let'st slip."
(In reply to Nemo from comment #26) > (In reply to Dan Garry from comment #25) > > I've got a plan afoot. > > I don't believe you. Fortunately, this does not change my plans. :-)
And that probably means "Fortunately, this does not change my plans in any way that will result in the fixing of this bug prior to 2016." :-(
(In reply to Dan Garry from comment #25) > I've got a plan afoot. Stay tuned for more information. Bug 14862 is close to being resolved. Any news? https://wikitech.wikimedia.org/w/index.php?title=Deployments&oldid=116060#Next_month
(In reply to MF-Warburg from comment #29) > And that probably means "Fortunately, this does not change my plans in any > way that will result in the fixing of this bug prior to 2016." :-( Hey, that'll make it a nice round ten years of not being done. https://github.com/wikimedia/mediawiki-extensions-CentralAuth/commit/f34d746dd1133f42ad878c9ad3740148d6628c41#diff-78ccdd1419c89ebda99c7fe418fc64a1
Making this a proper tracking bug by blocking bug 2007 and adding the tracking keyword.
Just to followup re: timescales for the casual bugspam follower, it's looking more like the first quarter of 2015 for this than 2016 (source: Dan Garry).
Update assignee per https://www.mediawiki.org/w/index.php?title=SUL_finalisation&curid=210337&diff=1241446&oldid=1205612
