Page MenuHomePhabricator

Bureaucrats on WMF wikis to add/remove 'accountcreator' by default
Closed, ResolvedPublic

Description

We're having plently of requests to have this grant enabled on local wikis with the configuration mentioned in the task title. In fact most of the local rules in InitialiseSettings.php are configured as such.

I think we should just allow bureaucrats at WMF wikis to handle this as we recently did with 'confirmed' (T101983) and 'translationadmin' (T178793).

Bureaucrats only exist on large wikis so we can trust there'll be community supervision on the granting and removing of this grant. In case there's no local bureaucrat, stewards can be called to fullfil that role and assign/remove said permission with equal guarantees of supervision.

Local customizations will be possible as in the previous two cases in the event a wiki decides that administrators (for example) be allowed to add/remove this.

I don't think this is a controversial change but I'm announcing this notwithstanding on the Wikimedia Forum.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

I've long been baffled by the high amount of bureaucracy and overhead regarding account creation. We have people who do basically nothing else except create accounts via custom interfaces. Why is this? Does it make any sense to continue to support and enable this practice? For nearly all users, they should be able to create/register an account themselves. Why is a separate group, across hundreds of wikis, needed? Why is separate tooling needed? It doesn't make any sense to me.

@MZMcBride I'm talking about the user right, not about restricting who/when/how to create accounts. That has nothing to do with this ticket. The account creator permission is now (since a year or more) avalaible at all Wikimedia wikis (got added to MW core I think) and they just let the holders to skip whichever account creation limits the wiki has in place (we restrict 6 accounts per IP and day). In fact this will alleviate bureaucracy when, ie, workshops are being run, letting people create accounts for the attendants if they have not requested a IP cap lifting here. Thanks.

This is a "lower" security type flag, if itis part of core it should have a way to use it - so sure let 'crat have it. I'd be fine with local sysop's having it too (as this is a power they already have themselves).

@MZMcBride I'm talking about the user right, not about restricting who/when/how to create accounts. That has nothing to do with this ticket.

"Nothing" is a bit strong. I can understand why you might want to consider this request in isolation, but it really is part of a larger effort to institutionalize the role of "account creator" to work around self-imposed limits.

In fact this will alleviate bureaucracy when, ie, workshops are being run, letting people create accounts for the attendants if they have not requested a IP cap lifting here.

This is misguided, in my opinion. At workshops or anywhere, people should be able to create accounts for themselves. You're talking about having one set of users (bureaucrats) grant another set of users (account creators) the ability to create accounts for a third set of users (people who just want to register an account at a workshop or conference). In my opinion, this model and architecture are suboptimal and we should be wary of efforts to continue to expand and solidify them.

@MZMcBride I can understand your possition as well and nothing in this request is to impose burdens or more bureaucracy to the account creation process which will continue to be self-serviced in most of the cases. But the fact is that there's a limit on how many accounts can be created from an IP.

The solution for now is to either request an IP cap lift here in Phabricator for the specific IP/Range and let the users create the accounts themselves for a period of time (suggested approach), or have administrators/account creators to create the accounts for them because they forgot to request that here/don't know.

As I said, the [[m:Mass account creation]] path is always the prefered one as it lets the attendants create the accounts for themselves. I wish one day we could do the same thing on-wiki without the need of tickets, SWATs, etc. I think there's a ThrottleOverride extension in beta status.

In any case I'd just like to discuss if 'accountcreator' is safe to be bureaucrat-default, because there's an increasing number of requests here to let local users handle this permission and it's just annoying to patch over and over the config. I feel that discussing the process of account creations and its limits or how people runs workshops or conpherences is out of scope for this task.

Thank you.

Change 406025 had a related patch set uploaded (by MarcoAurelio; owner: MarcoAurelio):
[operations/mediawiki-config@master] Bureaucrats on WMF wikis to add and remove 'accountcreator' by default

https://gerrit.wikimedia.org/r/406025

Change 406025 merged by Niharika29:
[operations/mediawiki-config@master] Bureaucrats on WMF wikis to add and remove 'accountcreator' by default

https://gerrit.wikimedia.org/r/406025

Stashbot added a subscriber: Stashbot.

Mentioned in SAL (#wikimedia-operations) [2018-01-29T19:22:02Z] <niharika29@tin> Synchronized wmf-config/InitialiseSettings.php: Adding config for WikimediaEvents module for logging behavior data T183869 and beaureaucrats to add and remove accountcreator by default T185417 (duration: 00m 56s)

Change 408071 had a related patch set uploaded (by Framawiki; owner: Framawiki):
[operations/mediawiki-config@master] Remove old 'accountcreator' rules now handled by default

https://gerrit.wikimedia.org/r/408071

Change 408071 merged by jenkins-bot:
[operations/mediawiki-config@master] Remove old 'accountcreator' rules now handled by default

https://gerrit.wikimedia.org/r/408071

Mentioned in SAL (#wikimedia-operations) [2018-02-07T18:55:52Z] <thcipriani@tin> Synchronized wmf-config/InitialiseSettings.php: SWAT: [[gerrit:408071|Remove old "accountcreator" rules now handled by default]] T185417 T186462 (duration: 01m 12s)