I've just sent this to wikitech-l, but what I'm proposing is a *big* hammer, so needs lots of due consideration. Please pick holes in the idea.
- d.
---------- Forwarded message ---------- From: David Gerard dgerard@gmail.com Date: 31 Jan 2008 10:18 Subject: Wikimedia-wide global blocking mechanism? To: Wikimedia developers wikitech-l@lists.wikimedia.org
Discussions on the checkuser list (which is Wikimedia-wide) suggest that an all-project blocking mechanism would be very useful in keeping our more persistent vandals from hopping from project to project, wreaking havoc. This happens quite a bit.
A variant of Wikia's regex block would be a likely candidate for a useful implementation.
One detail it would need (in some coder's Copious Free Time) would be an option to unblock a globally-blocked IP or range locally. (One use case would be a local ISP which has several good editors from a small project, but has open proxies or similar that are a source of vandalism on many other projects.)
Presumably such a global block would only be available to stewards, on due consideration.
Before anyone starts coding - what are the devs' thoughts on a global blocking mechanism? What could go badly wrong?
- d.
I am for that completely. We will need one global admin list, too.
On 1/31/08, David Gerard dgerard@gmail.com wrote:
I've just sent this to wikitech-l, but what I'm proposing is a *big* hammer, so needs lots of due consideration. Please pick holes in the idea.
- d.
---------- Forwarded message ---------- From: David Gerard dgerard@gmail.com Date: 31 Jan 2008 10:18 Subject: Wikimedia-wide global blocking mechanism? To: Wikimedia developers wikitech-l@lists.wikimedia.org
Discussions on the checkuser list (which is Wikimedia-wide) suggest that an all-project blocking mechanism would be very useful in keeping our more persistent vandals from hopping from project to project, wreaking havoc. This happens quite a bit.
A variant of Wikia's regex block would be a likely candidate for a useful implementation.
One detail it would need (in some coder's Copious Free Time) would be an option to unblock a globally-blocked IP or range locally. (One use case would be a local ISP which has several good editors from a small project, but has open proxies or similar that are a source of vandalism on many other projects.)
Presumably such a global block would only be available to stewards, on due consideration.
Before anyone starts coding - what are the devs' thoughts on a global blocking mechanism? What could go badly wrong?
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 31/01/2008, Milos Rancic millosh@gmail.com wrote:
I am for that completely. We will need one global admin list, too.
That's why I was thinking of the stewards, though that assumes they want the job!
- d.
On 31/01/2008, Milos Rancic millosh@gmail.com wrote:
I am for that completely. We will need one global admin list, too.
That's why I was thinking of the stewards, though that assumes they want the job!
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
For small wikis without an admin the global block list seems to be a good option, much better one than waiting for one of the stewards to come and block the vandals. For big ones - I am not so sure, since the vandals are unregistered anyway, and blocking an IP range for English or Dutch wiki could do some harm. May be to exclude first 20 wikis from authomatick blocking?
For the global admin list, I was under understanding that stewards are actually doing the job.
Cheers, Yaroslav
On 31/01/2008, Yaroslav M. Blanter putevod@mccme.ru wrote:
For the global admin list, I was under understanding that stewards are actually doing the job.
Yes, stewards have a lot of the higher administrative powers for small wikis that don't have much of a community yet. Including checkuser, so the stewards using checkuser are on checkuser-l and haven't yet screamed in horror at the notion ;-)
- d.
Yeah, it's not perfect, but it seems like it would be a good tool for stewards to have. Only thing is, I'm envisioning a scenario where a valid user with good contribs gets blocked, doesn't user meta, tries to get unblocked at his home project, but cannot because he's not locally blocked, and the user doesn't know how to get in touch with a steward (Because he doesn't know of this policy) or doesn't understand how to communicate with one. I don't think it's necessarily that big of a deal, but I think it will need a LOT of localization to be effective.
-Dan On Jan 31, 2008, at 7:14 AM, David Gerard wrote:
On 31/01/2008, Yaroslav M. Blanter putevod@mccme.ru wrote:
For the global admin list, I was under understanding that stewards are actually doing the job.
Yes, stewards have a lot of the higher administrative powers for small wikis that don't have much of a community yet. Including checkuser, so the stewards using checkuser are on checkuser-l and haven't yet screamed in horror at the notion ;-)
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
The ability for local sysops to override it would help this a bit, but ideally, it should be restricted to blocking IPs only until SUL is implemented.
Dan Rosenthal wrote:
Yeah, it's not perfect, but it seems like it would be a good tool for stewards to have. Only thing is, I'm envisioning a scenario where a valid user with good contribs gets blocked, doesn't user meta, tries to get unblocked at his home project, but cannot because he's not locally blocked, and the user doesn't know how to get in touch with a steward (Because he doesn't know of this policy) or doesn't understand how to communicate with one. I don't think it's necessarily that big of a deal, but I think it will need a LOT of localization to be effective.
-Dan On Jan 31, 2008, at 7:14 AM, David Gerard wrote:
On 31/01/2008, Yaroslav M. Blanter putevod@mccme.ru wrote:
For the global admin list, I was under understanding that stewards are actually doing the job.
Yes, stewards have a lot of the higher administrative powers for small wikis that don't have much of a community yet. Including checkuser, so the stewards using checkuser are on checkuser-l and haven't yet screamed in horror at the notion ;-)
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
or we just agree that it will only be used for IP's (and if I'd have to say it, only for short terms, so that overriding would not be a big issue too. ) If we agree on that, I think we should be able to trust the stewards to adhere to that, and there would be no need to also make sure it is not technically possible.
BR, Eia
2008/1/31, Alex mrzmanwiki@gmail.com:
The ability for local sysops to override it would help this a bit, but ideally, it should be restricted to blocking IPs only until SUL is implemented.
Dan Rosenthal wrote:
Yeah, it's not perfect, but it seems like it would be a good tool for stewards to have. Only thing is, I'm envisioning a scenario where a valid user with good contribs gets blocked, doesn't user meta, tries to get unblocked at his home project, but cannot because he's not locally blocked, and the user doesn't know how to get in touch with a steward (Because he doesn't know of this policy) or doesn't understand how to communicate with one. I don't think it's necessarily that big of a deal, but I think it will need a LOT of localization to be effective.
-Dan On Jan 31, 2008, at 7:14 AM, David Gerard wrote:
On 31/01/2008, Yaroslav M. Blanter putevod@mccme.ru wrote:
For the global admin list, I was under understanding that stewards are actually doing the job.
Yes, stewards have a lot of the higher administrative powers for small wikis that don't have much of a community yet. Including checkuser, so the stewards using checkuser are on checkuser-l and haven't yet screamed in horror at the notion ;-)
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
-- Alex (en:User:Mr.Z-man)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
I'm on Checkuser-l and I'm not going to reveal which IP provoked this discussion. However the block was generally agreed at one year in this case. Yes, it is our old friend Willy on Wheels.
In cases like this where you are restricted to short blocks you are just making more work. When you've permanently blocked a dozen vandal accounts registered through an IP over a period of months you want the option to block the IP for a long term.
Brian McNeil
-----Original Message----- From: foundation-l-bounces@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of effe iets anders Sent: 31 January 2008 19:39 To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] Fwd: Wikimedia-wide global blocking mechanism?
or we just agree that it will only be used for IP's (and if I'd have to say it, only for short terms, so that overriding would not be a big issue too. ) If we agree on that, I think we should be able to trust the stewards to adhere to that, and there would be no need to also make sure it is not technically possible.
BR, Eia
2008/1/31, Alex mrzmanwiki@gmail.com:
The ability for local sysops to override it would help this a bit, but ideally, it should be restricted to blocking IPs only until SUL is implemented.
Dan Rosenthal wrote:
Yeah, it's not perfect, but it seems like it would be a good tool for stewards to have. Only thing is, I'm envisioning a scenario where a valid user with good contribs gets blocked, doesn't user meta, tries to get unblocked at his home project, but cannot because he's not locally blocked, and the user doesn't know how to get in touch with a steward (Because he doesn't know of this policy) or doesn't understand how to communicate with one. I don't think it's necessarily that big of a deal, but I think it will need a LOT of localization to be effective.
-Dan On Jan 31, 2008, at 7:14 AM, David Gerard wrote:
On 31/01/2008, Yaroslav M. Blanter putevod@mccme.ru wrote:
For the global admin list, I was under understanding that stewards are actually doing the job.
Yes, stewards have a lot of the higher administrative powers for small wikis that don't have much of a community yet. Including checkuser, so the stewards using checkuser are on checkuser-l and haven't yet screamed in horror at the notion ;-)
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
-- Alex (en:User:Mr.Z-man)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Short blocks are not bad. Robots like this tend to change IP anyway, and a short block will just stop them to work. I followed the discussion as well (as a steward also on that list), but I think that if the bot would be stopped, and it would become active again, it would comparitative be a very small efford to stop it. Just one click on the button. If we want to stop it for a longer time, there are more issues at stake, and that would imho require a much more complicated policy and discussion, both now and at the moment it would be blocked.
Another reason is that if we stick to one day, or something in the same order of magnitude, it is clearly something within the scope of the stewards. If we go much longer, I am not so sure about that any more. I don't say it is not, but I would have doubts about it. With one day, it is clear, as it is just an emergency measure.
In the discussion you mention, I think the main reason to choose for such a long time was because it is such a big of an efford to block it. (promote, block, degrade, and that 400-or-so times) With this feature, it would be one single action.
Best regards,
Eia
2008/1/31, Brian McNeil brian.mcneil@wikinewsie.org:
I'm on Checkuser-l and I'm not going to reveal which IP provoked this discussion. However the block was generally agreed at one year in this case. Yes, it is our old friend Willy on Wheels.
In cases like this where you are restricted to short blocks you are just making more work. When you've permanently blocked a dozen vandal accounts registered through an IP over a period of months you want the option to block the IP for a long term.
Brian McNeil
The problem is, these people abuse open proxies in countries where many providers have, for whatever reason, choosen to have a policy of open proxies. Which means you will block most of a country with this policy of yours even on their homewiki. That is not really what you want is it?
Waerth
I'm on Checkuser-l and I'm not going to reveal which IP provoked this discussion. However the block was generally agreed at one year in this case. Yes, it is our old friend Willy on Wheels.
In cases like this where you are restricted to short blocks you are just making more work. When you've permanently blocked a dozen vandal accounts registered through an IP over a period of months you want the option to block the IP for a long term.
Brian McNeil
-----Original Message----- From: foundation-l-bounces@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of effe iets anders Sent: 31 January 2008 19:39 To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] Fwd: Wikimedia-wide global blocking mechanism?
or we just agree that it will only be used for IP's (and if I'd have to say it, only for short terms, so that overriding would not be a big issue too. ) If we agree on that, I think we should be able to trust the stewards to adhere to that, and there would be no need to also make sure it is not technically possible.
BR, Eia
2008/1/31, Alex mrzmanwiki@gmail.com:
The ability for local sysops to override it would help this a bit, but ideally, it should be restricted to blocking IPs only until SUL is implemented.
Dan Rosenthal wrote:
Yeah, it's not perfect, but it seems like it would be a good tool for stewards to have. Only thing is, I'm envisioning a scenario where a valid user with good contribs gets blocked, doesn't user meta, tries to get unblocked at his home project, but cannot because he's not locally blocked, and the user doesn't know how to get in touch with a steward (Because he doesn't know of this policy) or doesn't understand how to communicate with one. I don't think it's necessarily that big of a deal, but I think it will need a LOT of localization to be effective.
-Dan On Jan 31, 2008, at 7:14 AM, David Gerard wrote:
On 31/01/2008, Yaroslav M. Blanter putevod@mccme.ru wrote:
For the global admin list, I was under understanding that stewards are actually doing the job.
Yes, stewards have a lot of the higher administrative powers for small wikis that don't have much of a community yet. Including checkuser, so the stewards using checkuser are on checkuser-l and haven't yet screamed in horror at the notion ;-)
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
-- Alex (en:User:Mr.Z-man)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
There is certainly no plan to use this to block entire countries. The issue, as others have stated, is where we have a persistent and patient vandal. Willy on Wheels is the ideal example of this; I'd swear he writes down when blocks expire and just starts vandalising again when they do so.
I assure you that the people involved from the CheckUser group do not lightly ask for this tool. The IP that provoked this was UK-based, and I for one would welcome input on exceptions for Mid-East and Asian countries where a limited number of proxies are the population's gateway to the Internet. The vandals abusing such proxies are generally not among such ISP's subscriber base and - with help from someone on language - we can try and persuade the ISP in question to firewall the proxy appropriately or enable xff.
In any case I personally wouldn't have access to such a tool. I would have to justify application of a global block to a steward and have evidence from other checkusers that the IP was problematic on several wikis. Before anyone gets to that stage the IP will have been investigated. If it is a proxy for an entire country - as I say above - then a different approach may be required, and a far shorter block would be applied.
Brian McNeil
-----Original Message----- From: foundation-l-bounces@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of Waerth Sent: 01 February 2008 08:43 To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] Fwd: Wikimedia-wide global blocking mechanism?
The problem is, these people abuse open proxies in countries where many providers have, for whatever reason, choosen to have a policy of open proxies. Which means you will block most of a country with this policy of yours even on their homewiki. That is not really what you want is it?
Waerth
I'm on Checkuser-l and I'm not going to reveal which IP provoked this discussion. However the block was generally agreed at one year in this
case.
Yes, it is our old friend Willy on Wheels.
In cases like this where you are restricted to short blocks you are just making more work. When you've permanently blocked a dozen vandal accounts registered through an IP over a period of months you want the option to block the IP for a long term.
Brian McNeil
-----Original Message----- From: foundation-l-bounces@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of effe iets anders Sent: 31 January 2008 19:39 To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] Fwd: Wikimedia-wide global blocking mechanism?
or we just agree that it will only be used for IP's (and if I'd have to say it, only for short terms, so that overriding would not be a big issue too. ) If we agree on that, I think we should be able to trust the stewards to adhere to that, and there would be no need to also make sure it is not technically possible.
BR, Eia
2008/1/31, Alex mrzmanwiki@gmail.com:
The ability for local sysops to override it would help this a bit, but ideally, it should be restricted to blocking IPs only until SUL is implemented.
Dan Rosenthal wrote:
Yeah, it's not perfect, but it seems like it would be a good tool for stewards to have. Only thing is, I'm envisioning a scenario where a valid user with good contribs gets blocked, doesn't user meta, tries to get unblocked at his home project, but cannot because he's not locally blocked, and the user doesn't know how to get in touch with a steward (Because he doesn't know of this policy) or doesn't understand how to communicate with one. I don't think it's necessarily that big of a deal, but I think it will need a LOT of localization to be effective.
-Dan On Jan 31, 2008, at 7:14 AM, David Gerard wrote:
On 31/01/2008, Yaroslav M. Blanter putevod@mccme.ru wrote:
For the global admin list, I was under understanding that stewards are actually doing the job.
Yes, stewards have a lot of the higher administrative powers for small wikis that don't have much of a community yet. Including checkuser, so the stewards using checkuser are on checkuser-l and haven't yet screamed in horror at the notion ;-)
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
-- Alex (en:User:Mr.Z-man)
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 01/02/2008, Brian McNeil brian.mcneil@wikinewsie.org wrote:
In any case I personally wouldn't have access to such a tool. I would have to justify application of a global block to a steward and have evidence from other checkusers that the IP was problematic on several wikis. Before anyone gets to that stage the IP will have been investigated. If it is a proxy for an entire country - as I say above - then a different approach may be required, and a far shorter block would be applied.
Yeah. Wide blocks - an ISP or a country *cough*Qatar*cough* - should be no more than a few minutes, just to stop vandalism in progress. Such blocks wouldn't be the sort of thing to be applied cross-wiki, I'd think.
- d.
On 31/01/2008, Alex mrzmanwiki@gmail.com wrote:
The ability for local sysops to override it would help this a bit, but ideally, it should be restricted to blocking IPs only until SUL is implemented.
SUL will only help where people use exactly the same username on each site they need to be blocked from - vandals smart enough to jump projects when one catches them are likely to realise they need to use a different name (just hopefully one similar enough for a regex to catch).
Thomas Dalton wrote:
On 31/01/2008, Alex mrzmanwiki@gmail.com wrote:
The ability for local sysops to override it would help this a bit, but ideally, it should be restricted to blocking IPs only until SUL is implemented.
SUL will only help where people use exactly the same username on each site they need to be blocked from - vandals smart enough to jump projects when one catches them are likely to realise they need to use a different name (just hopefully one similar enough for a regex to catch).
I'd be more worried about a good user on one project using the same name as a bad user on other projects. The odds of that happening are low, but still possible. I also doubt that most vandals would be dumb enough to be caught by a regex that wouldn't also have a good chance at having a high potential for collateral damage. On a side note, how well does regex handle non-latin characters?
On 31/01/2008, Alex mrzmanwiki@gmail.com wrote:
The ability for local sysops to override it would help this a bit, but ideally, it should be restricted to blocking IPs only until SUL is implemented.
Surely, until SUL is implemented, it would be pretty much impossible to block a specific user with such a tool?
--- Dan Rosenthal swatjester@gmail.com wrote:
Yeah, it's not perfect, but it seems like it would be a good tool for stewards to have. Only thing is, I'm envisioning a scenario where a valid user with good contribs gets blocked, doesn't user meta, tries to get unblocked at his home project, but cannot because he's not locally blocked, and the user doesn't know how to get in touch with a steward (Because he doesn't know of this policy) or doesn't understand how to communicate with one. I don't think it's necessarily that big of a deal, but I think it will need a LOT of localization to be effective.
This is the key problem. I think that unless we are capable of notifing all wikis of about the workings of this process in a language they are proficient taking blocks Wikimedia wide will cause a lot of harm. Of course an opt-in system would be very workable.
Birgitte SB
____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
On 31/01/2008, Birgitte SB birgitte_sb@yahoo.com wrote:
This is the key problem. I think that unless we are capable of notifing all wikis of about the workings of this process in a language they are proficient taking blocks Wikimedia wide will cause a lot of harm. Of course an opt-in system would be very workable.
Would logging it in the local block-log system be an acceptable method of notification?
Andrew Gray wrote:
On 31/01/2008, Birgitte SB birgitte_sb@yahoo.com wrote:
This is the key problem. I think that unless we are capable of notifing all wikis of about the workings of this process in a language they are proficient taking blocks Wikimedia wide will cause a lot of harm. Of course an opt-in system would be very workable.
Would logging it in the local block-log system be an acceptable method of notification?
Ideally (at least to me) it would create an entry in each project's block log and ipblocklist so it could easily be overridden by local sysops so that collateral damage on a few projects would not require it to be globally unblocked. Not sure how technically feasible that would be though.
--- Andrew Gray shimgray@gmail.com wrote:
On 31/01/2008, Birgitte SB birgitte_sb@yahoo.com wrote:
This is the key problem. I think that unless we
are
capable of notifing all wikis of about the
workings of
this process in a language they are proficient
taking
blocks Wikimedia wide will cause a lot of harm.
Of
course an opt-in system would be very workable.
Would logging it in the local block-log system be an acceptable method of notification?
I was more thinking first about a notification that this ability even *exists* before addressing notification individual blocks. However regarding individual blocks what language are you proposing the local log entry be written in?
The only reasonable way to do this is to have the log entries be a consistent pre-arranged formula that links to a local page explaining the system in the local language. The best way to ensure that all this is set-up is to use an opt-in system that requires these things be set-up before blocks .
Anything else means some wiki(s) will wake up one day to realize there are inexplicable blocks in place. Likely with logs entries they cannot read. And very likely when they start making inquiries no one will be able to explain what has happened to them own language leading to further misunderstandings.
Seriously make a system to handle these blocks and require every wiki wishing to join the system file a bug and things will go much more smoothly. If the stewards find they are doing tedious manual blocks on a certain wiki, they can encourage the that wiki to file the bug.
Birgitte SB
____________________________________________________________________________________ Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
Hi,
I agree with your concerns. However, currently a similar system is already active, proxyblocker. This system blocks some (I dont know how many) proxies, detected somewhere in 2005. Dont worry, no new blocks are being added, but some are still in place. The user just gets a message that he is blocked by proxyblocker. We could pick a logical name to appear in the message, that would point to meta. Maybe CrosswikiBlocker, or VandalbotBlocker or something.
Opt-in is not workable. This new thing is mainly for wiki's with no community. You can only opt in if you have a community. Hence, opt in would not work. After all, the stewards mainly have to block bots on wiki's with no or almost no normal edits. when there are people around, and they have sysops and a community, they can handle it themselves generally. However, I would plea for opt-out.
For the unblocking, I do not think that should be a major issue, if we would choose for a maximum of a block in the range of 1 day-1week. In that case, the chance that someone is affected by that block, but is not the person who was doing the malicious edits, is quite slim. Furthermore, that person will survive to wait a day or a week, no big harm done. If it proofs to be a major blocker for a specific community, ie they would only have one IP for a whole country or something, they could opt out.
BR, Eia
2008/1/31, Birgitte SB birgitte_sb@yahoo.com:
--- Andrew Gray shimgray@gmail.com wrote:
On 31/01/2008, Birgitte SB birgitte_sb@yahoo.com wrote:
This is the key problem. I think that unless we
are
capable of notifing all wikis of about the
workings of
this process in a language they are proficient
taking
blocks Wikimedia wide will cause a lot of harm.
Of
course an opt-in system would be very workable.
Would logging it in the local block-log system be an acceptable method of notification?
I was more thinking first about a notification that this ability even *exists* before addressing notification individual blocks. However regarding individual blocks what language are you proposing the local log entry be written in?
The only reasonable way to do this is to have the log entries be a consistent pre-arranged formula that links to a local page explaining the system in the local language. The best way to ensure that all this is set-up is to use an opt-in system that requires these things be set-up before blocks .
Anything else means some wiki(s) will wake up one day to realize there are inexplicable blocks in place. Likely with logs entries they cannot read. And very likely when they start making inquiries no one will be able to explain what has happened to them own language leading to further misunderstandings.
Seriously make a system to handle these blocks and require every wiki wishing to join the system file a bug and things will go much more smoothly. If the stewards find they are doing tedious manual blocks on a certain wiki, they can encourage the that wiki to file the bug.
Birgitte SB
____________________________________________________________________________________Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
The problem with opt-out is that a wiki must know this even *exists* in order to opt-out. So if you are capable of notifing all the village pumps in a language they can comprehend, this is reasonable. If you are not capable of that, opt-out is not reasonable. If this is mainly for wiki's with no community, then allow stewards to "opt-in" such wiki's. If they have no community, they will not object.
Birgitte SB
--- effe iets anders effeietsanders@gmail.com wrote:
Hi,
I agree with your concerns. However, currently a similar system is already active, proxyblocker. This system blocks some (I dont know how many) proxies, detected somewhere in 2005. Dont worry, no new blocks are being added, but some are still in place. The user just gets a message that he is blocked by proxyblocker. We could pick a logical name to appear in the message, that would point to meta. Maybe CrosswikiBlocker, or VandalbotBlocker or something.
Opt-in is not workable. This new thing is mainly for wiki's with no community. You can only opt in if you have a community. Hence, opt in would not work. After all, the stewards mainly have to block bots on wiki's with no or almost no normal edits. when there are people around, and they have sysops and a community, they can handle it themselves generally. However, I would plea for opt-out.
For the unblocking, I do not think that should be a major issue, if we would choose for a maximum of a block in the range of 1 day-1week. In that case, the chance that someone is affected by that block, but is not the person who was doing the malicious edits, is quite slim. Furthermore, that person will survive to wait a day or a week, no big harm done. If it proofs to be a major blocker for a specific community, ie they would only have one IP for a whole country or something, they could opt out.
BR, Eia
2008/1/31, Birgitte SB birgitte_sb@yahoo.com:
--- Andrew Gray shimgray@gmail.com wrote:
On 31/01/2008, Birgitte SB
wrote:
This is the key problem. I think that unless
we
are
capable of notifing all wikis of about the
workings of
this process in a language they are proficient
taking
blocks Wikimedia wide will cause a lot of
harm.
Of
course an opt-in system would be very
workable.
Would logging it in the local block-log system
be an
acceptable method of notification?
I was more thinking first about a notification
that
this ability even *exists* before addressing notification individual blocks. However regarding individual blocks what language are you proposing
the
local log entry be written in?
The only reasonable way to do this is to have the
log
entries be a consistent pre-arranged formula that links to a local page explaining the system in the local language. The best way to ensure that all
this
is set-up is to use an opt-in system that requires these things be set-up before blocks .
Anything else means some wiki(s) will wake up one
day
to realize there are inexplicable blocks in place. Likely with logs entries they cannot read. And
very
likely when they start making inquiries no one
will be
able to explain what has happened to them own
language
leading to further misunderstandings.
Seriously make a system to handle these blocks and require every wiki wishing to join the system file
a
bug and things will go much more smoothly. If the stewards find they are doing tedious manual blocks
on
a certain wiki, they can encourage the that wiki
to
file the bug.
Birgitte SB
____________________________________________________________________________________
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
no or barely a community. Most of the wiki's are small sized, and many show little activity. It is much easier, and would in practice be almost the same, to just automatically opt in projects...
BR, Lodewijk
2008/2/1, Birgitte SB birgitte_sb@yahoo.com:
The problem with opt-out is that a wiki must know this even *exists* in order to opt-out. So if you are capable of notifing all the village pumps in a language they can comprehend, this is reasonable. If you are not capable of that, opt-out is not reasonable. If this is mainly for wiki's with no community, then allow stewards to "opt-in" such wiki's. If they have no community, they will not object.
Birgitte SB
--- effe iets anders effeietsanders@gmail.com wrote:
Hi,
I agree with your concerns. However, currently a similar system is already active, proxyblocker. This system blocks some (I dont know how many) proxies, detected somewhere in 2005. Dont worry, no new blocks are being added, but some are still in place. The user just gets a message that he is blocked by proxyblocker. We could pick a logical name to appear in the message, that would point to meta. Maybe CrosswikiBlocker, or VandalbotBlocker or something.
Opt-in is not workable. This new thing is mainly for wiki's with no community. You can only opt in if you have a community. Hence, opt in would not work. After all, the stewards mainly have to block bots on wiki's with no or almost no normal edits. when there are people around, and they have sysops and a community, they can handle it themselves generally. However, I would plea for opt-out.
For the unblocking, I do not think that should be a major issue, if we would choose for a maximum of a block in the range of 1 day-1week. In that case, the chance that someone is affected by that block, but is not the person who was doing the malicious edits, is quite slim. Furthermore, that person will survive to wait a day or a week, no big harm done. If it proofs to be a major blocker for a specific community, ie they would only have one IP for a whole country or something, they could opt out.
BR, Eia
2008/1/31, Birgitte SB birgitte_sb@yahoo.com:
--- Andrew Gray shimgray@gmail.com wrote:
On 31/01/2008, Birgitte SB
wrote:
This is the key problem. I think that unless
we
are
capable of notifing all wikis of about the
workings of
this process in a language they are proficient
taking
blocks Wikimedia wide will cause a lot of
harm.
Of
course an opt-in system would be very
workable.
Would logging it in the local block-log system
be an
acceptable method of notification?
I was more thinking first about a notification
that
this ability even *exists* before addressing notification individual blocks. However regarding individual blocks what language are you proposing
the
local log entry be written in?
The only reasonable way to do this is to have the
log
entries be a consistent pre-arranged formula that links to a local page explaining the system in the local language. The best way to ensure that all
this
is set-up is to use an opt-in system that requires these things be set-up before blocks .
Anything else means some wiki(s) will wake up one
day
to realize there are inexplicable blocks in place. Likely with logs entries they cannot read. And
very
likely when they start making inquiries no one
will be
able to explain what has happened to them own
language
leading to further misunderstandings.
Seriously make a system to handle these blocks and require every wiki wishing to join the system file
a
bug and things will go much more smoothly. If the stewards find they are doing tedious manual blocks
on
a certain wiki, they can encourage the that wiki
to
file the bug.
Birgitte SB
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
____________________________________________________________________________________Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
I would like to re-iterate as a former admin of a small wiki almost without a community, for small wikis it looks very much reasonable. May be not only the vandal blocking, but also cleaning up some mess like pages created for vandalism which are tagged and need to be deleted. Larger wikis with the community of course will most probably choose to handle it themselves (not opt in).
Cheers, Yaroslav
no or barely a community. Most of the wiki's are small sized, and many
show little activity. It is much easier, and would in practice be almost the same, to just automatically opt in projects...
BR, Lodewijk
2008/2/1, Birgitte SB birgitte_sb@yahoo.com:
The problem with opt-out is that a wiki must know this even *exists* in order to opt-out. So if you are capable of notifing all the village pumps in a language they can comprehend, this is reasonable. If you are not capable of that, opt-out is not reasonable. If this is mainly for wiki's with no community, then allow stewards to "opt-in" such wiki's. If they have no community, they will not object.
Birgitte SB
--- effe iets anders effeietsanders@gmail.com wrote:
Hi,
I agree with your concerns. However, currently a similar system is already active, proxyblocker. This system blocks some (I dont know how many) proxies, detected somewhere in 2005. Dont worry, no new blocks are being added, but some are still in place. The user just gets a message that he is blocked by proxyblocker. We could pick a logical name to appear in the message, that would point to meta. Maybe CrosswikiBlocker, or VandalbotBlocker or something.
Opt-in is not workable. This new thing is mainly for wiki's with no community. You can only opt in if you have a community. Hence, opt in would not work. After all, the stewards mainly have to block bots on wiki's with no or almost no normal edits. when there are people around, and they have sysops and a community, they can handle it themselves generally. However, I would plea for opt-out.
For the unblocking, I do not think that should be a major issue, if we would choose for a maximum of a block in the range of 1 day-1week. In that case, the chance that someone is affected by that block, but is not the person who was doing the malicious edits, is quite slim. Furthermore, that person will survive to wait a day or a week, no big harm done. If it proofs to be a major blocker for a specific community, ie they would only have one IP for a whole country or something, they could opt out.
BR, Eia
2008/1/31, Birgitte SB birgitte_sb@yahoo.com:
--- Andrew Gray shimgray@gmail.com wrote:
On 31/01/2008, Birgitte SB
wrote:
This is the key problem. I think that unless
we
are
capable of notifing all wikis of about the
workings of
this process in a language they are proficient
taking
blocks Wikimedia wide will cause a lot of
harm.
Of
course an opt-in system would be very
workable.
Would logging it in the local block-log system
be an
acceptable method of notification?
I was more thinking first about a notification
that
this ability even *exists* before addressing notification individual blocks. However regarding individual blocks what language are you proposing
the
local log entry be written in?
The only reasonable way to do this is to have the
log
entries be a consistent pre-arranged formula that links to a local page explaining the system in the local language. The best way to ensure that all
this
is set-up is to use an opt-in system that requires these things be set-up before blocks .
Anything else means some wiki(s) will wake up one
day
to realize there are inexplicable blocks in place. Likely with logs entries they cannot read. And
very
likely when they start making inquiries no one
will be
able to explain what has happened to them own
language
leading to further misunderstandings.
Seriously make a system to handle these blocks and require every wiki wishing to join the system file
a
bug and things will go much more smoothly. If the stewards find they are doing tedious manual blocks
on
a certain wiki, they can encourage the that wiki
to
file the bug.
Birgitte SB
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
____________________________________________________________________________________Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
That's assuming that project's users read the village pump. I know I certainly don't read en.wp's village pump, and neither do quite a few other of my fellow editors.
-Dan On Feb 1, 2008, at 9:33 AM, Birgitte SB wrote:
The problem with opt-out is that a wiki must know this even *exists* in order to opt-out. So if you are capable of notifing all the village pumps in a language they can comprehend, this is reasonable. If you are not capable of that, opt-out is not reasonable. If this is mainly for wiki's with no community, then allow stewards to "opt-in" such wiki's. If they have no community, they will not object.
Birgitte SB
--- effe iets anders effeietsanders@gmail.com wrote:
Hi,
I agree with your concerns. However, currently a similar system is already active, proxyblocker. This system blocks some (I dont know how many) proxies, detected somewhere in 2005. Dont worry, no new blocks are being added, but some are still in place. The user just gets a message that he is blocked by proxyblocker. We could pick a logical name to appear in the message, that would point to meta. Maybe CrosswikiBlocker, or VandalbotBlocker or something.
Opt-in is not workable. This new thing is mainly for wiki's with no community. You can only opt in if you have a community. Hence, opt in would not work. After all, the stewards mainly have to block bots on wiki's with no or almost no normal edits. when there are people around, and they have sysops and a community, they can handle it themselves generally. However, I would plea for opt-out.
For the unblocking, I do not think that should be a major issue, if we would choose for a maximum of a block in the range of 1 day-1week. In that case, the chance that someone is affected by that block, but is not the person who was doing the malicious edits, is quite slim. Furthermore, that person will survive to wait a day or a week, no big harm done. If it proofs to be a major blocker for a specific community, ie they would only have one IP for a whole country or something, they could opt out.
BR, Eia
2008/1/31, Birgitte SB birgitte_sb@yahoo.com:
--- Andrew Gray shimgray@gmail.com wrote:
On 31/01/2008, Birgitte SB
wrote:
This is the key problem. I think that unless
we
are
capable of notifing all wikis of about the
workings of
this process in a language they are proficient
taking
blocks Wikimedia wide will cause a lot of
harm.
Of
course an opt-in system would be very
workable.
Would logging it in the local block-log system
be an
acceptable method of notification?
I was more thinking first about a notification
that
this ability even *exists* before addressing notification individual blocks. However regarding individual blocks what language are you proposing
the
local log entry be written in?
The only reasonable way to do this is to have the
log
entries be a consistent pre-arranged formula that links to a local page explaining the system in the local language. The best way to ensure that all
this
is set-up is to use an opt-in system that requires these things be set-up before blocks .
Anything else means some wiki(s) will wake up one
day
to realize there are inexplicable blocks in place. Likely with logs entries they cannot read. And
very
likely when they start making inquiries no one
will be
able to explain what has happened to them own
language
leading to further misunderstandings.
Seriously make a system to handle these blocks and require every wiki wishing to join the system file
a
bug and things will go much more smoothly. If the stewards find they are doing tedious manual blocks
on
a certain wiki, they can encourage the that wiki
to
file the bug.
Birgitte SB
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe:
http://lists.wikimedia.org/mailman/listinfo/foundation-l
Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
Dan Rosenthal wrote:
That's assuming that project's users read the village pump. I know I certainly don't read en.wp's village pump, and neither do quite a few other of my fellow editors.
One important factor which discourages me as much as you from keeping up with en:wp's Village Pump is its sheer mass. The tiny projects do not have that problem.
Ec
On Feb 1, 2008, at 9:33 AM, Birgitte SB wrote:
The problem with opt-out is that a wiki must know this even *exists* in order to opt-out. So if you are capable of notifing all the village pumps in a language they can comprehend, this is reasonable. If you are not capable of that, opt-out is not reasonable. If this is mainly for wiki's with no community, then allow stewards to "opt-in" such wiki's. If they have no community, they will not object.
On 31/01/2008, Birgitte SB birgitte_sb@yahoo.com wrote:
Would logging it in the local block-log system be an acceptable method of notification?
I was more thinking first about a notification that this ability even *exists* before addressing notification individual blocks. However regarding individual blocks what language are you proposing the local log entry be written in?
It's sort of half a solution. The "entry" is pretty much translated for you - it's the message that's the problem.
Let's look at two logs, frwp and dewp, to demonstrate what I mean:
http://fr.wikipedia.org/wiki/Special:Log/block http://de.wikipedia.org/wiki/Special:Log/block
1 février 2008 à 11:47 DocteurCosmos (Discuter | Contributions) a bloqué « 195.78.4.166 (Discuter) » - durée : 1 jour (utilisateurs anonymes seulement, création de compte interdite) (Vandalisme)
11:46, 1. Feb. 2008 Sinn (Diskussion | Beiträge) sperrte „217.228.228.94 (Diskussion)" für einen Zeitraum von: 2 Stunden (nur Anonyme, Erstellung von Benutzerkonten gesperrt) (Unsinnige Bearbeitungen eines anonymen Benutzers von dieser IP-Adresse)
Everything in there, except the comment ("Unsinnige..."), is generated automatically - it's MediaWiki taking internally stored data and displaying it here in French, there in German. So the *log entry* per se is going to be comprehensible ("X was blocked, four days") - it means there will be something there, even if we can't leave a coherent comment.
How to do the comment is, of course, a problem. What do stewards currently do *now* in this sort of situation, where they don't speak the project language but have to step in? English? A guess at what language is most likely to be understood by the local community?
The URL of a specific meta page about sitewide blocks might be a good idea - we can concentrate translations there, and it means that any particular block can run with a single comment without having to adapt for each project. And a URL as a summary is pretty clear for "go here" ;-)
Seriously make a system to handle these blocks and require every wiki wishing to join the system file a bug and things will go much more smoothly. If the stewards find they are doing tedious manual blocks on a certain wiki, they can encourage the that wiki to file the bug.
It really depends what we're looking at this to do - if it's mostly for the benefit of the small wikis without heavily active communities, to protect them against passing vandalbots, it seems to me that opt-out is better than opt-in, simply because of the difficulty of getting every project organised to say "yes, we want this" - a problem which will be most grave for the smallest ones.
On the plus side, though, I think we both agree that some kind of project-by-project ability to not be included would keep people happy :-)
How to do the comment is, of course, a problem. What do stewards currently do *now* in this sort of situation, where they don't speak the project language but have to step in? English? A guess at what language is most likely to be understood by the local community?
They use English.
Cheers, Yaroslav
Eh, I thought than you are proposing some *real* changes ;) (OK, it was just my initial wish, but I realized the meaning a couple of moments after.) Here are my thoughts about that:
- Every block longer or equal to 7 days should be Wikimedia-wide. - The fourth block on two days in, let's say 15 days should be Wikimedia-wide. - The fourth block on one day in 7 days should be Wikimedia-wide. - And so on...
So, here is "better" group of reasons: - If en.wp (or any other approved by WMF) ArbCom decided to block someone on 1 year, I really don't want to see such person on any other project. - If some community decided to block someone on a longer period, it is probably because of very good reason. - If someone got N-th consequent block (usually, any consequent block is higher) on any project, I assume that such person is troll or whatever-destructive.
But, we have the dark side, too: - If some ArbCom fails, it would be much more visible to the whole community. - If some community made some crazy decision only to remove some person from their project, it would be a global issue. - If some admin is not reliable, it would be, again, a matter of the whole community.
Of course, I would be happy with any kind of moving toward this model, which includes WM-wide IP blocks, too. I would really like to see open proxies blocked indefinitely because they are much more harmful to the small projects then to the big ones (yes, Andre, I know that you don't agree with that ;) ).
On 1/31/08, David Gerard dgerard@gmail.com wrote:
On 31/01/2008, Milos Rancic millosh@gmail.com wrote:
I am for that completely. We will need one global admin list, too.
That's why I was thinking of the stewards, though that assumes they want the job!
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
2008/1/31, Milos Rancic millosh@gmail.com:
Eh, I thought than you are proposing some *real* changes ;) (OK, it was just my initial wish, but I realized the meaning a couple of moments after.) Here are my thoughts about that:
- Every block longer or equal to 7 days should be Wikimedia-wide.
- The fourth block on two days in, let's say 15 days should be Wikimedia-wide.
- The fourth block on one day in 7 days should be Wikimedia-wide.
- And so on...
So, here is "better" group of reasons:
- If en.wp (or any other approved by WMF) ArbCom decided to block
someone on 1 year, I really don't want to see such person on any other project.
- If some community decided to block someone on a longer period, it is
probably because of very good reason.
- If someone got N-th consequent block (usually, any consequent block
is higher) on any project, I assume that such person is troll or whatever-destructive.
But, we have the dark side, too:
- If some ArbCom fails, it would be much more visible to the whole community.
- If some community made some crazy decision only to remove some
person from their project, it would be a global issue.
- If some admin is not reliable, it would be, again, a matter of the
whole community.
Of course, I would be happy with any kind of moving toward this model, which includes WM-wide IP blocks, too. I would really like to see open proxies blocked indefinitely because they are much more harmful to the small projects then to the big ones (yes, Andre, I know that you don't agree with that ;) ).
I'm sorry, but I have some big problems with that. I thought for a moment I misread you, but I am afraight not. Communities have different values, different borders, different rules, different behaviour. I beleive we have some very valuable member of the transcom that has been banned for a long time from her home wiki. And I'm confident there are more of these cases. If I am seen as disruptive somewhere, that does not mean the same behaviour occurs at all on other projects, with other people. And even if it would, it does not automatically conclude that this behaviour is also bad on the other community. Personal attacks for instance are very differently interpreted in some communities as in enwiki.
Also the open proxies of course. While in some wiki's open proxies are mainly used for vandalistic activities, in other projects they are being used to avoid easy government control, arrests or the loosing of a job. in some projects these addresses are disruptive, in others they are the backbone of the project. By deciding that for instance nlwiki's open procy policy should become wikimediawide (preventively block all open proxies, including TOR etc) might just very well kill some projects. I am confident this is not your intention. Of course there are ways around it, but this is just an example. My whole point is: who is one community to decide for another community who is allowed to join them. On one side you extremely rely on good faith of the blocking community, but on the other side you forget that also the blocked person might be acting in good faith, but for *some* reason, makes him/herself impossible on a project. Maybe because of language barriers, maybe because of long ongoing disagreements. It can all be in good faith, it can all be a reason to block if that is best for that local community. It is not per se the best for every community.
BR, Lodewijk
I know that you don't agree with that, Lodewijk :)
On 1/31/08, effe iets anders effeietsanders@gmail.com wrote:
I'm sorry, but I have some big problems with that. I thought for a moment I misread you, but I am afraight not. Communities have different values, different borders, different rules, different behaviour. I beleive we have some very valuable member of the transcom that has been banned for a long time from her home wiki. And I'm confident there are more of these cases. If I am seen as disruptive somewhere, that does not mean the same behaviour occurs at all on other projects, with other people. And even if it would, it does not automatically conclude that this behaviour is also bad on the other community. Personal attacks for instance are very differently interpreted in some communities as in enwiki.
- I really don't care about developed Wikimedian communities (and their cultures) which are not able to live with other Wikimedian communities. Bottom line is: If your cultural norms don't allow you to use computer -- don't use it.
- And if some community depends on one or couple of problematic contributors, it is a better idea to wait for some others or even to make some fund raising and find some professional editors.
- Long term ban is not a local, but a global issue. I was very clear about options.
- Personal attacks are personal attacks and, if needed, may be defined globally. Expressing racism is also a very clear field. Of course, someone may interpret that sun shining is a personal attack or a racism, but this is their own problem.
- Yes, I know that a person who did personal and racist attacks on en.wp may be a hero at its own language project. But, then we have a problem with a whole project. And sooner or later we won't be able to ignore it anymore.
- Also, Wikimedia is a culture with its own values and goals. A person who is not able to accept and understand this -- is not able to participate in the project, except as a POV pusher. And if it is a local community-wide behavior, then we are feeding a project which is unacceptable from the point our basic values.
- BTW, I know very well what "different culture norms" mean on the Internet (I live in a "different culture"). Members of really different cultures are not using Internet.
Also the open proxies of course. While in some wiki's open proxies are mainly used for vandalistic activities, in other projects they are being used to avoid easy government control, arrests or the loosing of a job. in some projects these addresses are disruptive, in others they are the backbone of the project. By deciding that for instance nlwiki's open procy policy should become wikimediawide (preventively block all open proxies, including TOR etc) might just very well kill some projects. I am confident this is not your intention. Of course there are ways around it, but this is just an example. My whole point is: who is one community to decide for another community who is allowed to join them. On one side you extremely rely on good faith of the blocking community, but on the other side you forget that also the blocked person might be acting in good faith, but for *some* reason, makes him/herself impossible on a project. Maybe because of language barriers, maybe because of long ongoing disagreements. It can all be in good faith, it can all be a reason to block if that is best for that local community. It is not per se the best for every community.
- http://meta.wikimedia.org/wiki/No_open_proxies
- There are a couple of projects which need open proxies free for editing and it is possible to make exceptions for them. However, ways for helping to valuable editors from such places.
effe iets anders wrote:
2008/1/31, Milos Rancic millosh@gmail.com:
- If en.wp (or any other approved by WMF) ArbCom decided to block
someone on 1 year, I really don't want to see such person on any other project.
- If some community decided to block someone on a longer period, it is
probably because of very good reason.
- If someone got N-th consequent block (usually, any consequent block
is higher) on any project, I assume that such person is troll or whatever-destructive.
But, we have the dark side, too:
- If some ArbCom fails, it would be much more visible to the whole community.
- If some community made some crazy decision only to remove some
person from their project, it would be a global issue.
- If some admin is not reliable, it would be, again, a matter of the
whole community.
Of course, I would be happy with any kind of moving toward this model, which includes WM-wide IP blocks, too. I would really like to see open proxies blocked indefinitely because they are much more harmful to the small projects then to the big ones (yes, Andre, I know that you don't agree with that ;) ).
I'm sorry, but I have some big problems with that. I thought for a moment I misread you, but I am afraight not. Communities have different values, different borders, different rules, different behaviour. I beleive we have some very valuable member of the transcom that has been banned for a long time from her home wiki. And I'm confident there are more of these cases. If I am seen as disruptive somewhere, that does not mean the same behaviour occurs at all on other projects, with other people. And even if it would, it does not automatically conclude that this behaviour is also bad on the other community. Personal attacks for instance are very differently interpreted in some communities as in enwiki.
I too think that Milos' proposal goes too far. No single project should have the power to insist on a site-wide block. Some refugees from the cauldron of the en:wp can do quite well when they emigrate to a project that is willing to listen to and respect their views. This does not mean that their proposals are adopted, only that they are listened to. The regulars on a small project look dimly on attempts to import en:wp practices without independent discussion.
A logical extension of Milos' proposal could arise if someone persistently insisted on pushing a Serbian POV on hr:wp. The Croatians would become very annoyed with this until that individual met one of the criteria which Milos suggests. They would block him, and the logical consequence would then be that he should also be blocked on sr:wp. Somehow, I don't see that this would necessarily be an acceptable result.
Ec
- Every block longer or equal to 7 days should be Wikimedia-wide.
- The fourth block on two days in, let's say 15 days should be
Wikimedia-wide.
- The fourth block on one day in 7 days should be Wikimedia-wide.
- And so on...
So, here is "better" group of reasons:
- If en.wp (or any other approved by WMF) ArbCom decided to block
someone on 1 year, I really don't want to see such person on any other project.
Do you still remember recent Russian Wikibooks story, when some users were permablocked by the only admin for no apparent reason? Under your policy, they would also be permablocked on all other projects.
Cheers Yaroslav
On 1/31/08, Yaroslav M. Blanter putevod@mccme.ru wrote:
Do you still remember recent Russian Wikibooks story, when some users were permablocked by the only admin for no apparent reason? Under your policy, they would also be permablocked on all other projects.
Duration of such blocks would be something like ten minutes, which would be the last minutes of that contributor's adminship.
ok, I think it is really not a good thing to discuss this right now right here. It is just confusing the discussion about the global block that will probably have support. I doubt your proposal comes even close to any form of support :) And that besides the fact that it would require a total redesign of the whole community idea of Wikimedia, so it's not posisble for the near future anyway. Let's focus on what's realistic, and not discuss unrealistic proposals for now. Of course, if you wish, start a seperate discussion about the restructuring of Wikimedia somewhere else.
BR, Lodewijk
2008/1/31, Milos Rancic millosh@gmail.com:
On 1/31/08, Yaroslav M. Blanter putevod@mccme.ru wrote:
Do you still remember recent Russian Wikibooks story, when some users were permablocked by the only admin for no apparent reason? Under your policy, they would also be permablocked on all other projects.
Duration of such blocks would be something like ten minutes, which would be the last minutes of that contributor's adminship.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 31/01/2008, Milos Rancic millosh@gmail.com wrote:
So, here is "better" group of reasons:
- If en.wp (or any other approved by WMF) ArbCom decided to block
someone on 1 year, I really don't want to see such person on any other project.
You do realise the head of the translator committee is banned from ja:wp due to personal disagreements? Communities have attacks of batshit insane, and that's too much power to hand to one project.
- d.
"Milos Rancic" millosh@gmail.com writes:
Eh, I thought than you are proposing some *real* changes ;) (OK, it was just my initial wish, but I realized the meaning a couple of moments after.) Here are my thoughts about that:
Given the enwiki habit (or should I say arrogance?) of blocking people with usernames containing non-ascii characters, I sincerly hope that you are just speaking your mind without thinking...
Otherwise, your ideas would pretty soon lead to wikipedia being an english-only affair, with the various languages splitting of projects of their own. Is that what you want?
As for the whole idea about global blocks in itself. Forget it. It'll just lead to further alienation of projects that are not enwiki.
That has been on bugzila for over a year now (perhaps two). It is easier said then done I think.
On Jan 31, 2008 12:34 PM, David Gerard dgerard@gmail.com wrote:
On 31/01/2008, Milos Rancic millosh@gmail.com wrote:
I am for that completely. We will need one global admin list, too.
That's why I was thinking of the stewards, though that assumes they want the job!
- d.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 31/01/2008, David Gerard dgerard@gmail.com wrote:
Presumably such a global block would only be available to stewards, on due consideration.
Before anyone starts coding - what are the devs' thoughts on a global blocking mechanism? What could go badly wrong?
My immediate note of caution is rangeblocks. Do we have any figures at all on how often rangeblocks prove overzealous? This does have the faint air of a catastrophe waiting to happen...
Other useful options:
i) an individual blanket opt-out for specific projects (I am not sure how many would take it up, but it seems the sort of thing that people like to know is there)
ii) Some way of telling the blocked user that they've been blocked on a sitewide level, please contact so-and-so about this, rather than the normal project block message. (Linguistic issues here)
Otherwise, it's mostly a matter of social safeguards - don't overuse it, don't block indefinitely, etc, and stewards are fairly well selected for sanity ;-)
On 31/01/2008, Andrew Gray shimgray@gmail.com wrote:
On 31/01/2008, David Gerard dgerard@gmail.com wrote:
Presumably such a global block would only be available to stewards, on due consideration.
Before anyone starts coding - what are the devs' thoughts on a global blocking mechanism? What could go badly wrong?
My immediate note of caution is rangeblocks. Do we have any figures at all on how often rangeblocks prove overzealous? This does have the faint air of a catastrophe waiting to happen...
Other useful options:
i) an individual blanket opt-out for specific projects (I am not sure how many would take it up, but it seems the sort of thing that people like to know is there)
ii) Some way of telling the blocked user that they've been blocked on a sitewide level, please contact so-and-so about this, rather than the normal project block message. (Linguistic issues here)
Oh, another one:
iii) some way of a local project *knowing* that a block has been issued - so presumably this would have to tie into all the local block logs.
"David Gerard" dgerard@gmail.com writes:
I've just sent this to wikitech-l, but what I'm proposing is a *big* hammer, so needs lots of due consideration. Please pick holes in the idea.
* Any kind of centralization, will be perceived as unwanted influence on all or most of the projects that are not enwiki.
* Really interesting intrawiki wheel wars.
* Conflicting policies between wikis.
In short, a very bad idea.
I'm afraid there seems to be an assumption that people with Checkuser are looking to apply their cultural norms to other wikis. This isn't the case, and I suspect most of the other CheckUser people would oppose expanding this idea of global blocking in that way.
It has now been nearly two weeks since I blocked an IP address on en.wikinews for a year. Checkuser revealed a long history of Willy on Wheels type usernames, all responsible for vandalism. When the same IP cropped up on several wikis it seemed logical to do a cross-wiki block. To do the whole nine yards is a mammoth task, and the people who have to do this are asking for a tool to make it easier.
Yes, there is a concern that making this easy will make it occur more frequently, but that is - I think - a risk worth taking.
Brian McNeil
-----Original Message----- From: foundation-l-bounces@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of Anders Wegge Jakobsen Sent: 31 January 2008 21:33 To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] Fwd: Wikimedia-wide global blocking mechanism?
"David Gerard" dgerard@gmail.com writes:
I've just sent this to wikitech-l, but what I'm proposing is a *big* hammer, so needs lots of due consideration. Please pick holes in the idea.
* Any kind of centralization, will be perceived as unwanted influence on all or most of the projects that are not enwiki.
* Really interesting intrawiki wheel wars.
* Conflicting policies between wikis.
In short, a very bad idea.
"Brian McNeil" brian.mcneil@wikinewsie.org writes:
I'm afraid there seems to be an assumption that people with Checkuser are looking to apply their cultural norms to other wikis. This isn't the case, and I suspect most of the other CheckUser people would oppose expanding this idea of global blocking in that way.
No, I'm not after checkusers in particular. I'm warning about the consequences of a well-meaning proposal. Especially, when I see what bystanders gets out of it. Actually, I'm on the checkuser-l myself, so I've seen the talk there.
It has now been nearly two weeks since I blocked an IP address on en.wikinews for a year. Checkuser revealed a long history of Willy on Wheels type usernames, all responsible for vandalism. When the same IP cropped up on several wikis it seemed logical to do a cross-wiki block. To do the whole nine yards is a mammoth task, and the people who have to do this are asking for a tool to make it easier.
Yes, they ask for that. But I see no reason giving this kind of power to checkuser, let alone random admins on foo.wikipedia.org. And unfortunately, that was where the debate were headed, when I had time to read this thread. Coming from one of those "pesky and irritating" (to paraphrase the general tone in this thread, and not yours) little wikis, I can tell you that any kind of centralization is a bad move. Already we are forced to live with people assuming that whatever policy enwiki invented this week is project-wide. Being forced to live with yet another layer of "We do know better than you, after all", will just increase tension, and achieve little less. I don't know where dawiki ranks, and frankly, I don't really care. I happen to be one of about 15 active administrators, who are well capable of taking care of our own project. We *DO* *NOT* need any kind of outside "help", "advice" or whatnot. What we do need on the other hand, is a hint, now and then, that someone actually consider us mature enough that we are able to cope with our own problems.
And this lead me to the core issue:
There are too many small wikis, with a very limited community backing them. They are endangered by project-wide vandalism. But that danger is a political creature, so please don't try to combat that with technical means that are far more disruptive in the long term.
Yes, there is a concern that making this easy will make it occur more frequently, but that is - I think - a risk worth taking.
Plain and simple no. If it's worth doing, it's something that will be done, even if it's hard to do. If it's not that much of an issue, there will be blocks only where needed.
Nobody is suggesting anyone be given the ability to perform a task they can't already. What is being suggested is a tool or feature to make carrying out this task easy.
I think the key point I made in my earlier mail was that this IP for WoW was blocked on en.wn about two weeks ago. We're still getting hits from it on other wikis. That's two weeks of cross-lang/cross-project disruption that could have been nipped in the bud. There was consensus at the time of my posting to Checkuser-l that the IP had been enough of a nuisance on multiple wikis to merit the cross-project/language block. Problem is, it took *weeks* for it to be implemented. This is what I want to see dealt with.
I've already posted on Checkuser-l that we need some ground rules for when this can be applied - and I've taken it for granted that it would be applied to an IP address, not a username. A disruptive username should be blocked on a per-wiki basis and grounds for elevating that to a block of the underlying IP should perhaps include the creation of multiple disruptive accounts.
I must stress, this is not asking for an unavailable power. It is seeking a tool to automate the process. Personally I would be opposed to this being used for short-term blocks, it is for habitual offenders who have a permanent or semi-permanent IP. I'd welcome a discussion to set up ground rules for use of such a tool or feature, but I would definitely argue the case it is needed.
Brian McNeil
-----Original Message----- From: foundation-l-bounces@lists.wikimedia.org [mailto:foundation-l-bounces@lists.wikimedia.org] On Behalf Of Anders Wegge Jakobsen Sent: 31 January 2008 22:21 To: Wikimedia Foundation Mailing List Subject: Re: [Foundation-l] Fwd: Wikimedia-wide global blocking mechanism?
"Brian McNeil" brian.mcneil@wikinewsie.org writes:
I'm afraid there seems to be an assumption that people with Checkuser are looking to apply their cultural norms to other wikis. This isn't the case, and I suspect most of the other CheckUser people would oppose expanding this idea of global blocking in that way.
No, I'm not after checkusers in particular. I'm warning about the consequences of a well-meaning proposal. Especially, when I see what bystanders gets out of it. Actually, I'm on the checkuser-l myself, so I've seen the talk there.
It has now been nearly two weeks since I blocked an IP address on en.wikinews for a year. Checkuser revealed a long history of Willy on Wheels type usernames, all responsible for vandalism. When the same IP cropped up on several wikis it seemed logical to do a cross-wiki block. To do the whole nine yards is a mammoth task, and the people who have to do this are asking for a tool to make it easier.
Yes, they ask for that. But I see no reason giving this kind of power to checkuser, let alone random admins on foo.wikipedia.org. And unfortunately, that was where the debate were headed, when I had time to read this thread. Coming from one of those "pesky and irritating" (to paraphrase the general tone in this thread, and not yours) little wikis, I can tell you that any kind of centralization is a bad move. Already we are forced to live with people assuming that whatever policy enwiki invented this week is project-wide. Being forced to live with yet another layer of "We do know better than you, after all", will just increase tension, and achieve little less. I don't know where dawiki ranks, and frankly, I don't really care. I happen to be one of about 15 active administrators, who are well capable of taking care of our own project. We *DO* *NOT* need any kind of outside "help", "advice" or whatnot. What we do need on the other hand, is a hint, now and then, that someone actually consider us mature enough that we are able to cope with our own problems.
And this lead me to the core issue:
There are too many small wikis, with a very limited community backing them. They are endangered by project-wide vandalism. But that danger is a political creature, so please don't try to combat that with technical means that are far more disruptive in the long term.
Yes, there is a concern that making this easy will make it occur more frequently, but that is - I think - a risk worth taking.
Plain and simple no. If it's worth doing, it's something that will be done, even if it's hard to do. If it's not that much of an issue, there will be blocks only where needed.
wikimedia-l@lists.wikimedia.org