Gabriele, indicated we shouldn't use the current methodology unless they have 
very good alternatives - but the same applies to stopping it. 

We don't have the capacity to handle a big bulk increase in pending changes as 
proposed by gbfv  on en-wiki and presumably others as well - and making very 
short-length blocks on proxies would require a major increase in Steward time, 
which a quick review of the average  myriad steward backlogs indicates is not 
really a resource in sufficient supply to be profligate with. 

Others have proposed using a professional group of employees to either replace 
or outweigh the CU corps. I seriously doubt many projects are going to be happy 
with vastly increasing the amount of blocks implemented by the foundation on 
the basis of evidence that very few can see. 

Vermont has correctly summarised the issues that come with any 
auto-implementation of IPBE. 

But there clearly is a need to act on the growing set of problems, and DannyH's 
list has many good options (and even the not so good options are the ones that 
obviously should be considered to judge the tradeoff threshold). 

If we can smooth the process for Stewards (on their side) to shrink the time 
needed for each action, that's the same effect as having more active stewards. 
That let's us consider options that currently may be a non-starter. We also 
need to smooth the process for requesting unblocks (or even understanding the 
problem). No doubt this is excabated by the "they can't hear you" 
<> problems.  

We absolutely need a process for simplifying and clarifying both understanding 
IPBE (global/local) and then requesting it. 

Now, I suspect most "innocent" proxies being added/blocked would probably 
become "harmful" if unblocked (that is, sooner or later they'd be used 
problematically), but that's definitely something that should be tested as we 
expand on blocking proxies just because we know they're proxies.
Wikimedia-l mailing list --, guidelines at: and
Public archives at
To unsubscribe send an email to

Reply via email to