Page MenuHomePhabricator

The Event Organiser's Userright
Open, NormalPublic

Tokens
"Like" token, awarded by Liuxinyu970226."Love" token, awarded by Santamarcanda."Love" token, awarded by Ivanhercaz."Like" token, awarded by Daniel_Mietchen."Love" token, awarded by Base."Like" token, awarded by Romaine."Like" token, awarded by czar.
Assigned To
Authored By
WereSpielChequers, Mar 8 2015

Description

The Event Organiser's Userright is a Userright in Mediawiki designed to help run outreach events.

Holders of this userright can mark the IP they are currently using as an ''Event IP'', or do so remotely marking the IP used by a specific edit made by another user as being an ''Event IP''.

While an IP address is an ''Event IP'':

  1. There is no limit to the number of accounts created from that IP address. However many people attend your outreach event they can all create accounts.
  2. There is no limit to the number of IP/unconfirmed editor edits per minute from that IP address. So the course leader can say "all hit save now" without the current situation of 6 successful saves and the rest of the class needing help.
  3. The capcha requirement for adding external links is waived. So you can train newbies to reference their edits without them being required to complete a capcha.

24 hours after an IP has been set as an ''event IP'' the status lapses.

Logging

Only Checkusers and Oversighters would have access to the log showing which IP addresses had been flagged as ''Event IP''s. So flagging an IP that someone else has used as an ''Event IP'' wouldn't be a sneaky to identify the IP someone uses.

IP Throttles

The three throttles that the userright avoids are all designed to make life difficult for spammers, vandals and unsupervised classrooms of children. This userright only makes tiny and temporary gaps in these very important throttles.

Rights Allocation

As with other user rights this would by default be included in the administrators toolset and be allocated to others by administrators.

Endorsements

  1. As author as someone who would find this useful on the English language Wikipedia, and in my capacity as GLAM organiser for Wikimedia UK. Jonathan Cardy aka WereSpielChequers

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Fae added a comment.Mar 12 2015, 3:31 PM

I found the description slightly confusing. I initially read this as being an extension to the administrators toolset, however based on the later explanation, I understand the key rationale is the ability to provide this right to non-administrators.

I am not convinced by this as a use case, as I have never heard of an editathon or GLAM event where it was actually impossible to find an administrator willing to help out. As it is easy to provide this sort of help remotely via IRC or email, an admin could be in a different country and still assist with patrolling a list of accounts or helping with other admin actions for new users that run into problems. However I do not feel strongly, as this seems primarily an English Wikipedia based request.

It would be nice to see this Phabricator request supported by a local community consensus for an open proposal for the right on the English Wikipedia, on the presumption that the right may only ever exist there. I do not see this as a lot of extra work for anyone, as the proposal could probably be a cut & paste job from this task request.

I agree with Jonathan, it would be useful to have this as a Userright. We need to make running editathons more straight forward.

I think that having a 24 hour window is a useful suggestion and I do not think it would open a significant opportunity for vandals.

WereSpielChequers added a comment.EditedMar 12 2015, 6:39 PM

Hi Fae, I take your point re "As with other user rights this would by default be included in the administrators toolset and be allocated to others by administrators". Can you suggest an alternative to make clear this is not just for administrators? As for which wikipedias would use this, we currently have interest expressed from Catalan and Swedish as well as English, outreach takes place in lots of languages so I would expect quite a wide take up.

As for getting admins to help out, yes that's usually possible, but at least in English Wikipedia we have a declining pool of admins and we need to invest in making ourselves less dependant on admins. Also having admins and account creators is a poor substitute for people actually being able to create accounts themselves. So this right would result in a better experience for the volunteers who run events as well as newbies who attend them.

KTC added a subscriber: KTC.Mar 12 2015, 7:46 PM

This would be very useful; and in training sessions run in-house by Wikimedians in Residence, too. I've had a lot of valuable training-time wasted dealing with the issues described.

Correct me if I am wrong, but this is what ThrottleOverride extension does. If not, let's just add these features to the extension. When a sysop sets an exception for certain IP addresses or ranges with an expiry time set, users from the IP address/range can bypass the default rate limits until the expiry time. By introducing a new userright instead of noratelimit, which the extension currently uses, we can take one step for getting this resolved.

Instead of developing a completely new extension for this, let's just improve the ThrottleOverride extension and get it deployed to Wikimedia projects. :)

