@JMatazzoni (WMF): - any of your feedback on this would be most welcome.

Hi everyone, so in looking how to make things better, I'd like to discuss setting outreachdashboard.wmflabs.org to ratelimit exempt. There are some pro's and con's of this (I started a list below, feel free to add examples). In testing, it appears thaaccount created through the request/create process on outreachdashboard all come from an internal (RFC 1918) address

Pro's

1. This would be self-service and would alleviate the need to set up account creators/evc's on-wiki simply to create accounts.

Con's

1. Abuse of outreachdashboard may be harder to deal with. (Though the internal IP could be outright blocked). Perpahs JMatazzoni can expand on options for volunteers admins on that tool?
2. If an event is going to have a need to manually confirm on-site users, a coordinator may still need EVC access. (Though for certain types of events this may not be an issue - especially not for ones that don't use enwiki). - This could be a possible feature request to the outreachtool (e.g. add +confirmed for 10 days to created users)

Discuss

Thoughts anyone? — xaosflux ^Talk 18:42, 27 December 2018 (UTC)[reply]

Pings to some editors above that have been active in this topic: @Theredproject, TonyBallioni, Swarm, and Bluerasberry:. — xaosflux ^Talk 18:44, 27 December 2018 (UTC)[reply]

I agree that this would be the ideal. Thanks for your work on this, xaosflux. TonyBallioni (talk) 19:23, 27 December 2018 (UTC)[reply]

Agreed, this sounds like an obvious solution. I also agree with granting a temporary confirmed status via the outreach tool. That sounds more reasonable than having it all needlessly tangled up in enwiki RfPERM. But, this is assuming that the people using the outreach tool are legitimate users who know what they're doing. Is there any kind of scrutiny or restrictions regarding the access to this tool? We don't want any random users to be able to sign up and have these permissions by default without any scrutiny. If we grant these abilities to the tool by default, what is the gatekeeping system for tool access going to be?  Swarm  {talk}  20:15, 27 December 2018 (UTC)[reply]

Fwiw, the reasons you bring up about gatekeeping are why I much prefer this being localized rather than centralized on en.wiki. Our policy is to grant these permission on a temporary basis to non-established editors, but are fine with permanent granting to established en.wiki editors because we can judged their record. We can't really judge if someone has a good record on the project they are working on if we aren't active there, while local sysops can. As I've said above, we'll obviously keep doing what we have to do, but getting this more integrated with other local projects so that they can set their own standards for use should be the long-term goal.​ TonyBallioni (talk) 20:33, 27 December 2018 (UTC)[reply]

@TonyBallioni: it looks like that tool DOES have options for other projects, have you ever tried them? — xaosflux ^Talk 20:39, 27 December 2018 (UTC)[reply]

No, I've never used it personally, I was going off of the discussion above about only working on en (and sorry if I confused things, there being multiple dashboards with different configurations is a bit confusing.)

If it does, then what might be the best thing would be to start a discussion on meta about some sort of system for using it along the lines of what Swarm is discussing. It actually might be best to have it centralized on meta where stewards, who tend to include sysops from different projects, would be able to grant somewhat like the Global-OTRS group. TonyBallioni (talk) 20:44, 27 December 2018 (UTC)[reply]

OK, for testing I set up an enrollment for eswiki, however it created the account here still. — xaosflux ^Talk 20:56, 27 December 2018 (UTC)[reply]

@TonyBallioni and Xaosflux: Weird that setting up an account for another wiki still creates it on enwiki, but if I'm not mistaken, that doesn't matter because the accounts created are global. Xaosflux, I think if you tried to log in at eswiki, it would automatically work (feel free to test, I'm assuming here). Can you also confirm that account via the dashboard? If so, does confirmation carry over to other projects? If not, then the current system doesn't fully work anyway. It either needs both the acc and confirmation permissions written into the software itself, with some sort of centralized, global gatekeeping system, or it needs to be entirely decentralized, and only rely on local permissions. (Sorry if I'm just restating the obvious.)  Swarm  {talk}  00:02, 28 December 2018 (UTC)[reply]

It doesn't matter because of SUL, but it does matter in terms of your "gatekeeper" concept. I'm of the belief that local projects should be the judge of who they want to have access to it for things that will be affecting them. As an example, despite my edit count there, for a variety of reasons I'm heavily involved with cross-wiki work with the Arabic Wikipedia. Despite that, I don't know any of their policies and guidelines, outside a vague understanding of how they deal with socking, and basically interact with a handful of sysops and functionaries and don't really know anyone in the general editing community. I also don't speak a word of Arabic. I really shouldn't be deciding who has the rights to create a ton of accounts that will be used on ar.wiki or for that matter pt.wiki.

I'm willing to now because apparently outreach stuff was designed with only en.wiki in mind, but since we're talking about ideals here I'm saying that my ideal is that local communities set up their own policies for how they want outreach to work on their project and en doesn't get to decide how stuff works elsewhere. Either that or centralize it to meta and have stewards who are familiar with the language in question sort it out. I just don't want en to be the permanent home for outreach efforts for a global movement. TonyBallioni (talk) 00:18, 28 December 2018 (UTC)[reply]

Yeah, not every project delegates the ability to confirm accounts, it's actually a brand new concept here. So, fair point, we probably shouldn't write that into the software for global use. Local outreach coords need to coordinate with local admins on that, and it should be left with the local communities whether EVC-style delegation of confirmation ability is implemented. I think ratelimit exemption, on the other hand, is less controversial, and that can be written into the dashboard. It likely wouldn't change anything in practice, but it would remove enwiki admins from the position of having to make that decision for other projects. Are we on the same page here?  Swarm  {talk}  00:33, 28 December 2018 (UTC)[reply]

Sounds like it. TonyBallioni (talk) 00:39, 28 December 2018 (UTC)[reply]

FYI: phab:T188630 suggests this dashboard may already be using a grant with high limits, but this may be dependent on the end user also having the access - which is the problem we are trying to avoid. — xaosflux ^Talk 21:06, 27 December 2018 (UTC)[reply]

@Sage (Wiki Ed): can speak to this directly, but I believe that we found it required both the app/API request **and** the user/API requester to have permissions. --Theredproject (talk) 23:40, 2 January 2019 (UTC)[reply]

That's correct. Programs & Events Dashboard requests the high-volume editing grant so that users with the right to create accounts beyond the standard limit can do so through the Dashboard. It doesn't get around needing the rights in the first place.--Sage (Wiki Ed) (talk) 23:45, 2 January 2019 (UTC)[reply]

Question to Sage and others: Setting aside the administrative/consent, is it technically possible to "get around needing the rights in the first place"?--Theredproject (talk) 04:58, 3 January 2019 (UTC)[reply]

• It sounds like the new issue that we are discussing is how having events in any language or project affects every other language and project. If anyone sets up an account creation process in the Dashboard or Wikimedia project in any language, then that circumvents all the review processes in English Wikipedia. I suppose this has actually been an issue since the inception of SUL, but only now is this case coming up a lot in practice.

Again - a typical use case is someone with a new, 0-edit Wikimedia account needing to make 30 new Wikimedia accounts with a few days notice. We have not yet had someone set their account up in Spanish / Hindi / whatever then have people start editing English Wikipedia, but this seems to be a likely future trend.

I am not sure what the technical solution is. There are at least a few technical developers here - Joe @ WMF, Sage @ Wiki Ed, and then Wikimedia community people who have been regulating the ENWP user rights from a security perspective. The social side of this is flexible just so long as an approved path exists to run outreach events for new users. Blue Rasberry (talk) 15:19, 28 December 2018 (UTC)[reply]

@Bluerasberry: do you have more insight to how these 0-edit Wikimedia account needing to make 30 new Wikimedia accounts are getting recruited? — xaosflux ^Talk 15:39, 28 December 2018 (UTC)[reply]

@Xaosflux: Yes, the Wikimedia Foundation has been incentivizing this behavior with funding since about 2013 after doing experiments in this space since about 2010. If I had to guess I would say it is about 20% of the funding in meta:Grants:Start. So far as I know you and the other regulars in the conversation do not participate in any conversations about the WMF outreach funding strategy. It has always struck me as strange that some ENWP policy proposals regarding account creation in outreach have been contrary to what the WMF pays and funds people to do. Blue Rasberry (talk) 15:50, 28 December 2018 (UTC)[reply]

Thanks, this seems more in line with opening up the self-service via the dashboard. Still hoping to get some feedback from JMatazzoni (WMF) on this. — xaosflux ^Talk 16:02, 28 December 2018 (UTC)[reply]

Hi @Xaosflux: I'm working on a project for event organizers, it's true, though it's unconnected to Dashboard. This interesting idea seems to fall into the domain of Security team, so I'm pinging @JBennett (WMF):, who may be able to offer guidance. Good luck! JMatazzoni (WMF) (talk) 17:43, 2 January 2019 (UTC)[reply]

Hi All, I have been AFK for a bit. I support this general approach. I note that we will still want to get our en wiki organizers to have EVC if we can, but the main concern isn't confirmation, but rather account creation limits. So that will be great. I also note that many non en wiki organizers do not (e.g. refuse to) use the dashboard. So this may proved to a problem there, but I think that is a second tier problem to deal with. Overall, though I support, if it is technically possible. Thanks all for your ongoing thoughtful consideration of this use case. --Theredproject (talk) 23:43, 2 January 2019 (UTC)[reply]

@Theredproject: I'm in discussion with a group of staff on some options. For non-enwiki events where people don't want to use the dashboard, well that really isn't our problem, other projects can manage their own account creators. Right now all dashboard creations get made here, so that is somewhat our problem (even if that user will never edit here) Account creation limits are the first thing that we are working on, and using the dashboard is likely the best near-term solution for that (especially for massive campaigns like A+F). Local 'event coordinator' will still be necessary if an event is going to require manual confirmations (if for example if participants will be directly full articles or needing to upload fair-use media). — xaosflux ^Talk 14:23, 3 January 2019 (UTC)[reply]

This is the get around needing the rights in the first place part. — xaosflux ^Talk 14:25, 3 January 2019 (UTC)[reply]

Thanks Xaosflux. I hope that Wolliff (WMF) or someone else from the community team is part of the group you are discussing with. Especially per Bluerasberry's comments above about communication between ENWP admins and WMF outreach. Again, thank you.--Theredproject (talk) 16:13, 3 January 2019 (UTC)[reply]

@Theredproject: so far it's John Bennett, Sage Ross, and Sam Walton. — xaosflux ^Talk 22:05, 4 January 2019 (UTC)[reply]

Hi Xaosflux just checking in on this, to see if there are any updates. We are six weeks from the start of the March Art+Feminism events. We are starting to get inquiries from regular event organizers (rather than the regional organizers who have done test requests so far) so the first wave of requests is only about two weeks away. People are already following last year's workflow, so I want to make sure we have a plan in place, so we can direct them to the right workflow. --Theredproject (talk) 20:36, 13 January 2019 (UTC)[reply]

@Theredproject: what do you think is a realistic maximum number of accounts that would get created per-day related to the events? — xaosflux ^Talk 21:42, 13 January 2019 (UTC)[reply]

Sage (Wiki Ed) might have data, but I would say that the range might be between 20 and 250 accounts per day? Some of the bigger days there will be dozens of events around the world: March 2, the first weekend + MoMA day, March 8 [International Women's Day], March 9, the Saturday directly after IWD are some of the heavier days. I can tell you that at MoMA alone we prob create 40 accounts that day (plus we get IP limits lifted for that location for the day, because another 10 or so will just do it themselves while they are waiting to check in). Also, I'm kind of guessing as I only track the number of accounts that were created through dashboard request (e.g. not created by an ACC), when many of the other events had account creators who were able create the accounts themselves via en wiki or dashboard.--Theredproject (talk) 22:40, 13 January 2019 (UTC)[reply]

• Update: so we haven't come up with a fix for this yet, so will certainly keep processing temporary requests for coordinators. Due to the way the dashboard works right now, the "fix" for this is likely going to be to assign a bot account to the dashboard and let it make the accounts - this requires some technical changes on the dashboard. The accounts would still need to be approved by the coordinator, just the actual "created by" would be the bot account. — xaosflux ^Talk 04:09, 17 January 2019 (UTC)[reply]