I'm skeptical about solution #1 (we lack candidates rather than roles) and #3 (without actual data is not possible to find the best solution, yesterday alone I think I wrote 30 times through VRTS "hey, you forgot to turn this VPN off"). Instead, I wholeheartedly endorse improving blocking messages. I've tried to write down a stub of wizard at https://meta.wikimedia.org/w/index.php?title=User:Vituzzu/wizard but I lack the time to do it). Also I'm quite skeptical about the technical support, for the issue. This proposal https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Admins_and_patrollers/Allow_global_whitelisting_of_IPs_subject_to_global_rangeblocks has been around since 2014, lack of global block for accounts is already a meme.
In short, stewards and global patrollers are left alone fighting against machines (it took ages to improve the NTSAMR spammers situation) and deeply dedicated trolls (Rgalo and his T-MO block is immensely expensive in terms of resources) almost by hand. Vito Il giorno ven 22 apr 2022 alle ore 14:43 Florence Devouard < [email protected]> ha scritto: > 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 and > https://meta.wikimedia.org/wiki/Wikimedia-l > Public archives at > https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/RQYWVQXJJ3EOSEXXDTZQQRFEOSESROA7/ > To unsubscribe send an email to [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 and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/[email protected]/message/VLNOIDL4YTYBJM5B4NZ3MO5BFVL5O5KM/ To unsubscribe send an email to [email protected]