That link didn't work, does the throttle override extension do all of the things that this would do, and does it have the same privacy compliant features to enable remote use, and also does it have the same temporary feature that would leave our anti spam and antivandalism filters working on all other IPs?

That link didn't work,

Which link?

does the throttle override extension do all of the things that this would do,

If the extension doesn't have needed functionality, then we can add them, as I already said.

and does it have the same privacy compliant features to enable remote use,

I'm not sure whether the log should be private. Currently, we don't have a log in ThrottleOverride extension but what we've been doing on the mediawiki-config's throttle.php for years now has been public. Anyone can view the history of throttle.php and I haven't seen any privacy issues being raised regarding it.

and also does it have the same temporary feature that would leave our anti spam and antivandalism filters working on all other IPs?

Yes, only certain IP address/range are exempted. Currently, ratelimits can be bypassed for account creation, edits, moves and emails.

Change 196780 had a related patch set uploaded (by Glaisher):
Use a new right ('throttleoverride') instead of 'noratelimit'

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

How would "throttleoveride" be of use to event organisers, trainers, Wikimedians in Residence, etc, who are not sysops?

How would "throttleoveride" be of use to event organisers, trainers, Wikimedians in Residence, etc, who are not sysops?

We can create a user group with the throttleoverride right as needed.

Change 196780 merged by jenkins-bot:
Use a new right 'throttleoverride' instead of 'noratelimit'

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

Nemo_bis closed this task as Resolved.Mar 20 2015, 9:03 AM
Nemo_bis claimed this task.
Nemo_bis reassigned this task from Nemo_bis to Glaisher.
Pigsonthewing reopened this task as Open.Jun 19 2015, 1:54 PM

Reopened - this is not resolved by "throttleoverride", according to https://lists.wikimedia.org/pipermail/wikimedia-l/2015-June/078309.html

revi added a subscriber: revi.Jun 19 2015, 2:13 PM
Krenair closed this task as Resolved.Jun 19 2015, 2:17 PM

The extension we're discussing here is not deployed to WMF sites, so you wouldn't see it take effect there, @Pigsonthewing. Please read the previous comments.

Please credit me with some intelligence. This has nothing to do with "deployment to WMF sites". The proposed solution /when deployed/ will not not resolve the issue described.

revi added a comment.EditedJun 19 2015, 2:33 PM

Please credit me with some intelligence. This has nothing to do with "deployment to WMF sites". The proposed solution /when deployed/ will not not resolve the issue described.

ThrottleOverride extension is not deployed into WMF cluster. So you won't see this on wikimedia wikis.

There is a throttle setting that is overridden of WP:EN, specifically to allow the use of mass rollback/undo. Perhaps this same mechanism could be applied here.

revi added a comment.Jun 21 2015, 6:51 AM

There is a throttle setting that is overridden of WP:EN, specifically to allow the use of mass rollback/undo. Perhaps this same mechanism could be applied here.

Please open a new bug for new suggestion.

WereSpielChequers reopened this task as Stalled.EditedAug 3 2015, 9:30 PM
WereSpielChequers changed the task status from Stalled to Open.
WereSpielChequers raised the priority of this task from Lowest to Normal.

I've reopened this and changed it to stalled as this development is not the same as the one it was incorrectly conflated with.

I've reopened this and changed it to stalled

Actually you removed the status "stalled" by setting the status to "open"...

czar awarded a token.Sep 7 2015, 10:32 PM
czar added a subscriber: czar.

So what is this report now, a request to enable the extension in Wikimedia? Literally speaking, "The Event Organiser's Userright" is already fixed in Wikimedia by the account creator group.

The "account creator" right (which I hold, for en.WP) does not do the same thing.

does not do the same thing.

What is missing? If you literally mean the user should be able to *alter* $wgRateLimits, this is a duplicate of T28992.

What is missing? If you literally mean the user should be able to *alter* $wgRateLimits, this is a duplicate of T28992.

Having a way to alter $wgRateLimits for a specific IP on a specific project does not have to involve a full implementation of T28992. Yes, it would mean code modifications, and any solution we implement would need to have a security and performance review, but it could probably be done without implementing the full config database described in T28992.

Quoting mw:Mass_account_creation#Requesting_temporary_lift_of_IP_cap:

