All of these suggestions sound good.
Reducing the current intimidating wall of text should be very high on the
priority list.
Another thing I'd suggest experimenting with is reducing the use of
preemptive IP blocks, simply because an IP was identified as a potentially
problematic proxy, and blocking them only if they actually vandalize.
בתאריך יום ו׳, 22 באפר׳ 2022, 15:44, מאת Florence Devouard <
fdevouard(a)gmail.com>gt;:
I have read all the comments and discussed privately
with a few people.
There are some elements of answers that are purely in the hands of
stewards, they have to discuss and find common grounds, in particular to
implementing blocks, so that they limit damage on good people, whilst
preserving the projects from vandals.
However, the general observation is that the current system to report an
unfair block to stewards and get unblocked by them is largely broken.
1) process is not simple to understand by the user
2) complicated to implement on the steward side (requires back and forth
discussion, checking legitimacy of request, copy pasting information etc.)
3) the steward pool of volunteers is limited, whilst the stewards willing
to do that job is even smaller (I heard the VRT queue is overflowing)
4) the process reveals IP private info
All this creates a bottleneck.
There is one path we could explore, a feature to simplify the process of
"adding legitimate users" to the Global IPblock exemptions list, in a
process inspired from the Global renamers one.
* new functionary role (eg Global IPblock exempters) : populated by
stewards, or people appointed by steward
* interface directly on wiki (bypass of VRT, bypass of copy pasting
between tools)
* a process which would NOT require revealing the IP address to the
functionary (it is sufficient that the system recognise the person is
blocked in relationship with an Open Proxy/TOR stuff)
* a process which could provide info to the functionary to very quickly
assess whether the person is a legitimate editor or not (every person
fighting vandalism know how to do that... display last contribs... block
log... number of edits... etc. or simply direct links to those info to
simplify the functionary job)
* a process allowing various "unblocking" options, day, weeks, indef
listing, pretty much as the blocking feature permit, so as to grant indef
listing to the super trustworthy individuals, and a time limited listing to
those more questionnable
* add a checkbox system where requesters can give pre-loaded reasons for
their asking (edit-a-thons etc.), which will help make the system
multilingual and language neutral for the functionary (in most cases, no
need to discuss with the user)
* add any feature necessary to limit the risk of vandals abusing the
feature (forced loging before submitting the request, capcha stuff)
In short, simply make the "add to the Global IP block exemption list"
process fluid with removal of the current bottle neck (stewards), which in
turn will be able to focus on more important security issues.
Is there any reasons why this would technically and socially not work ?
Flo
Le 22/04/2022 à 13:25, Rae Adimer via Wikimedia-l a écrit :
Hi all,
About unblocking IPs that geolocate to Africa, it’s not as though the
blocked IPs are random. The problem with these affected ISPs are that they
have many users on the same IP address. They aren’t traditional proxies
(and traditional proxies will not be unblocked, that isn’t the issue here),
they’re just poorly managed ISPs. I’m not even sure if there would be more
vandalism from unblocking these ISPs, and I think it should be done.
“Smart blocking” would be a bad idea. It would take *a lot* of work to
implement and would be a net harm to our ability to deal with abuse. I am
strongly opposed to creating this. Also remember to a large extent the
issue with these IPs isn’t a range, it’s that there’s multiple users on the
*same* IP.
Regarding IPBE, the issue isn’t that we’re declining requests, it’s that
we don’t get to them in a timely manner. There are a lot of requests.
I’ve tried to clear up a number of other misconceptions in a comment on
the Meta-Wiki page as well.
Best regards,
Rae
On Fri, Apr 22, 2022 at 07:03 WereSpielChequers <
werespielchequers(a)gmail.com> wrote:
Yesterday I was on a conference call that
included several Nigerian
Wikipedians, I was surprised at how much of their problems editing
Wikipedia were over blocks.
The English language Wikipedia doesn't have an overall problem with
editing numbers, nearly eight years on, editing volumes are still clearly
above the 2014 minima. But we do have huge geographic skews and in
particular we badly underrepresent the English speaking parts of Africa in
our community and in our Projects. I don't know if other languages have
similar issues, but it would not surprise me.
I get that lowering our guard overall against IP vandals would increase
the workload of those who'd rather be improving Wikipedia than clearing up
after vandals. But there are a couple of things that could fairly easily
be done if we want a more global community.
Firstly, unblock IPs that geolocate to countries where we lack
contributors.Yes we will get more vandalism in those countries, but far far
less than if we also unblocked all IPs in countries where we have lots of
editors.
Secondly, implement "smart blocking", especially with range bocks. Yes
there will still be lots of collateral damage where someone in the same
range has the same sort of device/, O/S etc as the person who did the edit
that prompted the block. But anyone in the same range who uses a different
type of hardware operating system etc would not be caught by a smart block.
Thirdly, especially if we can't do the first two, be more liberal with IP
block exemption for accounts in countries where we lack editors and have
problems with a limited number of often blocked IPs.
WSC
_______________________________________________
Wikimedia-l mailing list --
wikimedia-l(a)lists.wikimedia.org, guidelines
at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
--
~~~~~~~~~~~~~~~~
User:Vermont <https://meta.wikimedia.org/wiki/User:Vermont> on Wikimedia
projects
they/them/theirs (why pronouns matter
<https://www.mypronouns.org/what-and-why>)
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)lists.wikimedia.org, guidelines
at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and
https://meta.wikimedia.org/wiki/Wikimedia-l
Public archives at
https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org…
To unsubscribe send an email to wikimedia-l-leave(a)lists.wikimedia.org