I want to do some work on the blocking system. Essentially, the idea is to make blocking very flexible, whilst cleaning up some of the flags that are used now.
Therefore, I want to replace the current ipb_address field with a number of nullable fields, including address (username or IP address, as it is now), namespace, page, exempted groups, and permission. If all of the non-null fields match, the block will apply.
This will make blocking more flexible (resolves bugs 874, 1394, and possibly others) - you will be able to place blocks as wide as the current namespace protection, and as narrow as forbidding a certain user from moving a certain page.
Additionally, some of the current fields can be cleaned up - blocking account creation can be implemented by blocking the 'createaccount' permission, and anonymous-only blocks can be implemented by adding 'users' as an exempted group.
Currently, I intend to modify the current table, and allow data of the current schema to behave as normal, thus preventing any nasty batch-conversion scripts for the many tens of thousands of blocks on existing wikis.
This is a fairly major change, so I haven't started work on it. Therefore, questions, comments, suggestions and ridicule are most welcome.
On 8/12/07, Andrew Garrett andrew@epstone.net wrote:
Additionally, some of the current fields can be cleaned up - blocking account creation can be implemented by blocking the 'createaccount' permission, and anonymous-only blocks can be implemented by adding 'users' as an exempted group.
How would you define 'users'? Let's say I have four groups of users and I want to protect four pages so that only one of these groups cannot edit it. Do you allow for multiple exempted groups to be specified or how would you implement that?
Sebastian
On 8/12/07, Sebastian Moleski sebmol@gmail.com wrote:
How would you define 'users'?
'users' is an inbuilt MediaWiki group that includes anybody logged in.
Let's say I have four groups of users and I want to protect four pages so that only one of these groups cannot edit it. Do you allow for multiple exempted groups to be specified or how would you implement that?
My intention is to allow multiple exempted groups.
On 12/08/07, Andrew Garrett andrew@epstone.net wrote:
This is a fairly major change, so I haven't started work on it. Therefore, questions, comments, suggestions and ridicule are most welcome.
At first blush, it seems that you're going to over-complicate the blocking system. Can you explain how this will improve upon the current nightmare that means we have multiple blocks with different flags expiring all over the place? Can you further explain how you plan to keep this as simple to use as possible?
I get the impression that you're proposing a system that's slightly over-adventurous given the scope of this project.
Rob Church
On Aug 12, 2007, at 7:27 PM, Andrew Garrett wrote:
I want to do some work on the blocking system. Essentially, the idea is to make blocking very flexible, whilst cleaning up some of the flags that are used now.
If you do work on the blocking system, it would be very nice if you could implement global blocking (blocking across all Wikimedia wikis) which is a pretty sought-after feature (see http:// bugzilla.wikimedia.org/show_bug.cgi?id=8707).
Even if you don't implement this straight away, if you or any of the other devs do revolutionize the blocking feature, please keep this in mind.
Thanks,
Tangotango
On 8/12/07, Tangotango tangotango@ts.wikimedia.org wrote:
On Aug 12, 2007, at 7:27 PM, Andrew Garrett wrote:
I want to do some work on the blocking system. Essentially, the idea is to make blocking very flexible, whilst cleaning up some of the flags that are used now.
If you do work on the blocking system, it would be very nice if you could implement global blocking (blocking across all Wikimedia wikis) which is a pretty sought-after feature (see http:// bugzilla.wikimedia.org/show_bug.cgi?id=8707).
This will not be able to happen until SUL. :( MinuteElectron.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Without SUL, could it still be implemented for anon accounts?
en:user:xaosflux
- ----- Original Message ----- From: "Minute Electron" minuteelectron@googlemail.com To: "Wikimedia developers" wikitech-l@lists.wikimedia.org Sent: Sunday, August 12, 2007 8:45 AM Subject: Re: [Wikitech-l] Blocking changes proposal
On 8/12/07, Tangotango tangotango@ts.wikimedia.org wrote:
On Aug 12, 2007, at 7:27 PM, Andrew Garrett wrote:
I want to do some work on the blocking system. Essentially, the idea is to make blocking very flexible, whilst cleaning up some of the flags that are used now.
If you do work on the blocking system, it would be very nice if you could implement global blocking (blocking across all Wikimedia wikis) which is a pretty sought-after feature (see http:// bugzilla.wikimedia.org/show_bug.cgi?id=8707).
This will not be able to happen until SUL. :( MinuteElectron. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 8/13/07, xaosflux xaosflux@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Without SUL, could it still be implemented for anon accounts?
We need a central database, which SUL provides. It /could/ be implemented without SUL, but creating a separate central database seems a little silly.
-- Andrew Garrett
Andrew Garrett wrote:
On 8/13/07, xaosflux wrote:
Without SUL, could it still be implemented for anon accounts?
We need a central database, which SUL provides. It /could/ be implemented without SUL, but creating a separate central database seems a little silly.
I don't see that SUL has any blocking code. The global blocking can be implemented on the same database (!= table) without needing to wait for SUL, keeping open compatibility for blocking 'global users'. Some users should be blocked wikiwide, (Wikipedia:Username, sock puppets to evade blocks, Willy on wheels...) but, who should be able to do it? I suppose stewards will need to, but they won't be aware of many cases. Maybe do some global block some if blocked on X different projects? What to do when some users are sysops on many projects?
On 8/13/07, Platonides Platonides@gmail.com wrote:
Andrew Garrett wrote:
On 8/13/07, xaosflux wrote:
Without SUL, could it still be implemented for anon accounts?
We need a central database, which SUL provides. It /could/ be implemented without SUL, but creating a separate central database seems a little silly.
I don't see that SUL has any blocking code. The global blocking can be implemented on the same database (!= table) without needing to wait for SUL, keeping open compatibility for blocking 'global users'. Some users should be blocked wikiwide, (Wikipedia:Username, sock puppets to evade blocks, Willy on wheels...) but, who should be able to do it? I suppose stewards will need to, but they won't be aware of many cases. Maybe do some global block some if blocked on X different projects? What to do when some users are sysops on many projects?
There is a dependency for username blocks on some kind of code to determine which accounts across different projects are actually controlled by the same people. [[User:Anthony]] on en.wikipedia, might very well be different from [[User:Anthony]] on fr.wikipedia (in fact, it is), so we wouldn't want to block all User:Anthony's just because one of them is bad.
One way to solve this dependency is through SUL. Of course, there are other ways, but this fact is meant to be kept a secret.
On 8/13/07, Soo Reams soo@sooreams.com wrote:
Anthony wrote:
One way to solve this dependency is through SUL. Of course, there are other ways, but this fact is meant to be kept a secret.
For those of us new to the list and puzzled by your repeated snide references to SUL, could you recap your objections to it?
It forces good faith users to change their username, and clogs up the username namespace even more than it already is.
To use an analogy, let's say I come up with a plan for Single Domain Name Resolution (SDNR). Forcing Wikipedia to register so many domain names (wikipedia.com/wikipedia.net/wikipedia.org/etc) is silly, so why not let them register one address for all. So under SDNR, we merge .com, .net, and .org. Companies register for one of the three addresses and they automatically get all three. There's no longer a need to type in "slashdot.com", I can just type in "slashdot". In case of any conflict, where two people picked the same second level domain name part, we look at how much traffic the various domain names get and whoever gets the most traffic gets all three domain names. Happiness.org (alexa rank 1,743,585) has 3 months to come up with a new domain name or we change it for them, to happiness-usurped.org. After all, Happiness.com (alexa rank 1,262,045) gets more traffic.
Anthony
On Aug 13, 2007, at 10:00 PM, Anthony wrote:
To use an analogy, let's say I come up with a plan for Single Domain Name Resolution (SDNR). Forcing Wikipedia to register so many domain names (wikipedia.com/wikipedia.net/wikipedia.org/etc) is silly, so why not let them register one address for all. So under SDNR, we merge .com, .net, and .org. Companies register for one of the three addresses and they automatically get all three. There's no longer a need to type in "slashdot.com", I can just type in "slashdot". In case of any conflict, where two people picked the same second level domain name part, we look at how much traffic the various domain names get and whoever gets the most traffic gets all three domain names. Happiness.org (alexa rank 1,743,585) has 3 months to come up with a new domain name or we change it for them, to happiness-usurped.org. After all, Happiness.com (alexa rank 1,262,045) gets more traffic.
I'm not sure if I follow your analogy there, Anthony. Domain names have an importance almost akin to a trademark on the Internet, and companies use ridiculous amounts of resources for the upkeep of their domains and usurpation of any conflicting ones.
A Wikimedia username, on the other hand, is merely a unique identifier that identifies a person. Whether a user is named Tangotango or Tangomango, if the user behind the usernames is the same, then the quality of contributions from that account does not change.
Some may argue that a change in username reduces name recognition; however, countless users have successfully changed their on-wiki names to the point that the user rename is forgotten. There is really no inherent value in a Wikimedia username, like there is in a domain name.
You assert that "[SUL] forces good faith users to change their username". Sure, but that's only because we have a bad legacy of conflicting usernames on the 600 or so wikis we have, something that probably should not have been the case in the first place. Also, are that many "good faith users" actually affected? (Brion may have posted the figure somewhere before, but I can't find it right now.)
You also say that SUL will "[clog] up the username namespace even more than it already is". What username namespace? Do you mean the User: namespace on all wikis? The number of user pages certainly will not change with SUL; the number of people using a wiki will not change significantly just because of SUL. If you mean the number of registered users, the unified login script, as I understand it, does not go and automatically create an account on every single wiki for a particular user; in fact, by unifying preferences such as passwords and emails, it can be argued that SUL will actually *clean up* the user databases. It will be much less of a pain to change your email address, for example. However, I'm not going to pretend that I'm a SUL expert; I've only read through some of the documentation that Brion has provided.
In short, I don't really understand what long-term disadvantages SUL will bring to the Wikimedia universe; I can only see it as a positive (and logical) thing to do.
Cheers,
Tangotango
On 8/13/07, Tangotango tangotango@ts.wikimedia.org wrote:
On Aug 13, 2007, at 10:00 PM, Anthony wrote:
To use an analogy, let's say I come up with a plan for Single Domain Name Resolution (SDNR). Forcing Wikipedia to register so many domain names (wikipedia.com/wikipedia.net/wikipedia.org/etc) is silly, so why not let them register one address for all. So under SDNR, we merge .com, .net, and .org. Companies register for one of the three addresses and they automatically get all three. There's no longer a need to type in "slashdot.com", I can just type in "slashdot". In case of any conflict, where two people picked the same second level domain name part, we look at how much traffic the various domain names get and whoever gets the most traffic gets all three domain names. Happiness.org (alexa rank 1,743,585) has 3 months to come up with a new domain name or we change it for them, to happiness-usurped.org. After all, Happiness.com (alexa rank 1,262,045) gets more traffic.
I'm not sure if I follow your analogy there, Anthony. Domain names have an importance almost akin to a trademark on the Internet, and companies use ridiculous amounts of resources for the upkeep of their domains and usurpation of any conflicting ones.
A Wikimedia username, on the other hand, is merely a unique identifier that identifies a person. Whether a user is named Tangotango or Tangomango, if the user behind the usernames is the same, then the quality of contributions from that account does not change.
Well, I think it's a good analogy. Not perfect, as no analogy is, but a good one. But if usernames don't matter, then what's the point of having SUL in the first place? Just use an internal identifier (User:8974287434) and keep everyone's public username(s) exactly the same.
You assert that "[SUL] forces good faith users to change their username". Sure, but that's only because we have a bad legacy of conflicting usernames on the 600 or so wikis we have, something that probably should not have been the case in the first place. Also, are that many "good faith users" actually affected? (Brion may have posted the figure somewhere before, but I can't find it right now.)
The figure is increasing daily, and probably has increased dramatically in the past few months. We have user:goddess and user:HAL, and user:H, and user:Nat, and user:Anthony, and user:Stu, and user:Glen all on en.wikipedia. I can't imagine these names aren't duplicated on any other wikis.
IF SUL was implemented from the beginning, it would have been fine. (Same thing, by the way, with the whole .com/.net/.org analogy.) But it wasn't implemented from the beginning.
You also say that SUL will "[clog] up the username namespace even more than it already is". What username namespace? Do you mean the User: namespace on all wikis?
I don't mean namespace in the technical mediawiki sense. It was a bad choice of phrasing.
What I mean, in a nutshell, is that it's going to get 10 times harder for new users to pick a username.
The number of user pages certainly will not change with SUL; the number of people using a wiki will not change significantly just because of SUL. If you mean the number of registered users, the unified login script, as I understand it, does not go and automatically create an account on every single wiki for a particular user;
SUL, as I understand it, locks every username so that the same name cannot be created on any other wiki. That, as it was explained to me, is precisely what SUL is.
in fact, by unifying preferences such as passwords and emails, it can be argued that SUL will actually *clean up* the user databases.
None of those are features of SUL, as it was explained to me. SUL, as it was explained to me, is a "feature" where every user has the same username on all wikis.
If I am incorrect (or for that matter, if I'm correct), I'd appreciate it if someone would point us to an official description of SUL.
It will be much less of a pain to change your email address, for example. However, I'm not going to pretend that I'm a SUL expert; I've only read through some of the documentation that Brion has provided.
In short, I don't really understand what long-term disadvantages SUL will bring to the Wikimedia universe; I can only see it as a positive (and logical) thing to do.
On 8/13/07, Anthony wikitech@inbox.org wrote:
If I am incorrect (or for that matter, if I'm correct), I'd appreciate it if someone would point us to an official description of SUL.
Here's a description, though I have no way of knowing whether or not it's correct:
"The upcoming unified login system combines the user accounts for all of these projects. The greatest advantages are single sign-up (you don't have to create your account again on each new project you get involved with; your existing username comes with you) and consistent identity (your username now always means you; no one else can take your name on another project)."
"Registering a username reserves it everywhere; this means different users can no longer register the same account on different wikis. Users only need to set and confirm their email address in one account. Future changes may alert users when they have received a message on any wiki, but this is not yet available."
http://meta.wikimedia.org/wiki/H:UL
By the way, I was wrong when I said that unifying passwords and emails are not part of SUL. Unifying passwords and emails is part of SUL. Unifying of other preferences isn't.
"User preferences are local, although the email address only needs to be set and confirmed in one place. You can continue to have different preferences on different sites."
On Aug 13, 2007, at 10:41 PM, Anthony wrote:
Well, I think it's a good analogy. Not perfect, as no analogy is, but a good one. But if usernames don't matter, then what's the point of having SUL in the first place? Just use an internal identifier (User:8974287434) and keep everyone's public username(s) exactly the same.
I should have been clearer - I meant that it doesn't matter what a user is called, *as long as they have a unique name* that does not cause confusion (i.e., is the same across all Wikimedia wikis).
Because people have conflicting usernames across wikis, there is much confusion as to the true identity of users who register on multiple Wikimedia wikis. That's why we have vandals impersonating admins of larger wikis on smaller wikis, and people being forced to do all sorts of arcane things (like linking to an edit authorizing a particular account as their own when voting for Wikimedia-wide elections or applying for adminship on Meta, etc.)
A globally unique numeric identifier would also serve the same purpose, but most humans just don't remember numbers as well as strings, so I wouldn't call it a user-friendly way to do things.
You assert that "[SUL] forces good faith users to change their username". Sure, but that's only because we have a bad legacy of conflicting usernames on the 600 or so wikis we have, something that probably should not have been the case in the first place. Also, are that many "good faith users" actually affected? (Brion may have posted the figure somewhere before, but I can't find it right now.)
The figure is increasing daily, and probably has increased dramatically in the past few months. We have user:goddess and user:HAL, and user:H, and user:Nat, and user:Anthony, and user:Stu, and user:Glen all on en.wikipedia. I can't imagine these names aren't duplicated on any other wikis.
Without hard data to back this up, I'm not sure if this is an issue. (I mean, of course, the people actually affected are not going to feel the same way, and I do not mean to belittle their feelings in any way.) In the long run, will this adversely affect our goals to provide free knowledge to the world?
IF SUL was implemented from the beginning, it would have been fine. (Same thing, by the way, with the whole .com/.net/.org analogy.) But it wasn't implemented from the beginning.
I personally think we should be looking at the Wikimedia projects from a long-term point of view; if we want the Wikimedia projects to be still available for the next generation, we should be thinking longer than the average Wikimedian's active length (mere months or sometimes a couple of years).
The domain thing is rather a bit different; unifying something like that (and I'm not saying that's a good idea, since domains represent a hierarchy, as opposed to usernames, which are just strings), deployed across millions of computers across the world, is more than a few times more difficult than unifying Wikimedia usernames. I'm sure SUL is also difficult enough, but at least it's possible with few, if any, long-term adverse effects.
What I mean, in a nutshell, is that it's going to get 10 times harder for new users to pick a username.
True, but is that a problem? This happens to all popular sites. It's hard to get a Gmail or Hotmail username you want, because so many people have already got one they want. Incidentally, this is also the case for most top-level domains. However, people can be creative! The supply of intelligible usernames is almost unlimited. The slight inconvenience of trying to find an available username should not interfere with the best interests of the Wikimedia projects.
Cheers,
Tangotango
On 8/13/07, Tangotango tangotango@ts.wikimedia.org wrote:
On Aug 13, 2007, at 10:41 PM, Anthony wrote:
Well, I think it's a good analogy. Not perfect, as no analogy is, but a good one. But if usernames don't matter, then what's the point of having SUL in the first place? Just use an internal identifier (User:8974287434) and keep everyone's public username(s) exactly the same.
I should have been clearer - I meant that it doesn't matter what a user is called, *as long as they have a unique name* that does not cause confusion (i.e., is the same across all Wikimedia wikis).
I guess I just have to disagree. It does matter to me what my username is, and I think it matters to a lot of other people too.
Because people have conflicting usernames across wikis, there is much confusion as to the true identity of users who register on multiple Wikimedia wikis. That's why we have vandals impersonating admins of larger wikis on smaller wikis, and people being forced to do all sorts of arcane things (like linking to an edit authorizing a particular account as their own when voting for Wikimedia-wide elections or applying for adminship on Meta, etc.)
A globally unique numeric identifier would also serve the same purpose, but most humans just don't remember numbers as well as strings, so I wouldn't call it a user-friendly way to do things.
I just don't think the problem you describe is enough reason to screw things up for all those people who don't have the problem. A globally unique numeric identifier is what should be the first step. Then all those features which are supposedly dependent on SUL can be implemented. In reality nothing is dependent on SUL.
SUL also has the potential to create confusion, when people are forced to change their longstanding username and all those urls to their user page suddenly point to someone else's user page. I don't have any hard numbers on this, although I don't have any hard numbers on the number of times admins have been impersonated either. My sense is that the problems caused to those who are going to have to change their username are greater, but if I decide to start a true campaign to eliminate SUL I'll get better numbers. Maybe I should start contacting users with lots of contributions whose username conflicts with other users with lots of contributions and let them know about this plan to force them to change their name. Maybe I'm even wrong and this isn't going to be as big of a problem as I imagine.
Maybe SUL makes sense for admins, or at least for those admins who participate on multiple projects. Maybe it makes sense where there's no current conflict. Maybe it makes sense on a per-language basis. But I think en.wikipedia.User:Anthony and fr.wikipedia.User:Anthony should be able to get along. I'll probably win the eventual conflict between us, as fr.wikipedia.User:Anthony doesn't have very many edits, but I don't think there should have to be a winner. The two of us have gotten along perfectly fine without SUL.
You assert that "[SUL] forces good faith users to change their username". Sure, but that's only because we have a bad legacy of conflicting usernames on the 600 or so wikis we have, something that probably should not have been the case in the first place. Also, are that many "good faith users" actually affected? (Brion may have posted the figure somewhere before, but I can't find it right now.)
The figure is increasing daily, and probably has increased dramatically in the past few months. We have user:goddess and user:HAL, and user:H, and user:Nat, and user:Anthony, and user:Stu, and user:Glen all on en.wikipedia. I can't imagine these names aren't duplicated on any other wikis.
Without hard data to back this up, I'm not sure if this is an issue. (I mean, of course, the people actually affected are not going to feel the same way, and I do not mean to belittle their feelings in any way.) In the long run, will this adversely affect our goals to provide free knowledge to the world?
I think it will slightly, because I think it's going to be bothered by it. But besides that, there's one thing that *is* adversely affecting our goals to provide free knowledge to the world, and that's the fact that every time some feature is brought up like global blocking or global talk page notification or global language preferences, it gets put on hold because "that won't happen until after SUL".
IF SUL was implemented from the beginning, it would have been fine. (Same thing, by the way, with the whole .com/.net/.org analogy.) But it wasn't implemented from the beginning.
I personally think we should be looking at the Wikimedia projects from a long-term point of view; if we want the Wikimedia projects to be still available for the next generation, we should be thinking longer than the average Wikimedian's active length (mere months or sometimes a couple of years).
I think I am thinking from a long-term point of view, and frankly I don't see why you'd try to say I'm not.
The domain thing is rather a bit different; unifying something like that (and I'm not saying that's a good idea, since domains represent a hierarchy, as opposed to usernames, which are just strings), deployed across millions of computers across the world, is more than a few times more difficult than unifying Wikimedia usernames. I'm sure SUL is also difficult enough, but at least it's possible with few, if any, long-term adverse effects.
Fair enough. I'm keeping the domain name analogy in my toolbox for trying to convince others, because I think it's a good one, but I accept that it wasn't a good analogy to convince you of anything.
What I mean, in a nutshell, is that it's going to get 10 times harder for new users to pick a username.
True, but is that a problem?
It's a problem, but if it were the only problem I might overlook it. The major problem in my opinion is that SUL requires some people (let's say, more than 10 people) who have registered a username in good faith, to change that username.
On Aug 14, 2007, at 12:00 AM, Anthony wrote:
I guess I just have to disagree. It does matter to me what my username is, and I think it matters to a lot of other people too.
I guess it's a matter of different values, and partly because you have a short, easy-to-remember username. :) However I think most people do tend to judge users by their contributions, rather than their username (unless it's very silly!).
I just don't think the problem you describe is enough reason to screw things up for all those people who don't have the problem. A globally unique numeric identifier is what should be the first step. Then all those features which are supposedly dependent on SUL can be implemented. In reality nothing is dependent on SUL.
Well, I agree it's not a huge problem, but it would certainly make a lot of people's lives easier. I don't think it would really screw things up for anybody - I've considered changing my username in the past, since it may be (and has been) confused with User:Tango, and having seen many people change their username recently, especially on the English Wikipedia, I have the feeling it hasn't taken them too much effort to do that.
As far as I've seen, none of the informed devs have told us that "XYZ is dependent on SUL". They've said "XYZ is made easier by SUL", but nothing about dependencies. My assumption is that they would just be reinventing the wheel if they implemented a global function (like global blocking), and then enabled SUL, so they've just elected not to do it until SUL is here. I would do the same in my own software; no programmer likes to write the same or similar code for two tasks if code can be shared between the two.
On the other hand, various people, on the mailing lists and Bugzilla, have told us that "XYZ is dependent on SUL". Most instances of these, as far as I know, are simply misinformed. So yes, I think you're right, nothing, besides SUL itself, is *dependent* on SUL.
SUL also has the potential to create confusion, when people are forced to change their longstanding username and all those urls to their user page suddenly point to someone else's user page.
I assume there are only going to be a few isolated cases where the username ABC is shared by person A on wiki 1 and person B on wiki 2, and both people have substantial contributions and are integral parts of their respective communities (User:Anthony is, as you cite, an example). There are probably going to be far fewer cases where person A is also an established member of wiki 2, or person B is an established member of wiki 1 (e.g., if you were an established member of both the English and French Wikipedias). In these cases, sure, confusion may arise; but it's not going to be too much of a hassle to put up a message on your user page asking users if they're looking for the right person, in these (probably) isolated cases.
Maybe SUL makes sense for admins, or at least for those admins who participate on multiple projects. Maybe it makes sense where there's no current conflict. Maybe it makes sense on a per-language basis.
I think it makes sense for anybody who participates in multiple projects (that includes, say, users who participate in both the English Wikipedia and Commons), whether an admin or not.
But I think en.wikipedia.User:Anthony and fr.wikipedia.User:Anthony should be able to get along. I'll probably win the eventual conflict between us, as fr.wikipedia.User:Anthony doesn't have very many edits, but I don't think there should have to be a winner. The two of us have gotten along perfectly fine without SUL.
In the grand scheme of things, far more users are going to benefit from being able to log in to Commons with their English Wikipedia accounts. I sympathize with the situation you are in, but I think this is more a technical thing than a who-gets-what-username thing.
I think it will slightly, because I think it's going to be bothered by it. But besides that, there's one thing that *is* adversely affecting our goals to provide free knowledge to the world, and that's the fact that every time some feature is brought up like global blocking or global talk page notification or global language preferences, it gets put on hold because "that won't happen until after SUL".
I wholeheartedly agree with you, especially with global blocking and the like, but as a person who programs, I sometimes have to put off badly-needed features for that "major redesign" myself, so I do realize nobody has bad intentions here. I don't think the devs are treating SUL as anything more than what it is (a nice new centralized backend to replace the currently higgledy-piggledy user accounts on Wikimedia wikis); most of the damage has been done by people who scream SUL for no good reason at all.
I personally think we should be looking at the Wikimedia projects from a long-term point of view; if we want the Wikimedia projects to be still available for the next generation, we should be thinking longer than the average Wikimedian's active length (mere months or sometimes a couple of years).
I think I am thinking from a long-term point of view, and frankly I don't see why you'd try to say I'm not.
Maybe I should have been clearer here, as well; I mean, it doesn't matter that much what today's users are going to experience in the changeover to SUL; if I, for example, had to change my username to Tangomango, and that caused a bit of inconvenience for me, it's not a big deal for Wikimedia, because the projects are still going to develop whatever the username of a lowly user like me happens to be.
However, future users will benefit far more than I will have been inconvenienced. Commons will also benefit from this, as the extra registration step for Commons will no longer be a hurdle for users. (Of course, that may increase the number of copyvios on Commons, but that's another matter.) So you might call it a sacrifice. Or an offering to the deity of future Wikimedians.
Fair enough. I'm keeping the domain name analogy in my toolbox for trying to convince others, because I think it's a good one, but I accept that it wasn't a good analogy to convince you of anything.
Sorry, perhaps I was a little pedantic about this. But I still do think the analogy deals with a far more serious subject than SUL, and has the potential to mislead people who hear your analogy to think of SUL as an apocalyptic being from hell, when it really isn't.
What I mean, in a nutshell, is that it's going to get 10 times harder for new users to pick a username.
True, but is that a problem?
It's a problem, but if it were the only problem I might overlook it. The major problem in my opinion is that SUL requires some people (let's say, more than 10 people) who have registered a username in good faith, to change that username.
We'll just have to disagree on this - I've stated my opinion above.
Cheers,
Tangotango
I might make a longer response later, but I wanted to comment on a few things quickly:
On 8/13/07, Tangotango tangotango@ts.wikimedia.org wrote:
On Aug 14, 2007, at 12:00 AM, Anthony wrote:
But I think en.wikipedia.User:Anthony and fr.wikipedia.User:Anthony should be able to get along. I'll probably win the eventual conflict between us, as fr.wikipedia.User:Anthony doesn't have very many edits, but I don't think there should have to be a winner. The two of us have gotten along perfectly fine without SUL.
In the grand scheme of things, far more users are going to benefit from being able to log in to Commons with their English Wikipedia accounts. I sympathize with the situation you are in, but I think this is more a technical thing than a who-gets-what-username thing.
It is possible to let people log in to Commons with your English Wikipedia account without SUL. First, attach the two accounts using a global identifier (could be a number, and doesn't have to necessarily be seen by anybody). Then, have a login page on commons with three fields - username, wiki, and password.
How do you attach the two accounts without knowing the global identifier? Log into your commons account and type in your en.wikipedia username and password and press "attach". Or log into your en.wikipedia account and type in your commons username and password and press attach.
Commons account usernames could even be used as this global identifier. That'd simplify the login stage - each wiki login would have a spot for username and password and a drop down to select the local wiki or commons.
None of this implies SUL, because users are not required to use the same local username on every wiki. And in fact, doing things this way is going to be a required step before SUL *anyway*, because there has to be a transition period while working through the conflicting usernames.
excuse me for my english level because i speak french but i think i can learn many things with wikimedia think a lot
--------------------------------- Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
On Mon, Aug 13, 2007 at 11:00:17AM -0400, Anthony wrote:
IF SUL was implemented from the beginning, it would have been fine. (Same thing, by the way, with the whole .com/.net/.org analogy.) But it wasn't implemented from the beginning.
[ ... ]
Fair enough. I'm keeping the domain name analogy in my toolbox for trying to convince others, because I think it's a good one, but I accept that it wasn't a good analogy to convince you of anything.
If "the domain name analogy" is what I think it is, it's a poor analogy.
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?
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.
There is a reasonable assumption that can be -- and clearly is -- made, by users, that the entire WMF is under one login namespace. Clearly that is not the case, but I'm pretty sure that those people who know that are a) the people who've signed up on more than one, and couldn't get the same name and b) those people who've made an assumption that anthere@pl.wiki is the same person they think it is (example made up of whole-cloth, but you know what I mean).
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.
Cheers, -- jra
On 8/12/07, Andrew Garrett andrew@epstone.net wrote:
On 8/13/07, xaosflux xaosflux@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Without SUL, could it still be implemented for anon accounts?
We need a central database, which SUL provides. It /could/ be implemented without SUL, but creating a separate central database seems a little silly.
Wouldn't it be possible to create a central database ("mysql> create database central;"), and then use that central database for SUL, whenever it gets implemented (*)?
(*) hopefully never
Andrew Garrett wrote:
This is a fairly major change, so I haven't started work on it. Therefore, questions, comments, suggestions and ridicule are most welcome.
Do you think you could implement it as an extension, even if that means a little extra work? I'm sure that minor changes to the codebase to facilitate such an extension would be mostly accepted. Then you can demonstrate it working for those projects that might want tighter controls.
On the other hand, almost every project I've worked on with tight controls eventually moves toward looser ones.
-mark
On 8/13/07, Mark Jaroski mark@geekhive.net wrote:
Do you think you could implement it as an extension, even if that means a little extra work? I'm sure that minor changes to the codebase to facilitate such an extension would be mostly accepted. Then you can demonstrate it working for those projects that might want tighter controls.
Oops, I missed this one in my replies.
It is /possible/ to implement this functionality in an extension, using the existing userCan hook. However, I think that, from a performance perspective, it would be a lot slower to do so (as the original blocking system check would have to be performed, as well as that for the improved system. The intention of the changes is to make the data structure and functionality for blocking both more flexible, and less convoluted - and I think that the best way to have it implemented is in core code.
This much complexity in blocking definitely isn't a good idea for core.
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
This much complexity in blocking definitely isn't a good idea for core.
I'm not sure what's so incredibly complicated about replacing two arbitrary flags with three or four well-structured, nullable fields.
On 8/12/07, Rob Church robchur@gmail.com wrote:
At first blush, it seems that you're going to over-complicate the blocking system. Can you explain how this will improve upon the current nightmare that means we have multiple blocks with different flags expiring all over the place? Can you further explain how you plan to keep this as simple to use as possible?
I disagree that this will over-complicate the blocking system. I think that, so long as I design the interface properly, no further complication will be experienced from a user perspective. I'm unsure of whether you're suggesting that it will be complicated from a technical perspective.
As for how this improves the current system, I think that it will be advantageous in that it will remove the current arbitrary flags, as well as lending a great deal of flexibility - and the number of votes for bugs 674 and 1394 demonstrate how important this is to the user community.
In passing, I'm not sure entirely where you're getting the idea that we have "multiple blocks with different flags expiring all over the place". I presume this was intended to give an impression of complexity, but I don't really see the issue - of course we're going to have multiple blocks, and some of these blocks will have multiple flags. The fact is that the blocking system, while a little convoluted at the moment, can be understood, and a little extra functionality is not going to make much of a difference.
SUL discussion could perhaps be broken off into another thread?
On 8/13/07, Andrew Garrett andrew@epstone.net wrote:
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
This much complexity in blocking definitely isn't a good idea for core.
I'm not sure what's so incredibly complicated about replacing two arbitrary flags with three or four well-structured, nullable fields.
As far as I can see, you'll reduce the number of flags from four to two, while increasing the number of fields from three to five or six or seven or something. That doesn't look like a decrease in complexity. If you were to ask why we don't replace the two permission-specific flags (createaccount/email -- the latter not even being a proper permission) with a generic permission-selection mechanism that would allow blocking any existing permission the user has, matched against a global whitelist (no blocking 'read' on Wikimedia projects!): that might be a good core feature. It would unify some existing features while fulfilling multiple other feature requests. But to also allow the permission to apply to individual pages/users/etc. is unnecessarily complex for core, and arguably not desirable altogether.
A more detailed proposal of exactly what schema and UI changes will be made might allow more explicit criticism and countersuggestions.
On 8/13/07, Andrew Garrett andrew@epstone.net wrote:
It is /possible/ to implement this functionality in an extension, using the existing userCan hook. However, I think that, from a performance perspective, it would be a lot slower to do so (as the original blocking system check would have to be performed, as well as that for the improved system.
To which the solution is to adjust hooks so that's not the case. Ideally, we should probably allow extensions to easily override any query in the software for exactly this reason, to avoid having to throw away or repeat queries.
Therefore, I want to replace the current ipb_address field with a number of nullable fields, including address (username or IP address, as it is now), namespace, page, exempted groups, and permission. If all of the non-null fields match, the block will apply.
I like the idea. I don't think it is too complicated for core. It should be 100% backwards compatible if done correctly (just make namespace and page default to NULL, exempted groups default to ipblock-exempt [ok, that's a permission, not a group, but that shouldn't be too much of a problem] for ip blocks and NULL for username blocks and permission default to edit and move, or whatever the appropriate combination is). The new functionality can then be put on a new Special:AdvancedBlock page.
In the process of doing all this, the User::isBlocked() and User::isBlockedFrom() methods should be deprecated. It would make everything much simpler if it all went through userCan().
wikitech-l@lists.wikimedia.org