While those with account creator permission can create accounts for people at events, there are sometimes situations where it would be preferable to open an IP to permit on-site individual creation of these accounts, such as at a GLAM event, without needing to login with a privileged account. Allowing people to create their own accounts may help them feel more engaged.

There doesn't necessarily need to be a new user right, but allowing those with the account-creator right to also be able to perform temporary IP address cap lifts would be a huge win for event organizers who have the account-creator right.

That's not [[mw:]] but [[m:]], it's not MediaWiki documentation but some users' opinion.

While those with account creator permission can create accounts for people at events, there are sometimes situations where it would be preferable to open an IP to permit on-site individual creation of these accounts, such as at a GLAM event, without needing to login with a privileged account. Allowing people to create their own accounts may help them feel more engaged.

As you quote this largely incorrect paragraph, I guess it's a danger for public knowledge to let it stay: fixed. https://meta.wikimedia.org/w/index.php?title=Mass_account_creation&type=revision&diff=15270602&oldid=14734061

As I see, the ip limit removing for saving is not needed as the participant of an event should create an account.

In which condition there is a captcha when you are adding an external link (I believed it was only for ip) ?

WereSpielChequers added a comment.EditedAug 10 2016, 9:59 PM

Hi Xcombelle, it isn't just IP editors who have to do a capcha each time they add a link. On English Wikipedia it is also accounts that have not yet been autoconfirmed, ie less than ten edits or less than four days. In practice that means almost all trainees at outreach events. But the trainers don't have the same issue unless we create a new training account for each event, and I doubt anyone does that.

The limit for saving is not just IPs. If it was just IPs we could resolve things just by getting people to create accounts. The problem is it is IPs and accounts that are not yet autoconfirmed. If you have two trainers one of whom is an admin then you can get round this by having the admin set people's accounts as autoconfirmed. But admins are scarce, an extra trainer for each event is a big overhead, and it is embarrassing having to explain that the way we run training events is based on mediawiki having such problems.

Here is a write up from an outreach event in Mexico where they simply had too many people to even try and get them to create accounts due to the IP throttle problems with mediawiki. So the problem is in ES as well as EN, Swedish and so forth.

Without this userright outreach simply doesn't scale.

I'll note that it is now possible to exempt specific IPs (and users logged-in from those IPs) from having to submit captcha by listing the IP addresses or IP ranges at MediaWiki:Captcha-ip-whitelist on the wiki. I realize that it doesn't meet the requirements of this task because only sysops (and others who are allowed to edit interface pages) can edit these pages but at least it is better than how it was previously and I encourage organizers to make use of it (by requesting sysops to add the IPs there) for a better experience for participants.

Romaine added a subscriber: Romaine.
Base added a subscriber: Base.Dec 21 2016, 3:21 PM
Base awarded a token.Dec 21 2016, 3:28 PM
Pharos added a subscriber: Pharos.Apr 5 2017, 1:42 PM
Ivanhercaz added a subscriber: Ivanhercaz.
EddieGP added a subscriber: EddieGP.EditedAug 26 2017, 5:24 AM

Please credit me with some intelligence. This has nothing to do with "deployment to WMF sites". The proposed solution /when deployed/ will not not resolve the issue described.

[...]this development is not the same as the one it was incorrectly conflated with.

I honestly don't think there's someone trying to annoy you here, but it's just not clear what you're asking for. The task description and comments given here lead me to the impression that Extension:ThrottleOverride would indeed solve the problem you're trying to get rid of. If that's not true, could somebody please describe what's the actual difference here?


What Extension:ThrottleOverride is aiming for is to provide a special page to users who hold the right "throttleoverride". That right might be given to admins, account creators or some new group - whatever fits your purposes best. Whether you'd call that right "Event Organiser's Userright" or something else doesn't matter.

On that special page you'd have to input

  1. which IP addresses(es) to exempt ( just google "what is my ip" will do it once you arrived at the location and are connected to their network)
  2. point in time when the exemption of throttles starts (this is not implemented yet, currently one can only use "start right now"; T93468 tracks the implementation of this)
  3. point in time when the exemption of throttles ends (expiration)
  4. reason (as with blocks, providing some information which will be shown in the log)
  5. a number of checkboxes to select which throttles the ip addresses should be exempted from (for example account creation, page edits, page moves etc.)

