On 8/13/07, Jay R. Ashworth jra@baylink.com wrote:
DNS's multi-2ld shape is *precisely so that* 3ld's which are identical won't collide, since they fall under different administrative spheres of responsibility. Why should Ford Motor Co., the Ford Foundation, and the Ford Car Club of America *not* be able to be ford.com, ford.org and ford.us?
My analogy used .com/.org/.net, which were all run initially by network solutions. Were that still true today I don't think the analogy would be any better or worse. Again though, analogies aren't meant to be perfect. My purpose was to show how bad of an idea it is to merge multiple already overcrowded namespaces (namespace, in the [[namespace (computer science)]] sense). Maybe it was a bad analogy though. I don't know.
A different situation pertains here: the WMF public wikis *do not* fall under separate administrative spheres, though I can understand the POV of some people who assert they might.
Count me under those who would say that the WMF wikis do fall under separate administrative spheres, actually.
There is a reasonable assumption that can be -- and clearly is -- made, by users, that the entire WMF is under one login namespace. [....]
I believe a random statistical sample of wikipedians not directly involved with SSO, and who don't have accounts on more than one wiki, would show a "believe that SSO's already there" rate much higher than you might think.
I think you're correct that a number of people do make this assumption. But I don't think that's an adequate reason to adopt a policy making it so.
I guess what has to happen before this can really be discussed is we need to drop the hypotheticals and come up with a semi-accurate list of actual conflicts. If a good portion of the conflicts are actually causing problems, then it's one thing. If most of them are just good faith collisions which wouldn't have even been discovered were it not for SUL, then it's another.
"Anthony" wikitech@inbox.org wrote in message news:71cd4dd90708131131k36ef2c17k39d1aae4234b7311@mail.gmail.com...
On 8/13/07, Jay R. Ashworth jra@baylink.com
wrote:
I guess what has to happen before this can really be discussed is we need to drop the hypotheticals and come up with a semi-accurate list of actual conflicts. If a good portion of the conflicts are actually causing problems, then it's one thing. If most of them are just good faith collisions which wouldn't have even been discovered were it not for SUL, then it's another.
As far as I am aware, the time for discussion ended months, if not a year ago, and now it is simply a matter of waiting for the implementation to be completed. If that is the case (and correct me if it isn't) then this whole conversation is somewhat pointless.
- Mark Clements (HappyDog)
On 13/08/07, Mark Clements gmane@kennel17.co.uk wrote:
As far as I am aware, the time for discussion ended months, if not a year ago, and now it is simply a matter of waiting for the implementation to be completed. If that is the case (and correct me if it isn't) then this whole conversation is somewhat pointless.
We are the Borg. Your login will be unified. Resistance is futile.
Rob Church
On 8/13/07, Mark Clements gmane@kennel17.co.uk wrote:
"Anthony" wikitech@inbox.org wrote in message news:71cd4dd90708131131k36ef2c17k39d1aae4234b7311@mail.gmail.com...
On 8/13/07, Jay R. Ashworth jra@baylink.com
wrote:
I guess what has to happen before this can really be discussed is we need to drop the hypotheticals and come up with a semi-accurate list of actual conflicts. If a good portion of the conflicts are actually causing problems, then it's one thing. If most of them are just good faith collisions which wouldn't have even been discovered were it not for SUL, then it's another.
As far as I am aware, the time for discussion ended months, if not a year ago, and now it is simply a matter of waiting for the implementation to be completed. If that is the case (and correct me if it isn't) then this whole conversation is somewhat pointless.
Considering that until a few weeks ago I (who follow the relevant mailing lists rather closely) didn't even know what exactly SUL was, I have to say that I don't think that is the case. A great many people right now still don't know what this whole SUL thing means. The documentation on it is inconsistent. Tons of misinformation is being spread.
When was this discussion period announced?
I don't think it's too late. It certainly won't be too late before user accounts start getting forcibly renamed, and even after that we could probably still change our minds.
On 13/08/07, Anthony wikitech@inbox.org wrote:
Considering that until a few weeks ago I (who follow the relevant mailing lists rather closely) didn't even know what exactly SUL was, I have to say that I don't think that is the case. A great many people right now still don't know what this whole SUL thing means. The documentation on it is inconsistent. Tons of misinformation is being spread.
Wasn't the Communications Committee supposed to ensure that users were advised of what would happen?
"Single user login" has been discussed and agonised about for a long period of time, on mailing lists, on Meta, and at Wikimania. It's been discussed in presentations at the previous two conferences, at least, for example.
If there is a lack of communication, then it's not the fault of the development team, it's the fault of the group which was tasked with communicating. If there is no such group, then the blame rests higher. That there are large numbers of long-term users who, at this time, still don't know the precise facts (not the rumours) about it, well, that screams "unacceptable" to me.
Rob Church
On 8/13/07, Rob Church robchur@gmail.com wrote:
On 13/08/07, Anthony wikitech@inbox.org wrote:
Considering that until a few weeks ago I (who follow the relevant mailing lists rather closely) didn't even know what exactly SUL was, I have to say that I don't think that is the case. A great many people right now still don't know what this whole SUL thing means. The documentation on it is inconsistent. Tons of misinformation is being spread.
Wasn't the Communications Committee supposed to ensure that users were advised of what would happen?
"Single user login" has been discussed and agonised about for a long period of time, on mailing lists, on Meta, and at Wikimania. It's been discussed in presentations at the previous two conferences, at least, for example.
Looking back, I guess it was brought up in a number of places, and I'm not quite sure how I missed it. I don't remember it being discussed on any of the non-tech mailing lists though.
If there is a lack of communication, then it's not the fault of the development team, it's the fault of the group which was tasked with communicating. If there is no such group, then the blame rests higher.
I don't blame the development team for the lack of communication, though I will blame them if they push this change through.
That there are large numbers of long-term users who, at this time, still don't know the precise facts (not the rumours) about it, well, that screams "unacceptable" to me.
I'd say now would be a good time to go through the list of users that might potentially be affected, and email them all, and put a message on each of their talk pages. Then sit back and watch the complaints, and hopefully change your mind.
SUL doesn't have to happen.
On 8/13/07, Anthony wikitech@inbox.org wrote:
Looking back, I guess it was brought up in a number of places, and I'm not quite sure how I missed it. I don't remember it being discussed on any of the non-tech mailing lists though.
The closest thing I can find is an email from Erik entitled "Single login - decision 2004", from November 2004. But no decision seems to have been made at that time.
Rob Church schreef:
Wasn't the Communications Committee supposed to ensure that users were advised of what would happen?
Communication can only be done about things you know about. There has been no communication to the ComCom about SUL since a long time.
About certain things is known that there is something going on but nothing concrete. I know there was supposed to be announced/presented on Wikimania a new skin for the WMF wikis. How it looks like and of it was presented I do not know.
The Communications Committee is actually nothing more then a mailing list. What is not send to there is unknown.
On 13/08/07, Walter Vermeir walter@wikipedia.be wrote:
Communication can only be done about things you know about. There has been no communication to the ComCom about SUL since a long time.
If your remit is such that you are required to communicate things about a particular project, then it is within your responsibility to find that out, by asking questions, by doing research - the actual implementation plans are there, in Subversion, for anyone to see - as is the code - and by pestering the developer(s) concerned until you know everything you feel you need to.
Review his presentations, review his plans, hell - ask Brion for an interview if you think that you can compose the questions.
About certain things is known that there is something going on but nothing concrete. I know there was supposed to be announced/presented on Wikimania a new skin for the WMF wikis. How it looks like and of it was presented I do not know.
Who said this? Pester them. Pester the Board, since they would presumably know something about this.
The Communications Committee is actually nothing more then a mailing list. What is not send to there is unknown.
Then it sounds like the committee is malformed and needs to be created anew, with fresh volunteers, and with a proper understanding of what its purpose is. And as I suspected, the blame does lie higher.
Rob Church
On 8/13/07, Rob Church robchur@gmail.com wrote:
On 13/08/07, Walter Vermeir walter@wikipedia.be wrote:
About certain things is known that there is something going on but nothing concrete. I know there was supposed to be announced/presented on Wikimania a new skin for the WMF wikis. How it looks like and of it was presented I do not know.
Who said this? Pester them. Pester the Board, since they would presumably know something about this.
Not as far as I know, though one was announced for Wikia.
As for SUL, as far as I am aware there hasn't been anything major to announce in a long time. "Yep. Decision still on, work still ongoing," isn't something that merits a press release.
-Kat
On 8/13/07, Kat Walsh kat@mindspillage.org wrote:
As for SUL, as far as I am aware there hasn't been anything major to announce in a long time. "Yep. Decision still on, work still ongoing," isn't something that merits a press release.
It's not about a press release so much as it is about informing users about what is going on. There's actually been quite a bit of planning regarding the communication needs for a full roll-out. A number of people worked on this a couple of years ago: http://meta.wikimedia.org/wiki/Single_login_specifications (very outdated now)
For many different reasons, the project fell behind schedule and then fell entirely _off_ any schedule. I'm glad that progress is now being made, and this forces us to seriously think about what the communication needs are.
With a partial initial roll-out, the need to communicate is a bit simpler. I think it's fine to advertise the feature in stages, though I hope we can make the transition permanent within a reasonable timeframe.
Simply put, I suggest the following: 1) announce on a few mailing lists for initial public testing 2) announce in sitenotice and on special:userlogin for official opt-in migration 3) e-mail all remaining users at some point to inform about end of transition period.
Of course at least 2) and 3) require translation, but most of that should be relatively straightforward through the MediaWiki: namespace.
Rob Church schreef:
If your remit is such that you are required to communicate things about a particular project, then it is within your responsibility to find that out, by asking questions, by doing research - the actual implementation plans are there, in Subversion, for anyone to see - as is the code - and by pestering the developer(s) concerned until you know everything you feel you need to.
Review his presentations, review his plans, hell - ask Brion for an interview if you think that you can compose the questions.
I do not consider that my task. At least not as comcom member. As Wikizine editor I attempt to find out what what I can were I can. And that is not a lot.
Brion is the chief technical officer of the WMF. If there is anything that should be known regarding technical matters then it should be Brion who informs whoever he is supposed to inform. And then that will also be send to comcom I hope.
Besides that I have no good experience in asking something. Bug; 7197 , 8662 and 10098
Then it sounds like the committee is malformed and needs to be created anew, with fresh volunteers, and with a proper understanding of what its purpose is. And as I suspected, the blame does lie higher.
Rob Church
What I am supposed to do as comcom member has never become clear to me. I think that was one of first questions I raised in the comcom when it was created. What I actually do is to follow the postings on the comcom mailing list, give my opinion about certain things, if I discover something relevant inform the other comcom members about it. And report the news that find out from the comcom sources that is not confidential and I believe is relevant for the community in Wikizine. Like I believe the Signpost people also do.
Walter Vermeir wrote:
About certain things is known that there is something going on but nothing concrete. I know there was supposed to be announced/presented on Wikimania a new skin for the WMF wikis. How it looks like and of it was presented I do not know.
That wasn't so much a presenting of a new skin as presenting of a plan to have a committee work on a new skin, and a demo. :)
The Communications Committee is actually nothing more then a mailing list. What is not send to there is unknown.
It's *people* on a mailing list, hopefully. ;)
The skin thing is being done by some sort of marketing subcommittee which isn't very well known, either. Guillaume & Elian are working on it I believe?
Really that's not a tech issue at this time, though, but more of an ongoing process to see what we can and should do about unifying and clarifying the visual identity of our sites -- that is, making it easier to tell Wikimedia sites apart from non-Wikimedia sites while looking good and having good usability/accessibility.
I don't know if they have screenshots etc up at this time.... ok:
http://wikimania2007.wikimedia.org/wiki/Proceedings:GP1
http://upload.wikimedia.org/wikipedia/wikimania2007/0/0c/GPaumier-Visualiden...
-- brion vibber (brion @ wikimedia.org)
On 13/08/07, Brion Vibber brion@wikimedia.org wrote:
http://upload.wikimedia.org/wikipedia/wikimania2007/0/0c/GPaumier-Visualiden...
Couple of screenshots on slides 50 (Wikipedia) and 51 (Wikisource), illustrating the proposed per-project colour schemes.
I've got to admit, I do like the look of them; the per-project coloured bar appeals to me; it adds some individuality to each project, while the basic skin appearance remains consistent. I certainly agree that Wikimedia needs a distinct appearance; MonoBook is nice and clean, but ultimately, being the default, there's a ton of other MediaWiki wikis out there which all look the same.
The idea of a global navigation bar also seems like a good one to me.
Rob Church
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
Walter Vermeir wrote:
About certain things is known that there is something going on but nothing concrete. I know there was supposed to be announced/presented on Wikimania a new skin for the WMF wikis. How it looks like and of it was presented I do not know.
That wasn't so much a presenting of a new skin as presenting of a plan to have a committee work on a new skin, and a demo. :)
Heh, I'd forgotten about that-- largely because it didn't seem there was anything to announce, just some brainstorming a and proposals about possible things to do, that no one else had seen yet.
-Kat
On 13/08/07, Rob Church robchur@gmail.com wrote:
Wasn't the Communications Committee supposed to ensure that users were advised of what would happen? If there is a lack of communication, then it's not the fault of the development team, it's the fault of the group which was tasked with communicating. If there is no such group, then the blame rests higher. That there are large numbers of long-term users who, at this time, still don't know the precise facts (not the rumours) about it, well, that screams "unacceptable" to me.
You tell us what's happening, we'll tell the world! We don't know a damn thing either. We woulda thought "ask the devs."
So. What's happening with SUL?
alternate answer: You want the job? It's yours! So, Rob. What's your publicity programme? I'm particularly interested in your sources for the information in question.
(Getting internal information bearing a close resemblance to pulling teeth is an ongoing problem for the comcom; you aren't helping with this shit.)
- d.
On 13/08/07, David Gerard dgerard@gmail.com wrote:
You tell us what's happening, we'll tell the world! We don't know a damn thing either. We woulda thought "ask the devs."
So. What's happening with SUL?
Quoting Brion, from his earlier post in this thread:
"Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks."
I concede the point, however.
Rob Church
On Monday 13 August 2007 22:27:52 Rob Church wrote:
On 13/08/07, David Gerard dgerard@gmail.com wrote:
You tell us what's happening, we'll tell the world! We don't know a damn thing either. We woulda thought "ask the devs."
So. What's happening with SUL?
Quoting Brion, from his earlier post in this thread:
"Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks."
Unfortunately, when I try to login, it tells me "there is no such user "tels"' or Tels.
So, how can I actually use that check to see if my "other" "tels" accounts on various mediawiki/wikimedia/wikipedia sites/whatever are the same or not or cause problems?
*confused*
Tels
You have to create an account on test.wikipedia.org first if you haven't alread.y. :-)
On 8/14/07, Tels nospam-abuse@bloodgate.com wrote:
On Monday 13 August 2007 22:27:52 Rob Church wrote:
On 13/08/07, David Gerard dgerard@gmail.com wrote:
You tell us what's happening, we'll tell the world! We don't know a damn thing either. We woulda thought "ask the devs."
So. What's happening with SUL?
Quoting Brion, from his earlier post in this thread:
"Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks."
Unfortunately, when I try to login, it tells me "there is no such user "tels"' or Tels.
So, how can I actually use that check to see if my "other" "tels" accounts on various mediawiki/wikimedia/wikipedia sites/whatever are the same or not or cause problems?
*confused*
Tels
-- Signed on Tue Aug 14 20:59:10 2007 with key 0x93B84C15. Get one of my photo posters: http://bloodgate.com/posters PGP key on http://bloodgate.com/tels.asc or per email.
" ...the Machholz Comet is named after the guy who really discovered it. Bob Comet."
-- Zathras26 (763537) on 2005-01-01 at /.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
It definitely took place ages ago, read the Meta page on it.
On 8/13/07, Anthony wikitech@inbox.org wrote:
On 8/13/07, Mark Clements gmane@kennel17.co.uk wrote:
"Anthony" wikitech@inbox.org wrote in message news:71cd4dd90708131131k36ef2c17k39d1aae4234b7311@mail.gmail.com
...
On 8/13/07, Jay R. Ashworth jra@baylink.com
wrote:
I guess what has to happen before this can really be discussed is we need to drop the hypotheticals and come up with a semi-accurate list of actual conflicts. If a good portion of the conflicts are actually causing problems, then it's one thing. If most of them are just good faith collisions which wouldn't have even been discovered were it not for SUL, then it's another.
As far as I am aware, the time for discussion ended months, if not a
year
ago, and now it is simply a matter of waiting for the implementation to
be
completed. If that is the case (and correct me if it isn't) then this
whole
conversation is somewhat pointless.
Considering that until a few weeks ago I (who follow the relevant mailing lists rather closely) didn't even know what exactly SUL was, I have to say that I don't think that is the case. A great many people right now still don't know what this whole SUL thing means. The documentation on it is inconsistent. Tons of misinformation is being spread.
When was this discussion period announced?
I don't think it's too late. It certainly won't be too late before user accounts start getting forcibly renamed, and even after that we could probably still change our minds.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
[snip] I've put Anthony on moderation, I'm tired of his trolling.
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
-- brion vibber (brion @ wikimedia.org)
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
[snip] I've put Anthony on moderation, I'm tired of his trolling.
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
-- brion vibber (brion @ wikimedia.org)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
I wasn't aware that we were this close, I have still been using this along with [[Special:Electroshock]] as a joke as recently as last week - excellent jobs, developers, and I'll go have a look at the demo!
On 13/08/07, Dan Collins en.wp.st47@gmail.com wrote:
I wasn't aware that we were this close, I have still been using this along with [[Special:Electroshock]] as a joke as recently as last week - excellent jobs, developers, and I'll go have a look at the demo!
The joke's on you! [[Special:LART]] and [[Special:Electroshock]] are both (non-committed) extensions, and have been for six months.
Rob Church
Rob Church wrote:
On 13/08/07, Dan Collins en.wp.st47@gmail.com wrote:
I wasn't aware that we were this close, I have still been using this along with [[Special:Electroshock]] as a joke as recently as last week - excellent jobs, developers, and I'll go have a look at the demo!
The joke's on you! [[Special:LART]] and [[Special:Electroshock]] are both (non-committed) extensions, and have been for six months.
ORLY? Those sound like fun: linky plz ;-)
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
I've put Anthony on moderation, I'm tired of his trolling.
That's completely obnoxious. Disagreeing with one of the moderators is not trolling.
On 8/13/07, Anthony wikitech@inbox.org wrote:
That's completely obnoxious. Disagreeing with one of the moderators is not trolling.
Probably not, but at this point the decision is effectively irreversible, barring a *really* big backlash (which I very much doubt we'll be seeing). Quite a lot of work has been done on it and most people seem to think it's a great idea.
On 8/13/07, Rob Church robchur@gmail.com wrote:
Neat, it's even identified MediaWiki.org as my home wiki. As it should be.
Me too. I'm betting it notices if you're a bureaucrat, then falls back to sysop, then edit count, or something like that. I hadn't realized we were this far along either, having become a bit desensitized to the overoptimistic DoA's that have been released in the past. Neat.
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/13/07, Anthony wikitech@inbox.org wrote:
That's completely obnoxious. Disagreeing with one of the moderators is not trolling.
Probably not, but at this point the decision is effectively irreversible, barring a *really* big backlash (which I very much doubt we'll be seeing). Quite a lot of work has been done on it and most people seem to think it's a great idea.
Fair enough, I still don't think that's a valid reason to put me on moderation or to call me a troll.
If I'm not permitted to question this decision (to implement checkuser) on this mailing list, then I will abide by that.
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/13/07, Anthony wikitech@inbox.org wrote:
That's completely obnoxious. Disagreeing with one of the moderators is not trolling.
Probably not, but at this point the decision is effectively irreversible, barring a *really* big backlash (which I very much doubt we'll be seeing). Quite a lot of work has been done on it and most people seem to think it's a great idea.
Fair enough, I still don't think that's a valid reason to put me on moderation or to call me a troll.
If I'm not permitted to question this decision (to implement SUL) on this mailing list, and a moderator tells me so, then I will abide by that. There's no need to put me on moderation to accomplish that.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Anthony wrote:
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/13/07, Anthony wikitech@inbox.org wrote:
That's completely obnoxious. Disagreeing with one of the moderators is not trolling.
Probably not, but at this point the decision is effectively irreversible, barring a *really* big backlash (which I very much doubt we'll be seeing). Quite a lot of work has been done on it and most people seem to think it's a great idea.
Fair enough, I still don't think that's a valid reason to put me on moderation or to call me a troll.
If I'm not permitted to question this decision (to implement SUL) on this mailing list, and a moderator tells me so, then I will abide by that. There's no need to put me on moderation to accomplish that.
You're welcome to question decisions, but I'd rather that discussions remain relatively civil and productive.
Having seen plenty of foundation-l threads involving you, and seeing this thread go the same direction -- fast pace, high tempers, strong words, and not really productive for anybody -- I figured it would help to impose a little cool-down period.
FWIW, I think there will be a really big backlash, and from what I've heard the whole reason it's taken over 3 years to implement is precisely because a lot of people don't think it's a great idea.
It's taken a long time because there have been other priorities, and the original spec was for a single massive site-wide merging process which had to do everyone at once, which meant it had to be perfect ahead of time.
We've gotten a lot of other issues sorted out over the last year, and I've respecced the merge process to work on an opt-in basis per-username which allows a graceful beta period for more feedback as we refine the process.
Of course there are legitimate differences of opinion about what's the best way to set up a global account system, but ultimately we had to pick one and stick to it. The one that's been picked was formalizing and codifying the existing tradition that people use the same username on multiple wikis -- which is by far the simplest thing when dealing with an integrated site family like this, where for instance we point people at Commons or Meta all the time.
A few people will be bitten, yes, but we'll all just have to live with it, just as we'd have to live with the much greater constant pain of having a wildly inconsistent username space if we didn't do this.
- -- brion vibber (brion @ wikimedia.org)
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/13/07, Anthony wikitech@inbox.org wrote:
That's completely obnoxious. Disagreeing with one of the moderators is not trolling.
Probably not, but at this point the decision is effectively irreversible, barring a *really* big backlash (which I very much doubt we'll be seeing). Quite a lot of work has been done on it and most people seem to think it's a great idea.
FWIW, I think there will be a really big backlash, and from what I've heard the whole reason it's taken over 3 years to implement is precisely because a lot of people don't think it's a great idea.
I can see how the fact that me criticizing something that people have spent so much effort on might hurt some feelings, but I think these things have to be said anyway.
Moin,
On Monday 13 August 2007 21:56:29 Anthony wrote:
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
On 8/13/07, Anthony wikitech@inbox.org wrote:
That's completely obnoxious. Disagreeing with one of the moderators is not trolling.
Probably not, but at this point the decision is effectively irreversible, barring a *really* big backlash (which I very much doubt we'll be seeing). Quite a lot of work has been done on it and most people seem to think it's a great idea.
FWIW, I think there will be a really big backlash, and from what I've heard the whole reason it's taken over 3 years to implement is precisely because a lot of people don't think it's a great idea.
I can see how the fact that me criticizing something that people have spent so much effort on might hurt some feelings, but I think these things have to be said anyway.
Just for what it's worth, I am *waiting* for SUL so I can stop having to have to register on every little wikimedia project again and again and again...
all the best,
Tels
On 13/08/07, Brion Vibber brion@wikimedia.org wrote:
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
Neat, it's even identified MediaWiki.org as my home wiki. As it should be.
Rob Church
On Mon, 13 Aug 2007 15:23:57 -0400, Brion Vibber wrote:
[snip] I've put Anthony on moderation, I'm tired of his trolling.
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
-- brion vibber (brion @ wikimedia.org)
It seems to work, although the instructions are a bit unclear. In my case, my password on test didn't match the others, so it just gave a link to my wikipedia user page, and didn't tell how to proceed. Once I changed my test password it worked.
Steve Sanbeg wrote:
It seems to work, although the instructions are a bit unclear. In my case, my password on test didn't match the others, so it just gave a link to my wikipedia user page, and didn't tell how to proceed. Once I changed my test password it worked.
Hmm yes, that needs a little clarification. :)
What it should be doing is directing you straight to the merge page on the other wiki, I think.
-- brion vibber (brion @ wikimedia.org)
Hoi, I have so many users that ARE matched that I would not miss some profiles in others. It would be good to know if there are profiles with the same name that have NOT been merged.. with an indication why not I can go there and fix this up. Alternatively it could be that I can authenticate myself to this other wiki and make it part of the ones that will be matched. Thanks, GerardM
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
Steve Sanbeg wrote:
It seems to work, although the instructions are a bit unclear. In my case, my password on test didn't match the others, so it just gave a
link
to my wikipedia user page, and didn't tell how to proceed. Once I
changed
my test password it worked.
Hmm yes, that needs a little clarification. :)
What it should be doing is directing you straight to the merge page on the other wiki, I think.
-- brion vibber (brion @ wikimedia.org)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8/13/07, GerardM gerard.meijssen@gmail.com wrote:
I have so many users that ARE matched that I would not miss some profiles in others. It would be good to know if there are profiles with the same name that have NOT been merged.. with an indication why not I can go there and fix this up. Alternatively it could be that I can authenticate myself to this other wiki and make it part of the ones that will be matched.
When I tried it, my Meta account had a different password than the others. It was listed separately, saying that if I knew its password I should enter it to have it merged too, otherwise it would be left alone for now and it would be worked out later. Something like that. It worked nicely.
Simetrical-3 wrote:
On 8/13/07, GerardM gerard.meijssen@gmail.com wrote:
I have so many users that ARE matched that I would not miss some profiles in others. It would be good to know if there are profiles with the same name that have NOT been merged.. with an indication why not I can go there and fix this up. Alternatively it could be that I can authenticate myself to this other wiki and make it part of the ones that will be matched.
When I tried it, my Meta account had a different password than the others. It was listed separately, saying that if I knew its password I should enter it to have it merged too, otherwise it would be left alone for now and it would be worked out later. Something like that. It worked nicely.
Same here, for that particular situation.
However, I want to know how to handle another problem I have: at least one of my accounts is named slightly differently. I'm [[user:Phil Boswell]] nearly everywhere, but on Meta for one, I'm [[user:PhilBoswell]] (i.e. CamelCase). I didn't notice any option for specifying further accounts with different names to be unified.
On 8/14/07, Phil Boswell phil.boswell@gmail.com wrote:
However, I want to know how to handle another problem I have: at least one of my accounts is named slightly differently. I'm [[user:Phil Boswell]] nearly everywhere, but on Meta for one, I'm [[user:PhilBoswell]] (i.e. CamelCase). I didn't notice any option for specifying further accounts with different names to be unified.
Brion said above, in response to the same question by Werdna ("is there an opportunity to add differently-named accounts?"):
Not at the moment. We'll consider the issues relating to user-directed merging of different account names, though, since some people will find it useful.
There are currently no plans to allow multiple names on different wikis for the same account, so your odd account will need to be renamed (as will my Hebrew-alphabet Simetrical on hewiki).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Phil Boswell wrote:
However, I want to know how to handle another problem I have: at least one of my accounts is named slightly differently. I'm [[user:Phil Boswell]] nearly everywhere, but on Meta for one, I'm [[user:PhilBoswell]] (i.e. CamelCase). I didn't notice any option for specifying further accounts with different names to be unified.
You can have the account renamed to match -- ask any bureaucrat. :)
- -- brion vibber (brion @ wikimedia.org)
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
[snip] I've put Anthony on moderation, I'm tired of his trolling.
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
Where is the correct place for feedback?
The automatic home wiki selector is fairly smart, but it's not always right. It would be nice if you were given a drop down with the automatic selection selected by default. Otherwise I think we may often end up with "thats not my home wiki! <back> now what?!".
On 13/08/07, Gregory Maxwell gmaxwell@gmail.com wrote:
Where is the correct place for feedback?
I've created a BugZilla component:
Product: MediaWiki extensions Component: CentralAuth
Rob Church
Gregory Maxwell wrote:
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
Where is the correct place for feedback?
Here is fine for now. It'll be progressively more opened up as we go into private, then opt-in beta, and then general availability. During that progress we'll all be fixing things up and figuring out how to best 'advertise' and document it -- something that's very difficult until we've had people really trying it out.
The automatic home wiki selector is fairly smart, but it's not always right. It would be nice if you were given a drop down with the automatic selection selected by default. Otherwise I think we may often end up with "thats not my home wiki! <back> now what?!".
*nod*
As discussed in the Q&A session at Wikimania, the home wiki will be user-selectable. I hadn't quite gotten that far when polishing up the live test for public demoing, though.
(Are videos from the Wikimania sessions available online yet? I'm a little lost on how that was supposed to work.)
-- brion vibber (brion @ wikimedia.org)
You need to have the same password on the site running Special:MergeAccount and the home wiki, even having the same confirmed email on both. While "going there" is fine for release, having to change the password for testing is not so nice. The message is not clear which password is asked on Special:MergeAccount. Testing shows it accepts both the site-password and the home wiki password, so instead of "log in there", you should tell "or provide its password in the previous step" and give another passsword box. Correction: You must fill the site password, get a notification about the home wiki account, go back, put the home wiki password and then works. Putting the home wiki password directly doesn't. Non-home wiki passwords tried, will be tried to create the list of attached accounts.
I also hit a bug on myself when not all accounts matched the email. I capitalised first-letter on some of them and not on anothers. Luckily, i only needed to identify to a second wiki to merge the full second block.
This is correct rfc behaviour, the user name part of the email address must be left unchanged, only the system storing it can perform case-transformations on it, as opposed to the host, which should be lower case, but as most email providers are cese-insensitive (is anyone case-sensitive?) and people *will* make this kind of mistakes, having a list of well-known providers which ignore case and are used by 90% of wikimedians (hotmail, gmail, yahoo, aol?) seems worth to. No case transformations are being done on the host, so should be which done the above fixing :)
Finally, thanks, thanks & thanks, Brion. At last, we can feel SUL near.
On Tue, Aug 14, 2007 at 12:02:54AM +0200, Platonides wrote:
I also hit a bug on myself when not all accounts matched the email. I capitalised first-letter on some of them and not on anothers. Luckily, i only needed to identify to a second wiki to merge the full second block.
This is correct rfc behaviour, the user name part of the email address must be left unchanged, only the system storing it can perform case-transformations on it, as opposed to the host, which should be lower case, but as most email providers are cese-insensitive (is anyone case-sensitive?)
Per the spec: LHSs of mailbox names have case sensitivity that is implementation-dependent and must be treated as case-sensitive.
RHSs of mailbox names are -- these days -- domain names, and domain names are case insensitive by their spec.
RFC 2822 and 1136, I think.
Cheers, -- jra
Jay R. Ashworth wrote:
On Tue, Aug 14, 2007 at 12:02:54AM +0200, Platonides wrote:
I also hit a bug on myself when not all accounts matched the email. I capitalised first-letter on some of them and not on anothers. Luckily, i only needed to identify to a second wiki to merge the full second block.
This is correct rfc behaviour, the user name part of the email address must be left unchanged, only the system storing it can perform case-transformations on it, as opposed to the host, which should be lower case, but as most email providers are cese-insensitive (is anyone case-sensitive?)
Per the spec: LHSs of mailbox names have case sensitivity that is implementation-dependent and must be treated as case-sensitive.
RHSs of mailbox names are -- these days -- domain names, and domain names are case insensitive by their spec.
Well, that's what i said, or at least intended to. Then i proposed having a list of common domain names which implement mailbox names case insensitive, to compare its emails as such.
RFC 2822 and 1136, I think.
My think is that they're 821 and 2821 :-)
On Tue, Aug 14, 2007 at 08:10:53PM +0200, Platonides wrote:
This is correct rfc behaviour, the user name part of the email address must be left unchanged, only the system storing it can perform case-transformations on it, as opposed to the host, which should be lower case, but as most email providers are cese-insensitive (is anyone case-sensitive?)
Per the spec: LHSs of mailbox names have case sensitivity that is implementation-dependent and must be treated as case-sensitive.
RHSs of mailbox names are -- these days -- domain names, and domain names are case insensitive by their spec.
Well, that's what i said, or at least intended to.
I misunderstood you to be talking about RHSs. LHSs *must* be treated as case-sensitive, regardless how many providers don't actually do it that way.
RFC 2822 and 1136, I think.
My think is that they're 821 and 2821 :-)
The case-insensitivity of RHSs devolves from the DNS RFCs, so neither 2821 nor 2822. RFC 1035, actually, s 2.3.3.
Cheers, -- jra
Jay R. Ashworth wrote:
I misunderstood you to be talking about RHSs. LHSs *must* be treated as case-sensitive, regardless how many providers don't actually do it that way.
Without any other data, they must. That's why i'm proposing it as a list of providers, rather than on a global basis. If we positively know that they're internaly case-insensitive, and treating them as such will make life easier for our users. Why not do it?
RFC 2822 and 1136, I think.
My think is that they're 821 and 2821 :-)
The case-insensitivity of RHSs devolves from the DNS RFCs, so neither 2821 nor 2822. RFC 1035, actually, s 2.3.3.
RFC 1035 is from November 1987.
RFC 821 (August 1982), section 2; Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive.
On Tue, Aug 14, 2007 at 09:40:27PM +0200, Platonides wrote:
Jay R. Ashworth wrote:
I misunderstood you to be talking about RHSs. LHSs *must* be treated as case-sensitive, regardless how many providers don't actually do it that way.
Without any other data, they must. That's why i'm proposing it as a list of providers, rather than on a global basis. If we positively know that they're internaly case-insensitive, and treating them as such will make life easier for our users. Why not do it?
Because you *can't* 'positively' know for any other time but right now... and more importantly, because as you quote, conveniently:
RFC 821 (August 1982), section 2; Commands and replies are not case sensitive. That is, a command or reply word may be upper case, lower case, or any mixture of upper and lower case. Note that this is not true of mailbox user names. For some hosts the user name is case sensitive, and SMTP implementations must take case to preserve the case of user names as they appear in mailbox arguments. Host names are not case sensitive.
the RFC says you have to. More specifically, it defines the semantics of an Internet email address, and that's the item you're ... oh.
You're talking about for matching purposes. I'm sorry; I'm kind of slow today.
I understand both sides of this argument, and while the spec really says that you can't do it that way, any administrator who assigns root and Root to 2 different mailboxes should be boiled in oil, hung, shot, drawn and quartered, and the pieces arrested.
So yeah, why not? :-)
Cheers, -- jra
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
Two issues: 1. So many people are trying it out, that test.wikipedia.org is slowing down to ridiculously slow levels. 2. Is there an opportunity to ask for differently-named accounts to be added to the mix (i.e. I have 'Werdna648' on meta, can I add that into the accounts to be merged?).
Probably asked before (or written somewhere)..but.. when someone renames an account of user x on y wiki, Will it be renamed automatically on all other wikis in which they have started their account?
Btw, great work!
Andrew Garrett wrote:
- Is there an opportunity to ask for differently-named accounts to be
added to the mix (i.e. I have 'Werdna648' on meta, can I add that into the accounts to be merged?).
The evil plans say: Are not trying to achieve ever: * Different usernames on each wiki
So you probably need to get renamed first to the main name.
Mohamed Magdy wrote:
Probably asked before (or written somewhere)..but.. when someone renames an account of user x on y wiki, Will it be renamed automatically on all other wikis in which they have started their account?
You're only renamed on wiki y. Renaming will probably be disabled for attached accounts.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Platonides wrote:
Mohamed Magdy wrote:
Probably asked before (or written somewhere)..but.. when someone renames an account of user x on y wiki, Will it be renamed automatically on all other wikis in which they have started their account?
You're only renamed on wiki y. Renaming will probably be disabled for attached accounts.
As it works at the moment, only unattached accounts can be renamed, and that's done locally.
I'd like to simplify user-renaming issues in general; self-directed renaming (with appropriate limits) would reduce bureaucratic pressure. This could work on the global-account level as well.
- -- brion vibber (brion @ wikimedia.org)
On 8/14/07, Platonides Platonides@gmail.com wrote:
The evil plans say: Are not trying to achieve ever: * Different usernames on each wiki
So you probably need to get renamed first to the main name.
Personally I dislike that provision. It means that no one who wants to use their account on (for instance) enwiki can use a non-Latin name *anywhere*, unless they use two Single-Login accounts (heh). But I'm not quite motivated enough to offer to set up a "local alias"-type system, so I guess I can just shut up about it. :)
Simetrical-3 wrote:
On 8/14/07, Platonides Platonides@gmail.com wrote:
The evil plans say: Are not trying to achieve ever: * Different usernames on each wiki So you probably need to get renamed first to the main name.
Personally I dislike that provision. It means that no one who wants to use their account on (for instance) enwiki can use a non-Latin name *anywhere*, unless they use two Single-Login accounts (heh).
Why ever not?
There has been some noise recently about people using non-Latin scripts who have fallen foul of over-anxious complainants worried that the names might be saying something rude in the non-English language to which they belong, but AFAIK there is no hard-and-fast rule.
Given that these names, once SUL arrives, will be subject to inspection by people who are familiar with the language in question, and will be able to spot rudeness and silliness just as easily as enwiki admins today can spot attempts to register [[User:I woke up naked in a vat of marshmallow topping]] who apparently rolled by a short while ago, the problem will be solved by the good old "many eyes" solution we are so fond of.
HTH HAND
On 8/14/07, Phil Boswell phil.boswell@gmail.com wrote:
Simetrical-3 wrote:
Personally I dislike that provision. It means that no one who wants to use their account on (for instance) enwiki can use a non-Latin name *anywhere*, unless they use two Single-Login accounts (heh).
Why ever not?
There has been some noise recently about people using non-Latin scripts who have fallen foul of over-anxious complainants worried that the names might be saying something rude in the non-English language to which they belong, but AFAIK there is no hard-and-fast rule.
Ah, it seems it was changed a bit:
Users with non-Latin usernames are welcome to edit in Wikipedia. However, scripts of non-Latin languages (such as Arabic, Armenian, Chinese, Cyrillic, Greek, Hebrew, Hindi, Japanese, Korean, Thai and others) are illegible to most other contributors of the English Wikipedia. As a courtesy to the rest of the contributors, users with such usernames are encouraged to help them navigate by means of Latin signatures, Latin user redirects, and an explanation on their userpage. http://en.wikipedia.org/wiki/Wikipedia:Username_policy#Non-Latin_usernames
Last I heard, which may have been some months ago, non-Latin usernames were being flat-out blocked on sight. Not because they might be offensive or anything, but because English-speaking admins would be unable to tell them apart in the event of vandalism, etc. There was a big fuss about it from some non-Latin-alphabet-using wikis. The current wording seems like a good compromise to me, and should make this not so much of an issue. But it would still be nice for people to be able to contribute in local-language usernames if desired, IMO. Not, in any case, a blocker feature: get it working first. :)
Ah, it seems it was changed a bit:
Users with non-Latin usernames are welcome to edit in Wikipedia. However, scripts of non-Latin languages (such as Arabic, Armenian, Chinese, Cyrillic, Greek, Hebrew, Hindi, Japanese, Korean, Thai and others) are illegible to most other contributors of the English Wikipedia. As a courtesy to the rest of the contributors, users with such usernames are encouraged to help them navigate by means of Latin signatures, Latin user redirects, and an explanation on their userpage. http://en.wikipedia.org/wiki/Wikipedia:Username_policy#Non-Latin_usernames
Last I heard, which may have been some months ago, non-Latin usernames were being flat-out blocked on sight. Not because they might be offensive or anything, but because English-speaking admins would be unable to tell them apart in the event of vandalism, etc. There was a big fuss about it from some non-Latin-alphabet-using wikis. The current wording seems like a good compromise to me, and should make this not so much of an issue. But it would still be nice for people to be able to contribute in local-language usernames if desired, IMO. Not, in any case, a blocker feature: get it working first. :)
I hadn't noticed that change either. It's a good one, though. The main issue I have with non-Latin names is that I can't pronounce them. Reading something with unpronounceable words in is much slower than it otherwise would be, since one keeps tripping up over the words. Latin signatures fixes that pretty much completely. There is nothing wrong with names in a foreign languages, it's just foreign scripts which are a problem, all users need to do is transliterate their username as a sig..
On 8/14/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Ah, it seems it was changed a bit:
Users with non-Latin usernames are welcome to edit in Wikipedia. However, scripts of non-Latin languages (such as Arabic, Armenian, Chinese, Cyrillic, Greek, Hebrew, Hindi, Japanese, Korean, Thai and others) are illegible to most other contributors of the English Wikipedia. As a courtesy to the rest of the contributors, users with such usernames are encouraged to help them navigate by means of Latin signatures, Latin user redirects, and an explanation on their userpage. <
http://en.wikipedia.org/wiki/Wikipedia:Username_policy#Non-Latin_usernames
Last I heard, which may have been some months ago, non-Latin usernames were being flat-out blocked on sight. Not because they might be offensive or anything, but because English-speaking admins would be unable to tell them apart in the event of vandalism, etc. There was a big fuss about it from some non-Latin-alphabet-using wikis. The current wording seems like a good compromise to me, and should make this not so much of an issue. But it would still be nice for people to be able to contribute in local-language usernames if desired, IMO. Not, in any case, a blocker feature: get it working first. :)
I hadn't noticed that change either. It's a good one, though. The main issue I have with non-Latin names is that I can't pronounce them. Reading something with unpronounceable words in is much slower than it otherwise would be, since one keeps tripping up over the words. Latin signatures fixes that pretty much completely. There is nothing wrong with names in a foreign languages, it's just foreign scripts which are a problem, all users need to do is transliterate their username as a sig..
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
How will the new users log work: whenever a new global account is created, or only once the account is 'activated' on the local wiki? ~~~~
On 15/08/07, Dan Collins en.wp.st47@gmail.com wrote:
How will the new users log work: whenever a new global account is created, or only once the account is 'activated' on the local wiki? ~~~~
If the extension isn't changed from its current state, then it will continue to report (explicit) account creations for the local wiki.
Perhaps the better question is, "how should the log work"?
Rob Church
Rob Church wrote:
On 15/08/07, Dan Collins en.wp.st47@gmail.com wrote:
How will the new users log work: whenever a new global account is created, or only once the account is 'activated' on the local wiki? ~~~~
If the extension isn't changed from its current state, then it will continue to report (explicit) account creations for the local wiki.
Perhaps the better question is, "how should the log work"?
Marking on the local log only local activations and global creations on an specific log (at meta?) is imho right. But the global one should also give some hint about the project from which the global creation came, for the easyness of reviewing.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Platonides wrote:
Rob Church wrote:
On 15/08/07, Dan Collins en.wp.st47@gmail.com wrote:
How will the new users log work: whenever a new global account is created, or only once the account is 'activated' on the local wiki? ~~~~
If the extension isn't changed from its current state, then it will continue to report (explicit) account creations for the local wiki.
Perhaps the better question is, "how should the log work"?
Marking on the local log only local activations and global creations on an specific log (at meta?) is imho right. But the global one should also give some hint about the project from which the global creation came, for the easyness of reviewing.
Probably sensible. A link to the home wiki would do the job, probably?
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber wrote:
Platonides wrote:
Rob Church wrote:
On 15/08/07, Dan Collins en.wp.st47@gmail.com wrote:
How will the new users log work: whenever a new global account is created, or only once the account is 'activated' on the local wiki? ~~~~
If the extension isn't changed from its current state, then it will continue to report (explicit) account creations for the local wiki.
Perhaps the better question is, "how should the log work"?
Marking on the local log only local activations and global creations on an specific log (at meta?) is imho right. But the global one should also give some hint about the project from which the global creation came, for the easyness of reviewing.
Probably sensible. A link to the home wiki would do the job, probably?
Yes. I understand a home wiki account is created at the same time than the global one, then?
On 8/15/07, Rob Church robchur@gmail.com wrote:
On 15/08/07, Dan Collins en.wp.st47@gmail.com wrote:
How will the new users log work: whenever a new global account is
created,
or only once the account is 'activated' on the local wiki? ~~~~
If the extension isn't changed from its current state, then it will continue to report (explicit) account creations for the local wiki.
Perhaps the better question is, "how should the log work"?
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well, it ''should'' show the account as soon as it's blockable, and not before, otherwise you could register "RobChurchSucks" on some obscure wiki and we'd see it, be unable to block it, and forget about it.
I'm assuming that autoconfirmation is also on a per-wiki basis?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Dan Collins wrote:
I'm assuming that autoconfirmation is also on a per-wiki basis?
Yep.
- -- brion vibber (brion @ wikimedia.org)
Is it blockable as soon as it is used on a wiki, or as soon as it's registered? On enwiki, usernames deemed inappropriate are blocked on sight (mostly) - would this make that impossible, and make it so we have to wait until it edits (at which point, the potentially obscene name is permanently in the edit history).
My main question is, what is the definition of "blockable". Is that as soon as it is globally registered, or as soon as they edit on a particular wiki they can be blocked on it?
-Matt
From: "Dan Collins" en.wp.st47@gmail.com Reply-To: Wikimedia developers wikitech-l@lists.wikimedia.org To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] SUL Date: Wed, 15 Aug 2007 16:25:07 -0400 MIME-Version: 1.0 Received: from lists.wikimedia.org ([145.97.39.157]) by bay0-mc10-f23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Wed, 15 Aug 2007 13:25:17 -0700 Received: from localhost ([127.0.0.1]:54553 helo=lily.knams.wikimedia.org)by lily.knams.wikimedia.org with esmtp (Exim 4.63)(envelope-from wikitech-l-bounces@lists.wikimedia.org)id 1ILPQX-0008BF-Rg; Wed, 15 Aug 2007 20:25:14 +0000 Received: from py-out-1112.google.com ([64.233.166.182]:41259)by lily.knams.wikimedia.org with esmtp (Exim 4.63)(envelope-from en.wp.st47@gmail.com) id 1ILPQU-0008B6-Jjfor wikitech-l@lists.wikimedia.org; Wed, 15 Aug 2007 20:25:11 +0000 Received: by py-out-1112.google.com with SMTP id y63so58859pygfor wikitech-l@lists.wikimedia.org;Wed, 15 Aug 2007 13:25:09 -0700 (PDT) Received: by 10.65.151.6 with SMTP id d6mr1713094qbo.1187209509715;Wed, 15 Aug 2007 13:25:09 -0700 (PDT) Received: by 10.64.184.7 with HTTP; Wed, 15 Aug 2007 13:25:07 -0700 (PDT) X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w X-Message-Info: 0jbW5ANosZLY8vjQK9rUF11rTfLn0SaDPjVzmzaUDo6r5VX4L1oCeOy5aEskXolqbNGTTc4kv/qZ1Rtl1YLTiQ== References: 71cd4dd90708131131k36ef2c17k39d1aae4234b7311@mail.gmail.com46C0AFCD.2090101@wikimedia.org2916cbf60708132248v4420cb7fqcd15ae1a36ae1092@mail.gmail.comf9ru7t$anr$1@sea.gmane.org7c2a12e20708141339x29e67a75x5a152e915e35451c@mail.gmail.com12153381.post@talk.nabble.com7c2a12e20708141546g684e5686o3a43be5470513119@mail.gmail.coma4359dff0708141625y436008dcob5a9be39457dcc15@mail.gmail.com38e9c3450708150517x53fb55b3lb45779a9103c8936@mail.gmail.come92136380708150628v42064cfbi3b732180b067d890@mail.gmail.com X-Content-Filtered-By: Mailman/MimeDel 2.1.9 X-BeenThere: wikitech-l@lists.wikimedia.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Wikimedia developers <wikitech-l.lists.wikimedia.org> List-Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/wikitech-l,mailto:wikitech-l-request@lists.wikimedia.org?subject=unsubscribe List-Archive: http://lists.wikimedia.org/pipermail/wikitech-l List-Post: mailto:wikitech-l@lists.wikimedia.org List-Help: mailto:wikitech-l-request@lists.wikimedia.org?subject=help List-Subscribe: http://lists.wikimedia.org/mailman/listinfo/wikitech-l,mailto:wikitech-l-request@lists.wikimedia.org?subject=subscribe Errors-To: wikitech-l-bounces@lists.wikimedia.org Return-Path: wikitech-l-bounces@lists.wikimedia.org X-OriginalArrivalTime: 15 Aug 2007 20:25:17.0884 (UTC) FILETIME=[651E57C0:01C7DF7A]
On 8/15/07, Rob Church robchur@gmail.com wrote:
On 15/08/07, Dan Collins en.wp.st47@gmail.com wrote:
How will the new users log work: whenever a new global account is
created,
or only once the account is 'activated' on the local wiki? ~~~~
If the extension isn't changed from its current state, then it will continue to report (explicit) account creations for the local wiki.
Perhaps the better question is, "how should the log work"?
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well, it ''should'' show the account as soon as it's blockable, and not before, otherwise you could register "RobChurchSucks" on some obscure wiki and we'd see it, be unable to block it, and forget about it.
I'm assuming that autoconfirmation is also on a per-wiki basis?
-- ST47 Administrator, en.wikipedia _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
_________________________________________________________________ Live Search delivers results the way you like it. Try live.com now! http://www.live.com
Hoi, When the English Wikipedia insists on discriminating against people who have a user in a script other than the Latin script... The argument that such a name might be potentially obscene is one that does not assume good faith. You (and I) are not even able to recognise all the potential obscene names in the Latin script as there are so many languages you (and I) do not know. Many of these words that are perfectly fine in one language and are not in another.
If at all it is the home project of a user that can determine if a user name is insulting.
Thanks, GerardM
On 8/17/07, The Fearow fearow00@hotmail.com wrote:
Is it blockable as soon as it is used on a wiki, or as soon as it's registered? On enwiki, usernames deemed inappropriate are blocked on sight (mostly) - would this make that impossible, and make it so we have to wait until it edits (at which point, the potentially obscene name is permanently in the edit history).
My main question is, what is the definition of "blockable". Is that as soon as it is globally registered, or as soon as they edit on a particular wiki they can be blocked on it?
-Matt
From: "Dan Collins" en.wp.st47@gmail.com Reply-To: Wikimedia developers wikitech-l@lists.wikimedia.org To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] SUL Date: Wed, 15 Aug 2007 16:25:07 -0400 MIME-Version: 1.0 Received: from lists.wikimedia.org ([145.97.39.157]) by bay0-mc10-f23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668);
Wed,
15 Aug 2007 13:25:17 -0700 Received: from localhost ([127.0.0.1]:54553 helo=lily.knams.wikimedia.org)by lily.knams.wikimedia.org with esmtp
(Exim
4.63)(envelope-from wikitech-l-bounces@lists.wikimedia.org)id 1ILPQX-0008BF-Rg; Wed, 15 Aug 2007 20:25:14 +0000 Received: from py-out-1112.google.com ([64.233.166.182]:41259)by lily.knams.wikimedia.org with esmtp (Exim 4.63)(envelope-from en.wp.st47@gmail.com) id 1ILPQU-0008B6-Jjfor wikitech-l@lists.wikimedia.org; Wed, 15 Aug 2007 20:25:11 +0000 Received: by py-out-1112.google.com with SMTP id y63so58859pygfor wikitech-l@lists.wikimedia.org;Wed, 15 Aug 2007 13:25:09 -0700 (PDT) Received: by 10.65.151.6 with SMTP id d6mr1713094qbo.1187209509715;Wed,
15
Aug 2007 13:25:09 -0700 (PDT) Received: by 10.64.184.7 with HTTP; Wed, 15 Aug 2007 13:25:07 -0700 (PDT) X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w X-Message-Info:
0jbW5ANosZLY8vjQK9rUF11rTfLn0SaDPjVzmzaUDo6r5VX4L1oCeOy5aEskXolqbNGTTc4kv/qZ1Rtl1YLTiQ== References: 71cd4dd90708131131k36ef2c17k39d1aae4234b7311@mail.gmail.com<
46C0AFCD.2090101@wikimedia.org>< 2916cbf60708132248v4420cb7fqcd15ae1a36ae1092@mail.gmail.com>< f9ru7t$anr$1@sea.gmane.org>< 7c2a12e20708141339x29e67a75x5a152e915e35451c@mail.gmail.com>< 12153381.post@talk.nabble.com>< 7c2a12e20708141546g684e5686o3a43be5470513119@mail.gmail.com>< a4359dff0708141625y436008dcob5a9be39457dcc15@mail.gmail.com>< 38e9c3450708150517x53fb55b3lb45779a9103c8936@mail.gmail.com>< e92136380708150628v42064cfbi3b732180b067d890@mail.gmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.9 X-BeenThere: wikitech-l@lists.wikimedia.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Wikimedia developers <wikitech-l.lists.wikimedia.org> List-Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/wikitech-l,<mailto:
wikitech-l-request@lists.wikimedia.org?subject=unsubscribe>
List-Archive: http://lists.wikimedia.org/pipermail/wikitech-l List-Post: mailto:wikitech-l@lists.wikimedia.org List-Help: mailto:wikitech-l-request@lists.wikimedia.org?subject=help List-Subscribe: http://lists.wikimedia.org/mailman/listinfo/wikitech-l,<mailto:
wikitech-l-request@lists.wikimedia.org?subject=subscribe>
Errors-To: wikitech-l-bounces@lists.wikimedia.org Return-Path: wikitech-l-bounces@lists.wikimedia.org X-OriginalArrivalTime: 15 Aug 2007 20:25:17.0884 (UTC) FILETIME=[651E57C0:01C7DF7A]
On 8/15/07, Rob Church robchur@gmail.com wrote:
On 15/08/07, Dan Collins en.wp.st47@gmail.com wrote:
How will the new users log work: whenever a new global account is
created,
or only once the account is 'activated' on the local wiki? ~~~~
If the extension isn't changed from its current state, then it will continue to report (explicit) account creations for the local wiki.
Perhaps the better question is, "how should the log work"?
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well, it ''should'' show the account as soon as it's blockable, and not before, otherwise you could register "RobChurchSucks" on some obscure
wiki
and we'd see it, be unable to block it, and forget about it.
I'm assuming that autoconfirmation is also on a per-wiki basis?
-- ST47 Administrator, en.wikipedia _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Live Search delivers results the way you like it. Try live.com now! http://www.live.com
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey, Non-latin is perfectly acceptable on english wikipedia - I mean names like "Jimbo Wales is a fucking faggot". These are likely to be insulting anywhere, and I do not see how that can be good faith. There is also the issue of impersonators and obvious socks (take molag bal who uses similair names).
Also, if it is not obviously obscene, it should not be blocked, but discussed, preferrably with the user. This is what is being recommended for now on enwiki.
-Matt
From: GerardM gerard.meijssen@gmail.com Reply-To: Wikimedia developers wikitech-l@lists.wikimedia.org To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] SUL Date: Fri, 17 Aug 2007 09:39:47 +0200 MIME-Version: 1.0 Received: from lists.wikimedia.org ([145.97.39.157]) by bay0-mc7-f10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Fri, 17 Aug 2007 00:40:27 -0700 Received: from localhost ([127.0.0.1]:53120 helo=lily.knams.wikimedia.org)by lily.knams.wikimedia.org with esmtp (Exim 4.63)(envelope-from wikitech-l-bounces@lists.wikimedia.org)id 1ILwQy-0000ZA-E7; Fri, 17 Aug 2007 07:39:52 +0000 Received: from rv-out-0910.google.com ([209.85.198.189]:25983)by lily.knams.wikimedia.org with esmtp (Exim 4.63)(envelope-from gerard.meijssen@gmail.com) id 1ILwQv-0000Z4-1wfor wikitech-l@lists.wikimedia.org; Fri, 17 Aug 2007 07:39:50 +0000 Received: by rv-out-0910.google.com with SMTP id c24so407613rvffor wikitech-l@lists.wikimedia.org;Fri, 17 Aug 2007 00:39:47 -0700 (PDT) Received: by 10.141.128.19 with SMTP id f19mr1127411rvn.1187336387139;Fri, 17 Aug 2007 00:39:47 -0700 (PDT) Received: by 10.141.154.3 with HTTP; Fri, 17 Aug 2007 00:39:47 -0700 (PDT) X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w X-Message-Info: 0jbW5ANosZLkrbVr2OVr/kLzukYF9tzdRqq+gy/wqx0kTYen9Zv9h0ptIN3wVFN+fyzEfoxrCAWPuNF6NYBPIw== References: 38e9c3450708151325m779481b4x14cd5c4641e5e987@mail.gmail.comBAY106-F216C518CF99E114236B27EC7D80@phx.gbl X-Content-Filtered-By: Mailman/MimeDel 2.1.9 X-BeenThere: wikitech-l@lists.wikimedia.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Wikimedia developers <wikitech-l.lists.wikimedia.org> List-Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/wikitech-l,mailto:wikitech-l-request@lists.wikimedia.org?subject=unsubscribe List-Archive: http://lists.wikimedia.org/pipermail/wikitech-l List-Post: mailto:wikitech-l@lists.wikimedia.org List-Help: mailto:wikitech-l-request@lists.wikimedia.org?subject=help List-Subscribe: http://lists.wikimedia.org/mailman/listinfo/wikitech-l,mailto:wikitech-l-request@lists.wikimedia.org?subject=subscribe Errors-To: wikitech-l-bounces@lists.wikimedia.org Return-Path: wikitech-l-bounces@lists.wikimedia.org X-OriginalArrivalTime: 17 Aug 2007 07:40:27.0864 (UTC) FILETIME=[E15C7D80:01C7E0A1]
Hoi, When the English Wikipedia insists on discriminating against people who have a user in a script other than the Latin script... The argument that such a name might be potentially obscene is one that does not assume good faith. You (and I) are not even able to recognise all the potential obscene names in the Latin script as there are so many languages you (and I) do not know. Many of these words that are perfectly fine in one language and are not in another.
If at all it is the home project of a user that can determine if a user name is insulting.
Thanks, GerardM
On 8/17/07, The Fearow fearow00@hotmail.com wrote:
Is it blockable as soon as it is used on a wiki, or as soon as it's registered? On enwiki, usernames deemed inappropriate are blocked on
sight
(mostly) - would this make that impossible, and make it so we have to
wait
until it edits (at which point, the potentially obscene name is permanently in the edit history).
My main question is, what is the definition of "blockable". Is that as soon as it is globally registered, or as soon as they edit on a particular
wiki
they can be blocked on it?
-Matt
From: "Dan Collins" en.wp.st47@gmail.com Reply-To: Wikimedia developers wikitech-l@lists.wikimedia.org To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] SUL Date: Wed, 15 Aug 2007 16:25:07 -0400 MIME-Version: 1.0 Received: from lists.wikimedia.org ([145.97.39.157]) by bay0-mc10-f23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668);
Wed,
15 Aug 2007 13:25:17 -0700 Received: from localhost ([127.0.0.1]:54553 helo=lily.knams.wikimedia.org)by lily.knams.wikimedia.org with esmtp
(Exim
4.63)(envelope-from wikitech-l-bounces@lists.wikimedia.org)id 1ILPQX-0008BF-Rg; Wed, 15 Aug 2007 20:25:14 +0000 Received: from py-out-1112.google.com ([64.233.166.182]:41259)by lily.knams.wikimedia.org with esmtp (Exim 4.63)(envelope-from en.wp.st47@gmail.com) id 1ILPQU-0008B6-Jjfor wikitech-l@lists.wikimedia.org; Wed, 15 Aug 2007 20:25:11 +0000 Received: by py-out-1112.google.com with SMTP id y63so58859pygfor wikitech-l@lists.wikimedia.org;Wed, 15 Aug 2007 13:25:09 -0700 (PDT) Received: by 10.65.151.6 with SMTP id d6mr1713094qbo.1187209509715;Wed,
15
Aug 2007 13:25:09 -0700 (PDT) Received: by 10.64.184.7 with HTTP; Wed, 15 Aug 2007 13:25:07 -0700
(PDT)
X-Message-Delivery: Vj0zLjQuMDt1cz0wO2k9MDtsPTA7YT0w X-Message-Info:
0jbW5ANosZLY8vjQK9rUF11rTfLn0SaDPjVzmzaUDo6r5VX4L1oCeOy5aEskXolqbNGTTc4kv/qZ1Rtl1YLTiQ==
References: 71cd4dd90708131131k36ef2c17k39d1aae4234b7311@mail.gmail.com<
46C0AFCD.2090101@wikimedia.org>< 2916cbf60708132248v4420cb7fqcd15ae1a36ae1092@mail.gmail.com>< f9ru7t$anr$1@sea.gmane.org>< 7c2a12e20708141339x29e67a75x5a152e915e35451c@mail.gmail.com>< 12153381.post@talk.nabble.com>< 7c2a12e20708141546g684e5686o3a43be5470513119@mail.gmail.com>< a4359dff0708141625y436008dcob5a9be39457dcc15@mail.gmail.com>< 38e9c3450708150517x53fb55b3lb45779a9103c8936@mail.gmail.com>< e92136380708150628v42064cfbi3b732180b067d890@mail.gmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.9 X-BeenThere: wikitech-l@lists.wikimedia.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Wikimedia developers <wikitech-l.lists.wikimedia.org> List-Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/wikitech-l,<mailto:
wikitech-l-request@lists.wikimedia.org?subject=unsubscribe>
List-Archive: http://lists.wikimedia.org/pipermail/wikitech-l List-Post: mailto:wikitech-l@lists.wikimedia.org List-Help: mailto:wikitech-l-request@lists.wikimedia.org?subject=help List-Subscribe: http://lists.wikimedia.org/mailman/listinfo/wikitech-l,<mailto:
wikitech-l-request@lists.wikimedia.org?subject=subscribe>
Errors-To: wikitech-l-bounces@lists.wikimedia.org Return-Path: wikitech-l-bounces@lists.wikimedia.org X-OriginalArrivalTime: 15 Aug 2007 20:25:17.0884 (UTC) FILETIME=[651E57C0:01C7DF7A]
On 8/15/07, Rob Church robchur@gmail.com wrote:
On 15/08/07, Dan Collins en.wp.st47@gmail.com wrote:
How will the new users log work: whenever a new global account is
created,
or only once the account is 'activated' on the local wiki? ~~~~
If the extension isn't changed from its current state, then it will continue to report (explicit) account creations for the local wiki.
Perhaps the better question is, "how should the log work"?
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Well, it ''should'' show the account as soon as it's blockable, and not before, otherwise you could register "RobChurchSucks" on some obscure
wiki
and we'd see it, be unable to block it, and forget about it.
I'm assuming that autoconfirmation is also on a per-wiki basis?
-- ST47 Administrator, en.wikipedia _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Live Search delivers results the way you like it. Try live.com now! http://www.live.com
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
_________________________________________________________________ Live Search delivers results the way you like it. Try live.com now! http://www.live.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Fearow wrote:
Is it blockable as soon as it is used on a wiki, or as soon as it's registered? On enwiki, usernames deemed inappropriate are blocked on sight (mostly) - would this make that impossible, and make it so we have to wait until it edits (at which point, the potentially obscene name is permanently in the edit history).
My main question is, what is the definition of "blockable". Is that as soon as it is globally registered, or as soon as they edit on a particular wiki they can be blocked on it?
As of this exact moment, a username would be blockable once it has been used to log in on that wiki.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Andrew Garrett wrote:
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
Two issues:
- So many people are trying it out, that test.wikipedia.org is
slowing down to ridiculously slow levels.
No, it's just that test.wikipedia.org is always ridiculously slow. ;)
- Is there an opportunity to ask for differently-named accounts to be
added to the mix (i.e. I have 'Werdna648' on meta, can I add that into the accounts to be merged?).
Not at the moment. We'll consider the issues relating to user-directed merging of different account names, though, since some people will find it useful.
- -- brion vibber (brion @ wikimedia.org)
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
One request: Please distinguish between accounts which have matching password/email and accounts that don't match but have no edits so will be merged anyway. The list of accounts it intends to merge with mine includes quite a few which I certainly didn't create, which could be rather confusing (well, to be honest, it *was* rather confusing, I thought it was a bug until I thought to check the contribs and saw they were blank).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Dalton wrote:
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
One request: Please distinguish between accounts which have matching password/email and accounts that don't match but have no edits so will be merged anyway. The list of accounts it intends to merge with mine includes quite a few which I certainly didn't create, which could be rather confusing (well, to be honest, it *was* rather confusing, I thought it was a bug until I thought to check the contribs and saw they were blank).
Good thought! The merging system knows internally what reason was used to make the match, and it would indeed be helpful to display that to the user.
At the moment that's only stored internally.
- -- brion vibber (brion @ wikimedia.org)
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
Good thought! The merging system knows internally what reason was used to make the match, and it would indeed be helpful to display that to the user.
At the moment that's only stored internally.
Is there any reason we don't suggest for merging accounts with matchin names but differing emails? ... if the user knows the password, the account is effectively theirs seems silly to make them take the extra step of going and changing the email before it shows in the list.
On 8/14/07, Gregory Maxwell gmaxwell@gmail.com wrote:
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
Good thought! The merging system knows internally what reason was used to make the match, and it would indeed be helpful to display that to the user.
At the moment that's only stored internally.
Is there any reason we don't suggest for merging accounts with matchin names but differing emails? ... if the user knows the password, the account is effectively theirs seems silly to make them take the extra step of going and changing the email before it shows in the list.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
I was under the impression that it looked through similar accounts testing the password you entered as well. As long as you know the password, you can merge it.
Is there any reason we don't suggest for merging accounts with matchin names but differing emails?
I'm pretty sure it does. If the email matches, it should automatically merge, since if you control the email account, you can always change the password if you don't know it. It's only when neither the email or password match that it asks.
However, I'm not really sure the password matching should be taken as proof that it's the same account, it could be a coincidence (especially if people are using bad passwords, eg username backwards). E-mail matching should be required. Otherwise, ask for the password. If they know it's their account and log on with the same password, excellent, if it's not their account they won't know the password (just because it's the same as their password doesn't mean they know it), and the account shouldn't be merged. Yes, it's likely people will try their password just in case it's their account and they've forgotten, but we should leave password guessing to the user, the code shouldn't be doing any guesswork.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Dalton wrote:
Is there any reason we don't suggest for merging accounts with matchin names but differing emails?
I'm pretty sure it does. If the email matches, it should automatically merge, since if you control the email account, you can always change the password if you don't know it. It's only when neither the email or password match that it asks.
However, I'm not really sure the password matching should be taken as proof that it's the same account, it could be a coincidence (especially if people are using bad passwords, eg username backwards).
It's very unlikely that two people with the exact same username will pick the exact same lame password.
If they do, then they could have logged into each others' accounts anyway -- so it's high time for them to figure it out. ;)
E-mail matching should be required. Otherwise, ask for the password. If they know it's their account and log on with the same password, excellent, if it's not their account they won't know the password (just because it's the same as their password doesn't mean they know it), and the account shouldn't be merged. Yes, it's likely people will try their password just in case it's their account and they've forgotten, but we should leave password guessing to the user, the code shouldn't be doing any guesswork.
There's no guesswork -- either you can log into the account or you can't.
- -- brion vibber (brion @ wikimedia.org)
It's very unlikely that two people with the exact same username will pick the exact same lame password.
If they do, then they could have logged into each others' accounts anyway -- so it's high time for them to figure it out. ;)
They couldn't log into each other's accounts without knowing they had the same password, except by guessing. They wouldn't know that until this new special page told them. It's highly unlikely, sure, but not impossible. I doubt there are many people with accounts with the same password but different email address, so the gain is minimal. I don't think that minimal gain is worth the, admittedly small, chance of given someone access to someone else's account.
The code is guessing that two accounts with the same username and password are owned by the same person, it's very likely, but it isn't definite, so it is a guess. Just because two accounts have the same password doesn't mean that knowing one means you know the other, since you don't know they are the same.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Dalton wrote:
It's very unlikely that two people with the exact same username will pick the exact same lame password.
If they do, then they could have logged into each others' accounts anyway -- so it's high time for them to figure it out. ;)
They couldn't log into each other's accounts without knowing they had the same password, except by guessing. They wouldn't know that until this new special page told them. It's highly unlikely, sure, but not impossible. I doubt there are many people with accounts with the same password but different email address, so the gain is minimal. I don't think that minimal gain is worth the, admittedly small, chance of given someone access to someone else's account.
I disagree; I think this "risk" is laughably ridiculous if not nonexistent, and the huge benefit of increased automation far far far far far far outweighs it.
Plenty of people don't *have* an e-mail address set, or don't have it set at all wikis. Password login checks are the most secure and most reliable way to confirm that the real human owns the account.
- -- brion vibber (brion @ wikimedia.org)
On Tue, 14 Aug 2007 13:45:47 -0400, Brion Vibber wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Dalton wrote:
It's very unlikely that two people with the exact same username will pick the exact same lame password.
If they do, then they could have logged into each others' accounts anyway -- so it's high time for them to figure it out. ;)
They couldn't log into each other's accounts without knowing they had the same password, except by guessing. They wouldn't know that until this new special page told them. It's highly unlikely, sure, but not impossible. I doubt there are many people with accounts with the same password but different email address, so the gain is minimal. I don't think that minimal gain is worth the, admittedly small, chance of given someone access to someone else's account.
I disagree; I think this "risk" is laughably ridiculous if not nonexistent, and the huge benefit of increased automation far far far far far far outweighs it.
Plenty of people don't *have* an e-mail address set, or don't have it set at all wikis. Password login checks are the most secure and most reliable way to confirm that the real human owns the account.
It seems to me like a typical precision vs. recall situation. I think email has the best precision, certainly better than password, since it shows the accounts are technically already linked; but since we don't require it, and even if people do use it, they can easily use different addresses that may or may not even go to the same inbox, recall would be pretty low (lots of false negatives), possibly to the point where the whole thing becomes pointless.
Password matching should greatly increase recall and slightly decrease precision. So it would be ideal to try to limit the amount of mistakes and have a way to deal with them, but it's a matter of finding a way to do that's not too complicated to deal with a situation that might never arise.
For example, when comparing passwords, also compare with the 5 or so most likely passwords for that account; if you get a match, then tell them to come back after they've changed their password. This has the advantage that it's pretty simple, and would also address a situation that really does occur.
"Thomas Dalton" thomas.dalton@gmail.com wrote in message news:a4359dff0708141021u5bce897eta7dc09c478ff023@mail.gmail.com...
It's very unlikely that two people with the exact same username will pick the exact same lame password.
If they do, then they could have logged into each others' accounts anyway -- so it's high time for them to figure it out. ;)
[SNIP] I doubt there are many people with accounts with the same password but different email address, so the gain is minimal. [SNIP]
There are a lot of people, like myself, who have started using different e-mails for every site they sign up to. For example, wikipedia_aug07@example.com would be the e-mail address I would use if I joined WP today. This allows easy inbox filtering, and is an good way to see which sites are disreputable/insecure when the spam starts coming in. When you own your own domain name (rather than using gmail or whatever) this requires no extra work (you can just make up the bit before the @ sign however you like), so a lot of people use this or a similar method to avoid being spammed to death.
- Mark Clements (HappyDog)
On 8/25/07, Mark Clements gmane@kennel17.co.uk wrote:
When you own your own domain name (rather than using gmail or whatever) this requires no extra work (you can just make up the bit before the @ sign however you like), so a lot of people use this or a similar method to avoid being spammed to death.
And if you use Gmail, you can use plus-addressing instead (see my e-mail address, for instance).
On Sat, 2007-08-25 at 20:53 -0400, Simetrical wrote:
And if you use Gmail, you can use plus-addressing instead (see my e-mail address, for instance).
There's always dspam.
I've been running it for years on our production servers, and I probably get... maybe 1-2 spams slipping through to my Inbox _every few months_, max (after its trained up, which takes about 1-2 months at the onset).
After 5+ years of running dspam, I never even have to worry about getting spam in my Inbox, because it simply doesn't happen. There may be a burst or two when a new spam technique comes out that dspam isn't aware of, but a few clicks in the web-ui, and I never see them again.
Throw graymilter or postgrey in there and it drops further:
http://code.gnu-designs.com/graymilter_results.png http://code.gnu-designs.com/dspam+graymilter-gnu.png
The side-benefit of graymilter/postgrey is that you're no longer accepting connections and spam emails which you'll quarantine and discard anyway. You save on bandwidth, storage space and reduce the number of connections necessary to process "real" emails.
For those who can't or won't use dspam, here's some other ideas:
<a href="mailto:foo@domain.com">feedback</a>
This semi-obfuscates the three main things spam harvesters look for to find email addresses:
- Splitting on a mailto string - Finding word at word.word and testing it as an email - Reverse split on .com.* to find the parent domain to spider
Spammers are getting smarter all the time, and they'll eventually figure out how to decode the entities, but for now, it reduces a HUGE amount of spammable public mailto links (and it does not break in a browser).
I haven't recieved a single SPAM after moving to using this (and similar) obfuscation methods, down from about 30/day previously without it (using SpamAssassin at the time), per address.
I also use a very strong offensive technique, which I've talked about before (and finally got around to posting on perlmonks[1] back in May of 2003). This has become more than just a defensive maneuver now, avoiding and blocking SPAM.
There are other ways as well, here are some examples:
# Yes, this is actually a valid email address - @yourdomain.com - foo()@yourdomain.com # Also valid - foo&bar at yourdomain.com # Valid - foo(localpart)@(domain is)yourdomain.com # Yes, also 100% valid - foo@(domain)yourdomain.com
I've been proactively and defensively fighting spam for the better part of a decade, and at this point, I think I've won. Not only do I simply no longer get spam, but neither do my users or anyone I middleman mail or mailing lists for.
Spam really is a non-issue, once you set up the right tools.
[1] Can-o-Raid: http://www.perlmonks.org/index.pl?node_id=258370
[SNIP] I doubt there are many people with accounts with the same password but different email address, so the gain is minimal. [SNIP]
There are a lot of people, like myself, who have started using different e-mails for every site they sign up to. For example, wikipedia_aug07@example.com would be the e-mail address I would use if I joined WP today.
Maybe there are also a lot of people having beside different email adresses also different passwords(startings/endings) on each account...
Conrad Nutschan wrote:
[SNIP] I doubt there are many people with accounts with the same password but different email address, so the gain is minimal. [SNIP]
There are a lot of people, like myself, who have started using different e-mails for every site they sign up to. For example, wikipedia_aug07@example.com would be the e-mail address I would use if I joined WP today.
Maybe there are also a lot of people having beside different email adresses also different passwords(startings/endings) on each account...
Then their user experience doesn't change in any way unless and until they change their accounts to match.
Horrifying, I know. ;)
-- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
Good thought! The merging system knows internally what reason was used to make the match, and it would indeed be helpful to display that to the user.
At the moment that's only stored internally.
Is there any reason we don't suggest for merging accounts with matchin names but differing emails?
We do, explicitly.
... if the user knows the password, the account is effectively theirs seems silly to make them take the extra step of going and changing the email before it shows in the list.
Yes, that would be silly -- that's why they're instead prompted to enter the password.
- -- brion vibber (brion @ wikimedia.org)
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
Good thought! The merging system knows internally what reason was used to make the match, and it would indeed be helpful to display that to the user.
At the moment that's only stored internally.
Is there any reason we don't suggest for merging accounts with matchin names but differing emails?
We do, explicitly.
... if the user knows the password, the account is effectively theirs seems silly to make them take the extra step of going and changing the email before it shows in the list.
Yes, that would be silly -- that's why they're instead prompted to enter the password.
I'm assuming this doesn't work on the test wiki yet -- I was prompted to enter a password and it only accepted the one I used with my login to the test wiki. It identified en.wikipedia as my home account but said I would have to log in at en.wikipedia to complete the merge process.
However, when I changed my password on test to the one I use on enwikipedia, it suggested all of the "mindspillage" accounts to merge, only prompting for my password on accounts where I have both different email and password.
Is this what's intended?
-Kat
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Kat Walsh wrote:
... if the user knows the password, the account is effectively theirs seems silly to make them take the extra step of going and changing the email before it shows in the list.
Yes, that would be silly -- that's why they're instead prompted to enter the password.
I'm assuming this doesn't work on the test wiki yet -- I was prompted to enter a password and it only accepted the one I used with my login to the test wiki. It identified en.wikipedia as my home account but said I would have to log in at en.wikipedia to complete the merge process.
That's the intended behavior -- the merge process requires that you be working at your main account or at an account which can be automatically determined to match it by password.
This minimizes the risk of someone else milling your accounts for information by making an account which would get merged in due to disuse or matching e-mail address.
However, when I changed my password on test to the one I use on enwikipedia, it suggested all of the "mindspillage" accounts to merge, only prompting for my password on accounts where I have both different email and password.
Is this what's intended?
Sounds about right! It can then match to your primary account (en.wikipedia in this case) by password, and then also match all others with the same password or e-mail address.
You'd only need to enter additional passwords if they can't be matched already.
- -- brion vibber (brion @ wikimedia.org)
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
This minimizes the risk of someone else milling your accounts for information by making an account which would get merged in due to disuse or matching e-mail address.
Ah. I didn't realize that we'd join across accounts using non-confirmed email data.
This creates an obscure and hard to exploit but fun hole:
Step 1. Pick a prominent non-admin on enwiki who is also not an admin anywhere else.
Step 2. Email them something friendly in order to determine their email address.
Step 3. Create an account on an obsecure wikimedia wiki where obtaining adminship is trivial. Set your email address to theirs, don't confirm.
Step 4. Make some edits edits on the small wiki and become an admin. You now have prefered status for standing as the master account.
Step 5. Merge accounts and enjoy your new enwiki account.
;)
To counter this we need to add a check to not merge across accounts from one without a confirmed email address. I.e. if and only if you have both the password and the account has a confirmed email should you be able to merge to accounts with the same email (confirmed or not) unless you have the password.
On Tue, Aug 14, 2007 at 02:42:15PM -0400, Gregory Maxwell wrote:
This creates an obscure and hard to exploit but fun hole:
Step 1. Pick a prominent non-admin on enwiki who is also not an admin anywhere else.
Step 2. Email them something friendly in order to determine their email address.
Step 3. Create an account on an obsecure wikimedia wiki where obtaining adminship is trivial. Set your email address to theirs, don't confirm.
Step 4. Make some edits edits on the small wiki and become an admin. You now have prefered status for standing as the master account.
Step 5. Merge accounts and enjoy your new enwiki account.
Step 6. PROFITT!!1!!
Cheers, -- jr 'moral imperative. hadda be done' a
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On 8/14/07, Brion Vibber brion@wikimedia.org wrote:
This minimizes the risk of someone else milling your accounts for information by making an account which would get merged in due to disuse or matching e-mail address.
Ah. I didn't realize that we'd join across accounts using non-confirmed email data.
You can reset the password if the email is set to your e-mail address. Thus any account that matches the email will be given to you if you are confirmed (by password) to own the master account.
This creates an obscure and hard to exploit but fun hole:
Step 1. Pick a prominent non-admin on enwiki who is also not an admin anywhere else.
Step 2. Email them something friendly in order to determine their email address.
Step 3. Create an account on an obsecure wikimedia wiki where obtaining adminship is trivial. Set your email address to theirs, don't confirm.
You don't have a choice about confirmation -- when you set the e-mail address it'll send a confirmation email automatically. Thus they're alerted, and the jig, as they say, is up. :)
Step 4. Make some edits edits on the small wiki and become an admin. You now have prefered status for standing as the master account.
Step 5. Merge accounts and enjoy your new enwiki account.
;)
To counter this we need to add a check to not merge across accounts from one without a confirmed email address. I.e. if and only if you have both the password and the account has a confirmed email should you be able to merge to accounts with the same email (confirmed or not) unless you have the password.
Hmmmm, maybe.
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber wrote:
Gregory Maxwell wrote:
On 8/14/07, Brion Vibber wrote:
This minimizes the risk of someone else milling your accounts for information by making an account which would get merged in due to disuse or matching e-mail address.
Ah. I didn't realize that we'd join across accounts using non-confirmed email data.
I thought we did this.
You can reset the password if the email is set to your e-mail address. Thus any account that matches the email will be given to you if you are confirmed (by password) to own the master account.
Once merged, the first thing to do would be change the email on the account taken over :-)
This creates an obscure and hard to exploit but fun hole:
Step 1. Pick a prominent non-admin on enwiki who is also not an admin anywhere else.
Step 2. Email them something friendly in order to determine their email address.
Step 3. Create an account on an obsecure wikimedia wiki where obtaining adminship is trivial. Set your email address to theirs, don't confirm.
You don't have a choice about confirmation -- when you set the e-mail address it'll send a confirmation email automatically. Thus they're alerted, and the jig, as they say, is up. :)
Then what? It alerts of the action, but you can't stop it. The confirmation message says: Someone, probably you from IP address X.Y.Z, has registered an account "YourName" with this e-mail address on Wikipedia.
To confirm that this account really does belong to you and activate e-mail features on Wikipedia, open this link in your browser:
http://test.wikipedia.org/wiki/Special:Confirmemail/baddeefbaddeefbaddeefbad...
If this is *not* you, don't follow the link. This confirmation code will expire at XXX
So, there's no option to "refuse" the email connection. The receiver may think, "oh, somebody registered an account with my name at the wikipedia in strange language" but not matter more about it (note he's relating the warning to the username, not with their email). If he checks the contributions will see a user with good editions. If username clashes are as common as Anthony says, he won't think it again (until he loses his account). He would need to be a paranoic, knowing this vulnerability running to warn a steward or takeover it. And still he'll need to sleep.
I'd create the takover account and not set its password to the matching one before minutes of Merging them.
You don't have a choice about confirmation -- when you set the e-mail address it'll send a confirmation email automatically. Thus they're alerted, and the jig, as they say, is up. :)
Then what? It alerts of the action, but you can't stop it. The confirmation message says: Someone, probably you from IP address X.Y.Z, has registered an account "YourName" with this e-mail address on Wikipedia.
To confirm that this account really does belong to you and activate e-mail features on Wikipedia, open this link in your browser:
http://test.wikipedia.org/wiki/Special:Confirmemail/baddeefbaddeefbaddeefbad...
If this is *not* you, don't follow the link. This confirmation code will expire at XXX
So, there's no option to "refuse" the email connection. The receiver may think, "oh, somebody registered an account with my name at the wikipedia in strange language" but not matter more about it (note he's relating the warning to the username, not with their email). If he checks the contributions will see a user with good editions. If username clashes are as common as Anthony says, he won't think it again (until he loses his account). He would need to be a paranoic, knowing this vulnerability running to warn a steward or takeover it. And still he'll need to sleep.
I'd create the takover account and not set its password to the matching one before minutes of Merging them.
Exactly right. A non-confirmed email address shouldn't be used for anything, at all, since without confirmation, it's just a random string. If you really want to use unconfirmed email addresses, then give control of accounts with unconfirmed addresses to accounts with confirmed addresses, but definitely not the other way around, that is a major loophole.
On 8/14/07, Thomas Dalton thomas.dalton@gmail.com wrote:
I'd create the takover account and not set its password to the matching one before minutes of Merging them.
[ed: email address was intended there instead of password]
Exactly right. A non-confirmed email address shouldn't be used for anything, at all, since without confirmation, it's just a random string. If you really want to use unconfirmed email addresses, then give control of accounts with unconfirmed addresses to accounts with confirmed addresses, but definitely not the other way around, that is a major loophole.
Major might be a bit of an overstatement. The attacker still needs to win the home wiki election. Otherwise the lack of a matching password locks them out, as Kat discovered upthread.
Against an account with a sizable history the most obvious and probably easy way to win the election is to become an admin with that name when they are not an admin anywhere... This is what I did for my test (I had Brion sysop a virtual sock of my bot account on test).
Brion's right about the email, but the attacker could just change it at the last moment. It takes a while for people to check their mail.
I'm sure if anyone actually pulled this off we'd just correct it and life would go on... but it would be nice to avoid it. Asking for a password in order to cross an email linkage from an unconfirmed side would be simple enough.
Alternatively, SUL could push people who are unconfirmed at their home wiki to confirm. ... This would be wise because once the dust is settled on SUL the issue of mandatory confirmed email for upload on commons is going to be raised again. Last time it appeared to have a reasonable level of support, but was put off until SUL was done to further inconveniencing users from the Wikipedias.
On Tue, 14 Aug 2007 21:52:14 +0100, Thomas Dalton wrote:
You don't have a choice about confirmation -- when you set the e-mail address it'll send a confirmation email automatically. Thus they're alerted, and the jig, as they say, is up. :)
Then what? It alerts of the action, but you can't stop it. The confirmation message says: Someone, probably you from IP address X.Y.Z, has registered an account "YourName" with this e-mail address on Wikipedia.
To confirm that this account really does belong to you and activate e-mail features on Wikipedia, open this link in your browser:
http://test.wikipedia.org/wiki/Special:Confirmemail/baddeefbaddeefbaddeefbad...
If this is *not* you, don't follow the link. This confirmation code will expire at XXX
So, there's no option to "refuse" the email connection. The receiver may think, "oh, somebody registered an account with my name at the wikipedia in strange language" but not matter more about it (note he's relating the warning to the username, not with their email). If he checks the contributions will see a user with good editions. If username clashes are as common as Anthony says, he won't think it again (until he loses his account). He would need to be a paranoic, knowing this vulnerability running to warn a steward or takeover it. And still he'll need to sleep.
I'd create the takover account and not set its password to the matching one before minutes of Merging them.
Exactly right. A non-confirmed email address shouldn't be used for anything, at all, since without confirmation, it's just a random string. If you really want to use unconfirmed email addresses, then give control of accounts with unconfirmed addresses to accounts with confirmed addresses, but definitely not the other way around, that is a major loophole.
It seems fine to me to merge an account with an unconfirmed email into a matching email. If I really want that as my home wiki, I could change it later; if it's an imposter, then I should get control of the account. Just make sure that when picking a home wiki, the confirmed email always wins.
On 8/14/07, Steve Sanbeg ssanbeg@ask.com wrote:
It seems fine to me to merge an account with an unconfirmed email into a matching email. If I really want that as my home wiki, I could change it later; if it's an imposter, then I should get control of the account. Just make sure that when picking a home wiki, the confirmed email always wins.
That just shifts the failure modes about. Say you, like many others, don't have a confirmed email on your primary project. You have 10 gillion edits... whatever, just no confirmed email.
An Some evil troll goes and creates an account with your name on klingon wikisource and old english wikibooks, confirms his own email, and makes a couple of edits.. Then merges his accounts.
You are now unable to merge your accounts. It's better than an account take over, but failure none the less.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On 8/14/07, Steve Sanbeg ssanbeg@ask.com wrote:
It seems fine to me to merge an account with an unconfirmed email into a matching email. If I really want that as my home wiki, I could change it later; if it's an imposter, then I should get control of the account. Just make sure that when picking a home wiki, the confirmed email always wins.
That just shifts the failure modes about. Say you, like many others, don't have a confirmed email on your primary project. You have 10 gillion edits... whatever, just no confirmed email.
An Some evil troll goes and creates an account with your name on klingon wikisource and old english wikibooks, confirms his own email, and makes a couple of edits.. Then merges his accounts.
Under the proposed scheme, he can't merge his accounts, since he doesn't own the primary account -- having a confirmed e-mail address didn't win him anything there. He still would have had to gain a privileged account first in order to win out over your unprivileged much-used account.
- -- brion vibber (brion @ wikimedia.org)
On 8/13/07, Brion Vibber brion@wikimedia.org wrote:
[snip] I've put Anthony on moderation, I'm tired of his trolling.
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
Nice! I think it found all my 11 logins. (good lord, 11. And I didn't even remember I had one on wikiquote. No wonder I keep getting confused about what to do next;-)
I am really looking forward to this. Not just for myself, but to rid people on de.wikipedia of that last excuse for not uploading pictures on commons instead.
Great work! Magnus
2007/8/14, Magnus Manske magnusmanske@googlemail.com:
Nice! I think it found all my 11 logins. (good lord, 11. And I didn't even remember I had one on wikiquote. No wonder I keep getting confused about what to do next;-)
Only 11? My page lists over 260...
On 14/08/07, Andre Engels andreengels@gmail.com wrote:
Only 11? My page lists over 260...
Ah, I wondered when this would become a dickwaving contest.
Rob Church
hahahaha... I won't comment on how big mine is...
On 8/14/07, Rob Church robchur@gmail.com wrote:
On 14/08/07, Andre Engels andreengels@gmail.com wrote:
Only 11? My page lists over 260...
Ah, I wondered when this would become a dickwaving contest.
Rob Church
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8/14/07, Andre Engels andreengels@gmail.com wrote:
2007/8/14, Magnus Manske magnusmanske@googlemail.com:
Nice! I think it found all my 11 logins. (good lord, 11. And I didn't even remember I had one on wikiquote. No wonder I keep getting confused about what to do next;-)
Only 11? My page lists over 260...
My accounts all have different passwords, some have different usernames, and all but a couple have no email addresses, so I'm SOL.
Brion Vibber-3 wrote:
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
-- brion vibber (brion @ wikimedia.org)
Hi Brion,
Brion Vibber-3 wrote:
Please note that the single user login account merging system is up and running in a live demo state since Wikimania at http://test.wikipedia.org/wiki/Special:MergeAccount
If your account on test.wikipedia.org matches your main one, you can try it out there and check for conflicting accounts. We'll go into the opt-in beta for actual logins over the next couple of weeks.
-- brion vibber (brion @ wikimedia.org)
Hi Brion,
Here is my situation (it's not a complaint, just a question ;-) ):
my main account is on fr.wp (let's call it A), I've the same account A on mediawiki.org
unfortunatelly, test.wikipedia.org tells me that my home account is on sv.wp
so I checked and indeed there is someone with account A on sv.wp which has ten times more edit than me (I've around 700 and he has several thousands) and which registered a few months earlier than me (back in 2004).
Well, if I understand correctly, I'm going to loose my account A on fr.wp and mediawiki.org in a few weeks.
That's not a problem at all, I'm fine with that ;-)
Last thing : I also have an other account B on fr.wp that I've used only once for now (1 contribution on the user page).
Here is my question :
Is it possible that instead of proposing me to change my user name, the SUL system proposes me to "transfer" my A contributions to another acount (there I would specify B) and then to SUL-merge my account B ? I'm pretty sure this is technically possible, but is it something you "could plan" or "have the right" to do ? (please :-) )
Is it possible that instead of proposing me to change my user name, the SUL system proposes me to "transfer" my A contributions to another acount (there I would specify B) and then to SUL-merge my account B ? I'm pretty sure this is technically possible, but is it something you "could plan" or "have the right" to do ? (please :-) )
My gut feeling is that merging the contributions of accounts would cause the sky to fall, but I can't actually think of anything that would go wrong... I look forward to more informed responses...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexis Moinet wrote:
my main account is on fr.wp (let's call it A), I've the same account A on mediawiki.org
unfortunatelly, test.wikipedia.org tells me that my home account is on sv.wp
so I checked and indeed there is someone with account A on sv.wp which has ten times more edit than me (I've around 700 and he has several thousands) and which registered a few months earlier than me (back in 2004).
Well, if I understand correctly, I'm going to loose my account A on fr.wp and mediawiki.org in a few weeks.
Sorry to hear that. :(
That's not a problem at all, I'm fine with that ;-)
And at least now you know. :)
Last thing : I also have an other account B on fr.wp that I've used only once for now (1 contribution on the user page).
Here is my question :
Is it possible that instead of proposing me to change my user name, the SUL system proposes me to "transfer" my A contributions to another acount (there I would specify B) and then to SUL-merge my account B ? I'm pretty sure this is technically possible, but is it something you "could plan" or "have the right" to do ? (please :-) )
Basically how this would work would be to rename all your A accounts to B, then do the global merge under the B name.
At the moment that's not all integrated, but you could get your existing A accounts renamed to B now through the existing bureaucrat-run Special:RenameUser system. In theory there should be request queue pages somewhere...
On en.wikipedia it's http://en.wikipedia.org/wiki/Wikipedia:Changing_username there are some links there to other languages.
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber-3 wrote:
That's not a problem at all, I'm fine with that ;-)
And at least now you know. :)
Yes, indeed :-)
Brion Vibber-3 wrote:
Last thing : I also have an other account B on fr.wp that I've used only once for now (1 contribution on the user page).
Here is my question :
Is it possible that instead of proposing me to change my user name, the SUL system proposes me to "transfer" my A contributions to another acount (there I would specify B) and then to SUL-merge my account B ? I'm pretty sure this is technically possible, but is it something you "could plan" or "have the right" to do ? (please :-) )
Basically how this would work would be to rename all your A accounts to B, then do the global merge under the B name.
At the moment that's not all integrated, but you could get your existing A accounts renamed to B now through the existing bureaucrat-run Special:RenameUser system. In theory there should be request queue pages somewhere...
On en.wikipedia it's http://en.wikipedia.org/wiki/Wikipedia:Changing_username there are some links there to other languages.
Thanks, that would be the obvious solution if the account B wasn't already existing (even if it's mine) on fr.wp (and with 1 contribution on User:B).
Unfortunatelly on fr.wp, the help page about renaming says that they can only rename an account to a new one that doesn't already exist... they say nothing about transferring contributions from one user to an other (though it is almost the same).
And on en.wp, http://en.wikipedia.org/wiki/Wikipedia:Changing_username/Usurpations says that there must be no contributions... (I know I made a huge mistake by doing that 1 contribution :-p )
That's why I was asking about SUL possibly doing the contribution transfer thing as a workaround to that.
But otherwise this is going out of topic for SUL and I'll just knock my head on some wall and deal with either finding some idea for an account C or starting using B without my past contributions of A...
Thanks anyway
Yes, and they might also bend the rules if you confirm that it's yours. :-)
On 8/15/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Thanks, that would be the obvious solution if the account B wasn't
already
existing (even if it's mine) on fr.wp (and with 1 contribution on
User:B).
Since it's yours, you can just request that it be renamed to C, and then rename A to B.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 15/08/07, Casey Brown cbrown1023.ml@gmail.com wrote:
Yes, and they might also bend the rules if you confirm that it's yours. :-)
On 8/15/07, Thomas Dalton thomas.dalton@gmail.com wrote:
Thanks, that would be the obvious solution if the account B wasn't
already
existing (even if it's mine) on fr.wp (and with 1 contribution on
User:B).
Since it's yours, you can just request that it be renamed to C, and then rename A to B.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
-- Casey Brown Cbrown1023
Note: This e-mail address is used for mailing lists. Personal emails sent to this address will probably get lost. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
Rules are there to be broken. Let's hope there's no process wonkery with this.
Majorly wrote:
Yes, and they might also bend the rules if you confirm that it's yours. :-)
You can get B renamed to old-B, and A renamed to B. If you care about that single contribution, you will need to poke a db admin to change that edit ownership. The question is: what trolling were you trying to achieve creating the B account?, you sockpuppeter! ;)
Platonides wrote:
Majorly wrote:
Yes, and they might also bend the rules if you confirm that it's yours. :-)
You can get B renamed to old-B, and A renamed to B. If you care about that single contribution, you will need to poke a db admin to change that edit ownership.
Thanks for the tip, that's a perfect solution (really don't care about 1 edit on my own user page)
Platonides wrote:
The question is: what trolling were you trying to achieve creating the B account?, you sockpuppeter! ;)
Actually it's all SUL fault ;-p
I noticed yesterday that I was going to loose my account A, so I searched for another available name and ... created it (B) instead of asking for renaming.
(Basically on wp I just do editing on articles, nothing like request to admins or bureaucrats --> I didn't know it was not possible to reattribute contributions. Plus I use the mediawiki software a lot on my intranet and thus I don't need to ask others to do such manipulation, if I make a mistake on my local install, I just do some SQL stuff (or backup) and it's corrected. "act first, then think...")
--Absent for 1 week : currently reading the whole "Help/Aide" namespaces on en.wp and fr.wp before doing some other silly action ...
On 8/15/07, Casey Brown cbrown1023.ml@gmail.com wrote:
Yes, and they might also bend the rules if you confirm that it's yours. :-)
There aren't any rules to bend, in this case. Usurpation only applies to an unresponsive account you want to replace. If the owner of the target name is agreeable, then of course you can get renamed to it (with the target renamed to still something else).
Well, you might want to break the rule that accounts can't be merged. But that's imposed by the Renameuser extension, so it can't be overridden by anyone on-wiki. A sysadmin could still do it easily enough, but given that it's one edit, who cares?
(Of course, if the merging algorithm is using live edit count in its calculations, you could also get around it by spamming a ton of vandalism reverts or something . . . now would be a good time to go for RFA, too, if there are people conflicting with you . . .)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Alexis Moinet wrote:
Basically how this would work would be to rename all your A accounts to B, then do the global merge under the B name.
At the moment that's not all integrated, but you could get your existing A accounts renamed to B now through the existing bureaucrat-run Special:RenameUser system. In theory there should be request queue pages somewhere...
On en.wikipedia it's http://en.wikipedia.org/wiki/Wikipedia:Changing_username there are some links there to other languages.
Thanks, that would be the obvious solution if the account B wasn't already existing (even if it's mine) on fr.wp (and with 1 contribution on User:B).
If it's already yours, then there's nothing you have to do on that one.
- -- brion vibber (brion @ wikimedia.org)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Thomas Dalton wrote:
If it's already yours, then there's nothing you have to do on that one.
He wants to keep his contributions from Account A, though, that's the issue.
He doesn't have any -- that wiki's Account A belongs to someone else, who is a sysop with more edits than any of his accounts.
- -- brion vibber (brion @ wikimedia.org)
Brion Vibber-3 wrote:
Thomas Dalton wrote:
If it's already yours, then there's nothing you have to do on that one.
He wants to keep his contributions from Account A, though, that's the issue.
He doesn't have any -- that wiki's Account A belongs to someone else, who is a sysop with more edits than any of his accounts.
- -- brion vibber (brion @ wikimedia.org)
Just to clarify : the accounts A on fr.wp and mediawiki.org belong to me (at least, until the SUL merge happens in a few weeks) and these are the ones I want to keep the contribs after SUL merges everything and changes my account name .
Anyway, Platonides' solution is perfect (rename B-->old-B then rename A-->B), thanks for the help and sorry for disturbing you ;-)
good night.
He doesn't have any -- that wiki's Account A belongs to someone else, who is a sysop with more edits than any of his accounts.
It's Account A on a different wiki that belongs to someone else and takes priority. His Account A on the french wiki has the edits he doesn't want to lose.
Alexis Moinet wrote:
Here is my question :
Is it possible that instead of proposing me to change my user name, the SUL system proposes me to "transfer" my A contributions to another acount (there I would specify B) and then to SUL-merge my account B ? I'm pretty sure this is technically possible, but is it something you "could plan" or "have the right" to do ? (please :-) )
I think the text suggested the ability of doing so. Or you can also get renamed to B on fr and mediawiki before merging :)
wikitech-l@lists.wikimedia.org