This extension or the other way (T91928 including) there definitely should be a way for a sysop/user with the same rights to temporarily lift account creation throttle for the IP he is connected from right there right at the moment.

The current ways are just insane:

• in order to ask system administrators you have to
  1. know the venue's IP beforehand which is very often not the case untill the event or the day before
  2. have your event not around any major wikimedia conference or US holiday in time, as otherwise system administrators are virtually unreachable
• account creation is the way, but it is worse psychologically or whatever wise: you want people to remember that they attended the event and did everything there themselves, since registration and every single edit from then on, while "Oh Wikipedia, now that you mention it I attended their event in the past and some guy even created an account for me, I wonder what it was called" is definitely what you want not

The ways which somewhat work are:

• Having people register beforehand (but sometimes you don't have a way to reach them or that is too difficult for them)
• Using random Central Auth wikis for different people, but for some the concept of going to another wiki is another piece of information they have to stack on the huge heap they are already expected to learn, besides just few wikis use the same language which is a problem for monolingual people.

But none is good enough to be satisfying.

T91928 actually provides better explanation I believe, but this task seems to be a core one now.

Efforts to develop a solution

@H-stt Thanks for your interest for this, yes, yes and yes, a tool to address this issue is most than very welcome. and wanted for some years.

You basically have two options:

1. write your own extension from scratch, in a very secure way, as it's a potential open door for spambots
2. start from the ThrottleOverride extension, review and improve it

An estimate would be 4 hours to analyze the requirements and see what we need to leverage as configuration, I can help for this part by the way + 10 hours to write unit tests and design a prototype, 20 hours to refactor, debug and document the code, 4 hours to prepare a demo environment. It will then be blocked by a security review for probably 3 to 8 weeks. Afterwards, you can estimate 4 hours to fix security issues and 2 hours to polish before a deployment request on beta.

So I'd say 38 hours + 6 extra hours after the security review.

If you come at the Wien hackathon, and you take a from scratch approach, I'm willing to help. If you take a "improve ThrottleOverride" approach, @Reedy is attending the hackathon too.

Prioritization :: this is a nice to have, not a must have

This reply was redacted December 21 to reply to @Base, but not posted, as not useful in a context there was some traction for some extension love. It's now again pertinent per T152877 closure.

First, the availability of an on wiki solution is welcome. Even if that will still require to know the IP.

But this solution should satisfy criteria of security, maintainability like any other extension.

Meanwhile, your assessment seems to describe a situation anterior to 2012.

Site requests currently receive a real time planification and support from caring volunteers.
Currently, the throttle requests are mainly handled by @Urbanecm in the next hours after task creation, and deployed timely when needed.

Deployment could occur at ordinary and extraordinary times: ordinary time is Monday to Thursday 3 time per day, ie there is each week 12 opportunities to add the rule to the config.

Volunteers and Wikimedia Foundation staff know how to handle these request at extraordinary times when needed in emergency.

And this issue will exist on wikis too: how to find one of the few individuals with the rights in emergency? Yet, if we can address this on wiki and on config, that at least give two opportunities where to find someone available.

Hi! I'm planning on showcasing this project for the hackathon and guessing @Dereckson & @Reedy; you might be available to help answer any questions?

I've just checked the participants list, it seems @H-stt isn't at the hackathon.

Its unclear to me what the status of this extension is. Is this waiting on security review? If not, please remove the Application Security Reviews tag.

Removed Application Security Reviews. That will be needed, but things are not ready yet. A specific review ticket should be opened when it is close to being ready for review.

Should we have T174895: Convert ThrottleOverride to use a wiki page for storage as a blocker for the deployment? I image a migration afterwards will be much harder (and create meaningless effort for different parties, such as DBAs creating and dropping those tables) than sorting that one out beforehand. It'd also solve T147367: Special page actions should have API equivalents, which should probably be a blocker here anyways.

In T27000#2893598, @Base wrote:

...
The ways which somewhat work are:
...

• Using random Central Auth wikis for different people, but for some the concept of going to another wiki is another piece of information they have to stack on the huge heap they are already expected to learn, besides just few wikis use the same language which is a problem for monolingual people.

...

That is not supposed to work after T43284: Make $wgAccountCreationThrottle effective on SUL was fixed.

Does this work in Wiki Farms? IE: if I want to run a workshop and want to add a rule for, say, enwiki, wikidata and commons, would we be able to do it all at once or do we need to visit the three projects to set the same rule. If the later, can we have this solved so it can work well for WMF wikis? Thanks.

In T27000#3917052, @MarcoAurelio wrote:

Does this work in Wiki Farms?

Yes, it does since T147364 and the attached patch there (although I've not tested it myself yet). There's a configuration variable which can (for WMF: will) be set to designate a single wiki in a farm (for WMF: meta) to be the one that manages all the overrides.

In T27000#3917430, @EddieGP wrote:

In T27000#3917052, @MarcoAurelio wrote:

Does this work in Wiki Farms?

Yes, it does since T147364 and the attached patch there (although I've not tested it myself yet). There's a configuration variable which can (for WMF: will) be set to designate a single wiki in a farm (for WMF: meta) to be the one that manages all the overrides.

Awesome then. I'd love to see this being deployed. The current process is a bit tedious t.b.h. for most users. Regards.

New process: https://www.mediawiki.org/wiki/Review_queue

In T27000#3996268, @MarcoAurelio wrote:

New process: https://www.mediawiki.org/wiki/Review_queue

How is that new? That page's been around for a while?

I mean, it's been updated since this task was created. Please verify the current requirements. This task is 7 years old.

I think the next step would be to set it up on Cloud VPS and ask for feedback. If done via Vagrant it should be easy to set it up for a wikifarm.

Removing Possible-Tech-Projects as we are planning on killing this tag soon!

In case anyone was looking for anything on this, note that accounts created via outreachdashboard.wmflabs.org have effectively been made throttle exempt