Again calling it "IP addresses to exempt" or "event ip" is of no difference.

While an IP address is an ''Event IP'':

  1. There is no limit to the number of accounts created from that IP address. However many people attend your outreach event they can all create accounts.

In Extension:ThrottleOverride, marking the "account creation" checkbox will do that.

  1. There is no limit to the number of IP/unconfirmed editor edits per minute from that IP address. So the course leader can say "all hit save now" without the current situation of 6 successful saves and the rest of the class needing help.

Checkbox "page edits" will do that.

  1. The capcha requirement for adding external links is waived. So you can train newbies to reference their edits without them being required to complete a capcha.

This is currently not part of Extension:ThrottleOverride, but of course including it there is a reasonable request. I've created T174225 for that.

24 hours after an IP has been set as an ''event IP'' the status lapses.

Just set the expiration to "1 day" or "24 hours".

Logging
Only Checkusers and Oversighters would have access to the log showing which IP addresses had been flagged as ''Event IP''s. So flagging an IP that someone else has used as an ''Event IP'' wouldn't be a sneaky to identify the IP someone uses.

Removing the throttles is currently done a configuration file. That file as well as it's whole history are viewable for everybody for at least 5 years. Personally I'm not aware of any reason why we shouldn't continue to have this log visible to the public. Besides the question who'll be able to view that log, it's obvious that we'll need such a log in the first place. There is T62421 to integrate that functionality in Extension:ThrottleOverride.

IP Throttles
The three throttles that the userright avoids are all designed to make life difficult for spammers, vandals and unsupervised classrooms of children. This userright only makes tiny and temporary gaps in these very important throttles.

Only the IP addresses that are exempted from the throttle get special treatment, for other IPs nothing will change. Admins can remove throttle exemptions that are abused at any time (and of course they still could block users).

Rights Allocation
As with other user rights this would by default be included in the administrators toolset and be allocated to others by administrators.

As mentioned above, we can assign the right "throttleoverride" to any user group that is preferred and/or assign it to a separate user group and enable bureaucrats/admins to add/remove users to/from that group.

Endorsements
And of course one of the biggest reasons for having this userright is that it can be done during the setup period before the participants start to arrive, thus freeing up trainer time for actually getting people to do useful edits.

So you'd arrive at the event, google "what is my ip", copy that address and paste it into Special:OverrideThrottle, fill out the rest of the form and hit "submit". The throttle would be gone instantly.

This proposal is for a 24 hour unthrottling for the event, if you really think this could be a problem it should be possible to code the right so the window was a number of hours set by the person with that right with a start and end time that only covers the event. But a preset 24 hours seems to me simpler and a reasonable window.

Extension:ThrottleOverride as it is today asks to set any expiration time one chooses, in the same was Special:Block asks for a expiration. There's not much point in removing the flexibility of users being free to choose whatever expiration they like.

Note: All of what's described here would only apply once Extension:ThrottleOverride is deployed to WMF cluster - which it is currently not, as it is still lacking basic features (logging, deleting throttles, changing throttles) and - after that features have been integrated - still needs a security review (T27000).

The proposed solution /when deployed/ will not not resolve the issue described.

[removing captchas] is currently not part of Extension:ThrottleOverride

Thank you for confirming that my statement "The proposed solution /when deployed/ will not not resolve the issue described" is true.

I've created T174225 for that.

And thank you for that also.

Thank you for confirming that my statement "The proposed solution /when deployed/ will not not resolve the issue described" is true.

The "proposed solution" is, and was from the very beginning (as suggested in T91928#1118877 and T91928#1118936) to do both

  • deploy Extension:ThrottleOverride (which includes developing all the features necessary to do so)

and

  • add missing features to that extension

The "issue described" means the three bullet points in the task description. #1 and #2 would be resolved by deploying ThrottleOverride (T27000) and #3 would be resolved by adding another feature to ThrottleOverride (it would have been senseful to create a specific task for that earlier; which, as I said, was now done with T174225).

So if you claim that "The proposed solution when deployed will not resolve the issue described" I can only try to describe why I think that's not true (which I've done now) and repeat Krenairs question (T91928#1382256):

Why not?

czar removed a subscriber: czar.Oct 5 2017, 7:10 AM
He7d3r added a subscriber: He7d3r.Dec 29 2017, 11:45 AM