Hello
Ok, so viewing the IP is necessary. I added the barebone proposition on
the meta page for futher refining.
https://meta.wikimedia.org/wiki/Talk:No_open_proxies/Unfair_blocking#On-wiki_feature
If anyone can edit the description to make it clearer, it would be great
Since you indicated seeing the IP is necessary, I have been wondering on
steward pool
1) how do you truely evaluate/know of each steward activity or lack
there of (steward activity). Probably easy to see the fully inactive
ones (might not be wiki active anymore), or the super active ones. But
for all those in-between.... how do you know the level of activity of
the 40 or so ? I have looked at the past situation and see there are
only 1-2 people removed for inactivity for most of the past few years.
It seems a bit surprising to me.
2) Number of stewards has been more or less stable since 2009... the
highest seem to have been 36. The lowest was 29 stewards in 2011. I am
not sure how much the job has evolved since inception given the many
roles added over time. But has the job been easier or more complicated
since 2009 ? Is the current number of steward sufficient ?
3) I see the number of candidates has been fairly limited over the year.
With a third to half of candidates rejected. 7 candidates in 2018 (2
no), 14 candidates in 2019 (7 no), 10 candidates in 2021 (5 no), 7
candidates in 2022 (2 no). Is this figure considered satisfactory to
you, or would you be hoping for more good candidates ? Has the
recruitement process been rather passive (simply posting an announcement
to call for new candidates) or rather active (actively approaching
potential candidates).
Flo
Le 22/04/2022 à 15:20, Rae Adimer via Wikimedia-l a écrit :
Hi Flo.
Viewing the IP address involved is necessary. There's a reason why
Stewards and CheckUsers are generally the ones involved in handling
IPBE requests. There's differences between people trying to use open
proxies to edit through the Great Firewall of China, people caught in
IPv4 blocks from CGNAT-using ISPs, people whose residential ranges are
blocked as p2p proxies, and people who just want to edit with a proxy.
Often there are rangeblocks with specific circumstances behind it,
such as usage by LTAs or being a specific type of proxy. Knowing this
background is necessary.
It would be incredibly helpful if there was a way to send in IPBE
requests on-wiki and for Stewards to be able to respond to it on-wiki,
confidentially. Where those affected can input the affected IP address
and reason, and Stewards can answer the queue there quickly and
easily. We can handle the quantity of requests if the process is workable.
I'm also wondering who the people discussed with privately are. Your
suggestion here is one of the most feasible I've seen, and as far as I
can tell there are very few people asking Stewards directly for input
on this. I've seen a lot of comments which are misinformed about what
is happening, why, and what is a feasible fix.
My message on the Meta-Wiki page outlines my views on this. Optimally,
the WMF would discuss with Stewards ways to create a better system for
this, and implement it. New problems, old tech.
Best regards,
Rae
~~~~~~~~~~~~~~~~
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>)
On Fri, Apr 22, 2022 at 8:43 AM Florence Devouard
<[email protected]> wrote:
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
<[email protected]> 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 -- [email protected],
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/[email protected]/message/CDBOEBW2ZRYHWYBHAYEPOIWZ6YC2WLIK/
To unsubscribe send an email to
[email protected]
--
~~~~~~~~~~~~~~~~
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 [email protected], guidelines
at:https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
andhttps://meta.wikimedia.org/wiki/Wikimedia-l
Public archives
athttps://lists.wikimedia.org/hyperkitty/list/[email protected]/message/RQYWVQXJJ3EOSEXXDTZQQRFEOSESROA7/
To unsubscribe send an email [email protected]
_______________________________________________
Wikimedia-l mailing list -- [email protected],
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/[email protected]/message/N6OKHEJ6OJNKB6ULB6ELASY23D7GFF55/
To unsubscribe send an email to [email protected]
_______________________________________________
Wikimedia-l mailing list [email protected], guidelines
at:https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
andhttps://meta.wikimedia.org/wiki/Wikimedia-l
Public archives
athttps://lists.wikimedia.org/hyperkitty/list/[email protected]/message/B7R5MIAHIDQRE2H54YMKTJHDG5MR4FZE/
To unsubscribe send an email [email protected]
_______________________________________________
Wikimedia-l mailing list -- [email protected], 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/[email protected]/message/LJLI74BTAENTUKF5OM4QJEUI46BRTSHJ/
To unsubscribe send an email to [email protected]
