Wikipedia talk:Requests for permissions/Archive 9

Archive 5

←

Archive 7

Archive 8

Archive 9

Archive 10

Archive 11

NPR being "use-it-or-lose-it"

This is a 'use-it-or-lose-it' right. doesn't seem to reflect current policy. Perhaps someone would like to adjust this. TheDragonFire (talk) 17:36, 14 September 2018 (UTC)

@TheDragonFire: Indeed, something more specific and clearer such as "If this right isn't used by an account for over a year, it may be removed" would probably be better. I have noticed many editors confused by this, thinking that they can only have the right if they're going to use it constantly, which is not the case. Just in case you didn't know, you can edit this yourself at WP:Requests for permissions/Header.--SkyGazer 512 ^{Oh no, what did I do this time?} 17:38, 14 September 2018 (UTC)

Ah, missed that. My understanding was it was 12 months inactivity globally, rather than 12 months with no patrols logged. As such, I've just removed the note altogether as too verbose for an index page like that. Feel free to tweak if need be. TheDragonFire (talk) 17:45, 14 September 2018 (UTC)

This has been talked about over and over by the powers that be (or want to be) at NPP, but I don't think anything's actually been decided regarding how long you can be inactive or what counts as activity. Natureium (talk) 17:48, 14 September 2018 (UTC)

(edit conflict) @TheDragonFire: You're right that the policy states that anybody who's inactive for over a year has the right removed. However, I have noticed that admins have been removing the NPR right from inactive patrollers, even though it isn't listed as any kind of policy, so it may be worth mentioning here. I personally think removing the text for now is fine, which you've already done.--SkyGazer 512 ^{Oh no, what did I do this time?} 17:50, 14 September 2018 (UTC)

Yep, it just refers to the clause that it may be revoked after one year of inactivity. I've also encountered users worried about the meaning of that particular phrase, so I have no problem with removing it. @SkyGazer 512: who's inappropriately revoking the right based on the "use-it-or-lose-it" sentiment? That's extremely inappropriate and potentially abusive. Swarm ♠ 17:54, 14 September 2018 (UTC)

Kudpung was going to go on a removal spree before I left a concerned note. I wouldn't be surprised to hear that someone else is doing it now. --Izno (talk) 18:00, 14 September 2018 (UTC)

And he did make at least one inappropriate removal 00:42, 30 July 2018 Kudpung (talk | contribs) changed group membership for Darylgolden from extended confirmed user, new page reviewer, pending changes reviewer and rollbacker to extended confirmed user, pending changes reviewer and rollbacker (Inactive for over 6 months) (thank). I didn't see any others in the past month and a half of permissions changes. --Izno (talk) 18:30, 14 September 2018 (UTC)

(edit conflict) (x4) @Swarm: Kudpung and possibly other admins were removing the right from users who haven't used the permission for many months, sort of what Izno said. I personally wouldn't regard it as "extremely inappropriate," but it probably should have been discussed at least.--SkyGazer 512 ^{Oh no, what did I do this time?} 18:31, 14 September 2018 (UTC)

Btw, why was this ever listed as "use-it or lose-it" to begin with? Was it only put in solely because users who have been completely inactive for over a year should have the right removed?--SkyGazer 512 ^{Oh no, what did I do this time?} 18:39, 14 September 2018 (UTC)

Looks like Kudpung added it in recently, on August 4, see Special:Diff/853450238.--SkyGazer 512 ^{Oh no, what did I do this time?} 18:41, 14 September 2018 (UTC)

To be clear as I have been noted as a big factor in NPR, I have not done this and have no plan to start conducting this sort of removal. -- Amanda (aka DQ) 19:29, 14 September 2018 (UTC)

Just FYI, I frequently remove groups from inactive users when the group has inactivity as a revocation condition, but I only ever check total inactivity, not specific actions. — xaosflux ^Talk 20:02, 14 September 2018 (UTC)

Temporary grants

On an aside, I'm seeing some temporary grants of the rights in the logs recently, mostly by DeltaQuad. Where is the consensus for that on the guidelines page, on this page, or on the admin instructions for granting? I think that should probably be RFCd, as I find that practice questionable, at-best. --Izno (talk) 18:15, 14 September 2018 (UTC)

We started doing this for various permissions after the software rolled out the feature. When I do it (mainly for rollback) it replaces telling someone who I would otherwise decline to come back in X month(s). It’s a way to give people who otherwise would not be granted a flag a chance to show they can use it correctly. Most people would prefer this instead of being flat out rejected in my experience. TonyBallioni (talk) 18:21, 14 September 2018 (UTC)

Most people would prefer this instead of being flat out rejected in my experience. I don't doubt that is so, but that isn't (the) consensus for use of that particular feature in that particular way. I'm pretty sure we had an RFC on this new feature.... --Izno (talk) 18:29, 14 September 2018 (UTC)

Uh, the consensus is that we've been doing it for almost a year now and no one has questioned it until now? We don't need a rule telling people how to use ever technical right they are assigned. It's reasonable to assume that if admins have the ability to reject granting a flag or to remove it, they also have the ability to temporarily grant a permission they would have otherwise rejected. This is the type of thing that evolves organically and doesn't need an RfC. Consensus is first and foremost what we do, and allowing people who would otherwise not have been given a permission the ability to use the flag for a temporary amount of time is a good thing. If the documentation needs to be updated, we can do that pretty easily. TonyBallioni (talk) 18:39, 14 September 2018 (UTC)

I'm questioning it per the same guideline--"we've been doing it that way" isn't good enough. --Izno (talk) 18:42, 14 September 2018 (UTC)

Yes, it is. That is how Wikipedia works. We are not a bureaucracy, and policies and guidelines document accepted practice, not vice vera. TonyBallioni (talk) 18:44, 14 September 2018 (UTC)

Prove this is the consensus. That's what I'm asking you to do. I see no talk page discussion, anywhere. Can you find the editing community which signed off on it and said "this is okay"? Admins deciding on their lonesome (or through some non-public discussion) that they can just hand out the rights as they see fit smacks of unaccountability, no matter how good-faithed. Either hand out the rights as the current consensus is documented, or verify that you are acting within consensus with an RFC. I'm more than happy to start one and get SNOW closed on if you are unable or unwilling. See also my reply to Joe below. --Izno (talk) 18:46, 14 September 2018 (UTC)

And if you're going to dump "NOTBUREAU" on me, I'm going to ask you: why should I need to request permissions? Yeah, because it's a bureaucratic process. --Izno (talk) 18:48, 14 September 2018 (UTC)

You don't need to request permissions. Any admin can give them out at any time with or without a request.

You are misunderstanding how Wikipedia works, and as it was pointed out in the discussion you linked to below: our policies and guidelines document what the accepted practice is. We don't have a rule or RfC on everything, and given how heavily scrutinized every admin action is, if there was any actual objection to this, I'd have expected it to come up before now. TonyBallioni (talk) 18:56, 14 September 2018 (UTC)

Granting rights temporarily seems like a diplomatic and entirely sensible way to respond to editors who almost-but-not-quite meet the requirements. What do you find questionable about it? – Joe (talk) 18:36, 14 September 2018 (UTC)

Agreed.--SkyGazer 512 ^{Oh no, what did I do this time?} 18:39, 14 September 2018 (UTC)

If it is so sensible, I would expect it to be in our guidelines somewhere. And to have been added there by consensus of the project. (Two separate hurdles.) Secondly, mostly that the original discussion surrounding it had nothing of "we should allow users to demonstrate their ability", and given the perennial discussion at WT:RFA about "interim admins", I get the feeling that there might not be consensus for temporary grants in this sense. --Izno (talk) 18:42, 14 September 2018 (UTC)

I agree that we should add it to the guidelines somewhere, maybe under WP:User access levels, Wikipedia:Requests for permissions, and/or Wikipedia:Administrators' guide/Granting and revoking user rights - as I do think it's kind of strange that it's not mentioned anywhere.--SkyGazer 512 ^{Oh no, what did I do this time?} 18:44, 14 September 2018 (UTC)

Updated. There is no need for an RfC for this, as it just reflects what is already being done. TonyBallioni (talk) 18:56, 14 September 2018 (UTC)

It's already is, on this very page: At administrators' discretion, the right may be accorded on a time limited basis or indefinite. – Joe (talk) 18:58, 14 September 2018 (UTC)

You're right, but it previously only said so for NPR and PM, not for any of the rights. I do agree with Tony that we don't need an RfC for everything, per WP:BOLD and WP:IAR.--SkyGazer 512 ^{Oh no, what did I do this time?} 19:01, 14 September 2018 (UTC)

Totally agree. RfCs aren't the only way to form consensus. Doing-something-sensible-and-nobody-objecting is sufficient in 99% of cases. If someone actually has a substantive objection to temp rights, then sure we can have a discussion about it. But insisting on a formal poll just in case somebody objects is tedious and bureaucratic. – Joe (talk) 19:06, 14 September 2018 (UTC)

I'm responding here per WP:ADMINACCT. WP:IMPLICITCONSENSUS says "Consensus is a normal and usually implicit and invisible process across Wikipedia. Any edit that is not disputed or reverted by another editor can be assumed to have consensus." An RFC can be started now, but as you noted in [1], all it really needs is a bold edit, unless you completely disagree with it and we need an RFC on the matter. -- Amanda (aka DQ) 19:27, 14 September 2018 (UTC)

I agree with TonyBallioni and Joe Roe. Schwede66 04:57, 15 September 2018 (UTC)

Whether separate request needed

I am currently a user of both english as well as malayalam wikipedias. If I request for this feature in English wikipedia, with that permission can I update malayalam wikipedia? Or do I need to get it in Malayalam wikipedia also?Adithyak1997 (talk) 11:30, 16 September 2018 (UTC)

• User rights granted here will only work on the English Wikipedia. Swarm ♠ 18:21, 16 September 2018 (UTC)

Semi-protected edit request on 20 September 2018

Change Western State Colorado University page title to Western Colorado University. WSCU (talk) 17:26, 20 September 2018 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Kpgjhpjm 17:34, 20 September 2018 (UTC)

I'm not sure how much more specific you could get than that. Natureium (talk) 17:39, 20 September 2018 (UTC)

Change Western State Colorado University to Western Colorado University Agray47 (talk) 17:30, 20 September 2018 (UTC)

 Not done: it's not clear what changes you want to be made. Please mention the specific changes in a "change X to Y" format and provide a reliable source if appropriate. Kpgjhpjm 17:33, 20 September 2018 (UTC)

@WSCU: and @Agray47: this page is the wrong venue to request a page move (which is what "renaming an article" is), however please see Wikipedia:Requested moves which can help you with your requests. — xaosflux ^Talk 18:23, 20 September 2018 (UTC)

Instructions

I noticed that the header and Wikipedia:Requests for permissions/Administrator instructions both say that "Administrators are permitted to grant account creator, autopatrolled, confirmed, event coordinator, file mover, mass message sender, pending changes reviewer, rollback and template editor flags to any user who meets the criteria explained above and can be trusted not to abuse the tool(s)."

Does this just need to be updated to include NPR and extended mover or are they not listed for a reason? Natureium (talk) 22:27, 27 October 2018 (UTC)

Simple answer: the page was written before either of those permissions were around (see [2]) and no one added them because that page isn't updated that frequently (none of the admin instruction pages are, tbh.) TonyBallioni (talk) 23:24, 27 October 2018 (UTC)

Autopatroll for people with New page reviewer

As I go about my NPP once in a while I come across a new article made by someone whose name I recognize for also doing NPP. This has always felt a bit silly. While I can imagine scenarios where we could trust someone to patrol others pages but not their own, this does not seem the norm. Especially because it feels far easier to acquire autopatrol than new page reviewer. Can I suggest that granting admin give some consideration to granting autopatrol along with NPP where appropriate? Best, Barkeep49 (talk) 17:14, 2 November 2018 (UTC)

Reverting edits

If someone reverted some of my edits using roleback, would I be told so or would it just say my edits were reverted? A 10 fireplane (talk) 16:30, 8 November 2018 (UTC)

Semi-protected edit request on 14 November 2018

Hi, My name is Raunak Ghosal and I am the Social Media Manager of "Kolkata Games and Sports PVT LTD. As the club official to "ATK (football team)" i would request you to grant me permission to maintain and edit the Wiki page of the Club. The page is right now being reviewed by multiple users, which is leading to a lot of vandalism on the page.

please take action at your earliest. Raunak6392 (talk) 20:04, 14 November 2018 (UTC)

 Not done: this is the talk page for discussing improvements to the page Wikipedia:Requests for permissions. Please make your request at the talk page for the article concerned. SkyGazer 512 ^{Oh no, what did I do this time?} 20:11, 14 November 2018 (UTC)

Semi-protected edit request on 28 November 2018

The title of our organization has changed from "Federation of Earth Science Information Partners" to "Earth Science Information Partners." Thus, I would like to move this page: https://wiki.riteme.site/wiki/Federation_of_Earth_Science_Information_Partners to https://wiki.riteme.site/wiki/Earth_Science_Information_Partners (which does not exist yet. I can not make this move as I do not have those permissions. I think this is in the realm of what this type of request is for. I apologize in advance if this is not the correct mechanism for this change. Anniebburgess (talk) 23:55, 28 November 2018 (UTC)

 Not done: page move requests should be made at Wikipedia:Requested moves. DannyS712 (talk) 00:19, 29 November 2018 (UTC)

EVC requests for Art+Feminism coordinators and regional organizers

Hi TonyBallioni, I noticed that you rejected Museu33389’s request for EVC permissions, because Museu33389 will be holding Art+Feminism events that focus on pt wiki. You referred Museu33389 to RadiX to explore getting these permissions on pt wiki. As a representative of the Art+Feminism project, I would like to discuss this with you, swarm and Xaosflux who also are active in approving EVC requests, to try to reach a consensus about how to move forward. CC'ing Pharos and Bluerasberry who have been part of this effort over the five previous years, and Sage Ross (WMF) who is the lead Dashboard developer.

I would like to share two pieces of information:

1. We use the Outreach Dashboard, which is an international tool (with language localizations) but which relies on en wiki ACC or EVC permissions for its account creation functions. I believe it does so because these permissions do not exist on many other wikis, or are so rarely used that they effectively do not exist.
2. We are going to have organizers on at least two dozen language wikis that will need EVC or ACC permissions. We will have over 300 events, and each of them will need at least one organizer with the ability to create accounts. It was hard enough in the past to manage getting everyone signed up for en wiki. Trying to track 300+ people through 30+ different pipelines and protocols is a recipe for tears.

I know there is responsibility and trust placed in you as an admin. I can imagine that you might perceive these A+F requests as a by-pass to the review process on other language wikis. I understand the principles at play, but the reality is that is a moot point: As you well know, these accounts are global, so the ability to create accounts on en wiki has the exact same effect as the ability to create accounts on pt wiki, or any other wiki. The potential for abuse is exactly the same — though I would be quick to point out that our A+F events have an extraordinarily low article deletion rate of less than 1%, and correspondingly have never had any abuse of these permissions at over 500 events.

If you are concerned about the potential for abuse of EVC’s ability to Autoconfirm users, would you prefer that organizers on non-ACTPERM wikis apply for ACC? While that will probably lead to some confusion, two pipelines is viable. Establishing and following more than 30 is not.

Respectfully, Theredproject (talk) 21:10, 21 December 2018 (UTC)

I support everything theredproject is saying here and am around for ongoing conversation. Blue Rasberry (talk) 21:22, 21 December 2018 (UTC)

So, after poking people are more familiar with this than I am (cc: L235), I think this is where we are from a technical standpoint:

1. The Outreach dashboard can work on any Wikimedia project.
2. Even if an individual were to be granted a permission that had (noratelimit) on en.wiki it would not actually help them on their local projects, as the rate limiting is on a per project basis. That is to say, if you create 11 accounts on en.wiki with this permission, only 6 of them would be autocreated on pt.wiki as the rate limit per IP still applies there. An individual would need a permission with (noratelimit) on pt.wiki for all 11 accounts to be created.
3. Other WMF wikis have permissions that are equivalent to eventcoordinator and accountcreator. Those that don't can get them implemented, but they will need to get local consensus in order to do so.
4. pt.wikipedia does have accountcreator (see this page).

I have no problem granting people who need it rights here, even if they primarily edit on other projects. I declined originally because of the principle that people who need something on their home project should follow the policies and guidelines of that project rather than en.wiki's policies and guidelines. I think the best solution would be to open up a discussion on pt.wiki about this or contact an administrator on that project. If there really is an absolute need for local rights on en.wiki, we can of course grant it, but I think it's better all around for people if they go through local admins on the projects where they will be using the rights. TonyBallioni (talk) 21:49, 21 December 2018 (UTC)

• If I recall correctly, when using dashboard.wikiedu.org (as opposed to outreachdashboard.wmflabs.org) there is an exemption (c.f. phab:T126541) against rate limited account creation. These are both coordinated by wikiedu - do we have a contact over there that can help? Additionally, with SUL if I recall correctly, it doesn't matter what project you create your account on, it will autocreate (regardless of project rate limits) on any other project once you are logged in. Getting the Program and Events dashboard to work seems like the right answer to me (especially for non-enwiki functions). — xaosflux ^Talk 22:10, 21 December 2018 (UTC)
  • Cool, Kevin said that the he was under the impression that autocreation was still subject to rate limits per IP per project, which is why I mentioned it above. If Sage can provide clarity on that it would be great. It'd also make sense for the dashboard to have a developer implemented IP exemption to the rate limits. TonyBallioni (talk) 22:16, 21 December 2018 (UTC)

Thanks guys. "Sage Ross (WMF)" is long gone from the WMF so that ping did not reach. Sage in official capacity is @Sage (Wiki Ed):, with Wiki Education Foundation presenting the meta:Programs and Events Dashboard. Any thoughts to share Sage? Blue Rasberry (talk) 23:04, 21 December 2018 (UTC)

• @Xaosflux, TonyBallioni, and Theredproject: So, the outreach dashboard is this centralized tool that relies on enwiki account creation permissions to create global accounts that may subsequently be used on other projects? Which means that the local project in question is more or less immaterial, anyone using the dashboard needs to go through us. They're creating global accounts, for which enwiki is technically the "home wiki" according to the software, but that doesn't really matter. Do I have all that right? If that actually the case, and it does work that way, then we should of course be as accommodating as possible and grant EVC for events on other Wikis, assuming that the users requesting make it clear that they're using the outreach dashboard and they need enwiki permissions to fully utilize it, even for other wikis. If that's the way it works, we should work with the system. I understand that point of principle regarding enwiki admins making grants here for the purposes of other projects, and that, ideologically, doesn't sound right, and simply granting the tool that exemption by default as Xaosflux suggests sounds like it would be better. However, as long as it needs to rely on enwiki permissions, I don't think it should be a major sticking point and we should prioritize outreach over ideals.  Swarm  {talk}  23:08, 21 December 2018 (UTC)
  • Swarm, yeah, I edit conflicted with you in replying to Bluerasberry, but obviously we're going to do whatever works here: if people from other projects need en.wiki rights, we'll do it. It's just unclear what the actual technical requirements are, and if rate limits apply to autocreation (two admins I trust on technical stuff have different views on that).
    In this specific case, pt.wiki actually does have accountcreator, which should do the exact same thing as the en.wiki eventcoordinator group, just local to the project where it will be used. I agree with xaosflux as to what the ideal is, and hopefully we can get some clarity on the technical aspects from Sage. TonyBallioni (talk) 23:19, 21 December 2018 (UTC)

    I am near-certain that rate limits don't apply on auto-creation. That we have SUL, anything otherwise would actually be pretty weird. ∯WBG^converse 15:02, 23 December 2018 (UTC)

    That seems like a pretty major security bug. Are you sure that's how it currently works? phab:T13148 seems to suggest that accounts are subject to local wiki checks when being created. Best, Kevin (aka L235 · t · c) 20:39, 23 December 2018 (UTC)

• @NKohli (WMF): is this something you could help with? It looks like this is "almost there" for what these event coordinators are trying to do via the Program and Events dashboard? — xaosflux ^Talk 23:35, 21 December 2018 (UTC)

  • @Xaosflux: Hi! The project you're talking about is actually now being managed by JMatazzoni (WMF). I'll let him respond to this. Thanks! -- NKohli (WMF) (talk) 12:20, 27 December 2018 (UTC)

• Thank you all for your thoughtful and prompt discussion of this. Apologies for pinging the wrong account for @Sage (Wiki Ed):... I think that Sage has to reply re the technical details, but I believe that Swarm is correct above. --Theredproject (talk) 23:58, 21 December 2018 (UTC)
  • We used the Programs & Events Dashboard's account creation feature last year, creating all the accounts on en.wiki including for non-en.wiki events, and it didn't run into any cross-wiki rate limits as far as I know. If autocreation on pt.wiki would be limited based on IP even though the account got created on en.wiki, that's something we haven't accounted for; I'd never heard of that before. In the future, I expect to add an option for users with account creation rights on any wiki to be able to use that wiki for account creation through the Dashboard, but that definitely won't be in place in time for A+F 2019.--Sage (Wiki Ed) (talk) 00:20, 22 December 2018 (UTC)
    • Cool, granted here for 6 months (in the immediate case above). I think making it work with other local rights would be great, but if it requires en, granting until the system is updated to work on other projects makes sense for now. Thanks for the clarification. TonyBallioni (talk) 00:24, 22 December 2018 (UTC)

Thanks everyone here for tying all the threads of this complicated issue into what seems like it will be a solution that works for us all. @Theredproject:, you have the most urgent present need, is this working for you? Thanks. Blue Rasberry (talk) 13:47, 22 December 2018 (UTC)

This is a lot of discussion. Thank you all for your engagement here. I want to summarize what I'm hearing, to make sure I/we understand:

• We are in agreement that having these permissions on any wiki are more or less equivalent to having them on another wiki, because any account, no matter what the "home wiki," can operate on any other wiki because of WP:SUL.
• The Admins who work in this area are okay with the fact that the Programs & Events Dashboard uses en wiki to create accounts, and will approve these requests for events focusing primarily on en wiki, and those focusing on other wikis.
  • Question: does "granted here for 6 months (in the immediate case above)" mean that @Museu33389: has had their perms granted?
• Sage Ross and The Admins who work in this area seek to build in the capability for Dashboard to pull perms from multiple wikis, not just en wiki

My concerns are:

• Whether these permissions are temporary or permanent: the approval for Museu33389 is only for 6 months. Museu33389 is one of 15 regional organizers for the Art+Feminism project. We hold events year round, and our regional organizers are particularly active in supporting events, in person and online. We understand and agree that the permissions for our individual event organizers will only last 3 months, but we believe that the people coordinating this outreach project need to be granted these permissions on a permanent basis, so we don't have to keep coming back here and having these conversations. While this is to some degree the wiki way, these conversations really sap everyone's energy and lead to frustration on all sides.
  • On the same angle, I see that @13ab37: is being questioned on their request about whether the events are in person, and what the dates/ranges and wiki events will be, when we have said repeatedly that we run a year round campaign; the most intense period is March, but we are supporting events year round. 13ab37 is active in WM CA, and has been organizing A+F events for 6 years and coordinating the Canadian A+F events for 5 years. It feels very frustrating to be interrogated like this when we are dealing with experienced organizers. I feel like I personally have talked on wiki with most of the people on this thread about the logistics of A+F process, and the way we work.
  • Which is why I am going to repeat my concern that this process is being done on an individual basis, as opposed to the batches we have done in previous years. This is going to be very offputting to new organizers.
• Whether this direction being proposed is going to lead to a workflow where we have to coordinate and monitor processes on dozens of wikis. As I said above, it is not viable for us to coordinate 300+ organizers through processes on ~30 wikis, many of which have zero users in these ACC roles (which will mean many more discussions like this one, except in languages we may not be able to communicate in, and with admins who don't understand our process). I note that pt wiki is the 15th largest wiki, but has only two people in that role. I am very concerned about that prospect. Theredproject (talk) 22:55, 23 December 2018 (UTC)

Okay, so @Theredproject:, to be clear, everything else aside, if we see an A+F coordinator, they're using a Dashboard that requires enwiki rights, regardless of their primary project of involvement? We have two requests pending. @Xaosflux: you're kind of the de facto leader when it comes to this permission. Are you comfortable with grants to A+F coords on this basis?  Swarm  {talk}  07:08, 26 December 2018 (UTC)

en.wiki is not the supreme wiki and it is a good thing for local projects to take ownership of their own outreach events. I find the opposition to this as a long term goal worrying as the development of local communities and processes should be a key component of what outreach efforts strive to do. This would be good both for outreach efforts and local communities, but at this point is largely academic as it is not the case now.

Re: temporary grants: I don’t really know how individuals with less than 200 (or 10) edits to en.wiki can be considered established users on this project. Asking that someone who is not an established user come by if they still need it 6 months later seems reasonable, because we don’t know who they are or if they’ll still be engaged on this project at that time.

When we first came out with this one of the outreach groups (I’m sorry that o don’t remember which one) gave us a usersubpage with people who needed ACC converted. We went through and changed them. I’m fine doing that in this case as well, but I don’t think setting without an expiry should be done for accounts that don’t actively edit. TonyBallioni (talk) 13:24, 26 December 2018 (UTC)

@Swarm: one of the considerations that is important is if accoutcreator or eventcoordinator should be used - with a big difference being if the event attendees should be getting manually "confirmed". I'm not sure what the goals of these events are, especially related to uploading fair-use media or creating new articles - can anyone expand on that? We are generally very supportive of systems that let us sign up new editors and making sure we don't turn away new editors is very important. That being said, it is also irresponsible to grant indefinite access grants to inexperienced editors (as 2 open requests are asking for right now). Are there any central experienced editors that are coordinating this entire event program that have a schedule, etc? (i.e. - who is recruiting all these coordiantors?) — xaosflux ^Talk 13:43, 26 December 2018 (UTC)

It sounds like we have a temporary solution here but I wanted to respond with a few thoughts for the longer-term. The first is just to say that the problems event organizers have with account creation are known and documented, at least in part. This is something we looked into in connection with the Event Metrics project. We eventually judged it out of scope, but there is a good discussion of problems and possible solutions in this ticket. Meanwhile, I authored a white paper about Movement Organizers (for an ongoing 3-5 year strategy project) in which I single out account-creation issues as an "urgent problem" that "we should address in the near term." Lastly, the WMF’s 2018-19 annual plan recognizes movement organizers as “fundamental implementers” and a "core asset” of the free-knowledge movement. Pursuant to that, the plan mandates a study that will take place this year to learn more about organizers' activities and issues. The study hasn't started yet but if you're interested leave a message for MNovotny (WMF) to share your thoughts or offer to participate/be interviewed. —JMatazzoni (WMF) (talk) 18:58, 2 January 2019 (UTC)

"confirmed" users can no longer create articles

Tracked in Phabricator
Task T213003

Hi, in going through some tests, I noticed that the "confirmed" group does not contain the newer permission "createpagemainns", and thus are unable to author new articles the way "autoconfirmed" users are. I think this is an oversight and somewhat related to phab:T204016. Pings to some involved: @MaxSem, Krinkle, and Enterprisey:. Was there prior discussion on this? — xaosflux ^Talk 18:46, 4 January 2019 (UTC)

Likewise on test2wiki, but that is just for a note in case we want to "fix" this. — xaosflux ^Talk 18:49, 4 January 2019 (UTC)

Well that's not good, since that's half the point of the permisssion... Beeblebrox (talk) 22:05, 4 January 2019 (UTC)

@Beeblebrox: yea that's what I was thinking - though I'm not sure how much it really gets used (brand new editors creating non-drafts that is) - it certainly helps with allowing FU Uploads and bypassing CAPTCHA still. — xaosflux ^Talk 22:06, 4 January 2019 (UTC)

It seems like a fine arrangement to me, unless I'm completely wrong (hard as that might be to imagine) in my assumptions regarding why an editor might be confirmed instead of autoconfirmed in the first place.--John Cline (talk) 01:56, 5 January 2019 (UTC)

As I understand it, confirmed is sometimes granted to brand new users at edit-a-thons. –xeno^talk 03:09, 5 January 2019 (UTC)

@John Cline: traditionally confirmed is used by admins (and now also event coordinators) specifically to bypass the auto-confirmation threshold. — xaosflux ^Talk 04:12, 5 January 2019 (UTC)

Ah yes, I had forgotten the outcries related to such events, and the decision (post discussion) to grant "special handling" for mitigating the same.

Comment strayed off topic and is collapsed here.

In that context, the stated inability looms ominously and foreshadows a backlash (I strongly suspect). Since repairing the situation seems likely to follow, I'd like to enter the fray and throw a little food (for thought) of my own. I think Wikipedia could benefit by the preventive protection that the confirmed permission's new array of abilities would offer (as described in this section). I'll bet, for example, that every good faith editor with more than a few years tenure has witnessed the occasional user whose level of competence was even less than autoconfirmed reasonably requires. And our only option in dealing with them is a CIR block. By keeping this, we could replace autocomfirmed with confirmed, sparing them from repeated login requirements (IIRC) and endless CAPTCHA challenges while protecting our work by everything else that it would prevent (I'd even suggest removing file uploading as well). This would also instill the importance of competent conduct from the first moment of being entrusted with an advanced permission and no better time for molding such traits could ever exist otherwise. Although acting on likes such as I suggest here necessitates the creation of an additional user group to allow for the mitigation previously accomplished using the confirmed permission, its doing would be a trivial task, and it could be replaced by confirmed, as well, if ever good cause was found to exist. Perhaps "earlyconfirmed" would be an apt name.

Thank you, happy new year, and best regards.--John Cline (talk) 09:45, 5 January 2019 (UTC)

Good spot xaosflux, hopefully this can be sorted. Richard Nevell (talk) 11:25, 5 January 2019 (UTC)

Seems like an oversight when creating the new perm. While we're here, it looks like confirmed users also don't have transcode-reset, though I don't know when that happened. ~ Amory (u • t • c) 11:43, 5 January 2019 (UTC)

Question: Has anybody let the eventcoordinators (Special:ListUsers/eventcoordinator) know? Or will they be left in the position of standing up in front of a roomful of irritated newcomers on Monday morning? Cabayi (talk) 13:52, 5 January 2019 (UTC)

@Cabayi: I think this has been broken for a little while at least. From what I've seen most new-user edit-a-thons don't direct their participants to create a new article directly in mainspace, though they certainly could. Like Amorymeltzer said, this appears to be a tech oversight, and I'll request a change to enable this (unless someone can point out that it was purposefully chosen to be left out?). — xaosflux ^Talk 14:49, 5 January 2019 (UTC)

Xaosflux, that's a case for withdrawing the ability to create a new article directly in mainspace, but it's a lousy way to treat eventcoordinators, letting them discover a shortfall in their advertised abilities live in front of an audience. Cabayi (talk) 16:34, 5 January 2019 (UTC)

• I've opened phab:T213003 to re-enable this, there will be a short hold in case there are good reasons this should be avoided. @John Cline: if you want to discuss changing the auto-confirmed threshold or creating other levels please start a new section, these can certainly be discussed but is somewhat different from this specific case. — xaosflux ^Talk 15:48, 5 January 2019 (UTC)

  Thank you xaosflux, I appreciate your thoughtful regards. Mine were appended as "food for thought" while slightly qualifying my initial comment where I said that "it seemed like a fine arrangement to me". Seeing that my reply did stray from the topic, I've collapsed its bigger part so as not to distract others. Best regards.--John Cline (talk) 18:49, 5 January 2019 (UTC)

  As I run events quite regularly, it's useful to know that 'confirmed' doesn't currently allow new page creation in mainspace, so thank you, Cabayi, for the notification. Nevertheless, as long as 'confirmed' can move pages from their userspace to mainspace, it won't be a problem, as I almost invariably guide new editors to work in their userspace for their first efforts. Even then, a large majority of new participants will only be updating existing articles after practising in their sandboxes. It's not a fatal problem. --RexxS (talk) 19:59, 5 January 2019 (UTC)

  Thanks for the ping. Good to know. Following on what RexxS said, is a page move really different from a page creation in mainspace? I've always presumed that part of the move from draft to mainspace involved creating a mainspace page and thus subject to the same constraints, no? — Rhododendrites ^talk \\ 20:02, 5 January 2019 (UTC)

  Interesting point, Rhododendrites. Although moves may look like a page creation followed by a delete (when no redirect is left behind), template editors and extended movers can move modules and articles respectively without leaving a redirect, even though they cannot simply delete pages, so I've always believed that the actual process is a little more complex. Also, I've never had any problems with 'confirmed' users moving pages into mainspace, so I assumed that the issue here didn't affect them. Of course, as there is now a new permission, it may have ruined my understanding of how things work. It will be interesting to find out. --RexxS (talk) 20:21, 5 January 2019 (UTC)

  In testing, currently "confirmed" users may MOVE a page in to mainspace - however this acutally appears to be a security bug, as you should not be able to create a page via a move if you can't create it directly. — xaosflux ^Talk 20:51, 5 January 2019 (UTC)

  Yes, but by that logic, I shouldn't be able to delete a module via a move if I can't delete it directly. But I can. --RexxS (talk) 23:14, 5 January 2019 (UTC)

  Just a quick note in counterpoint to RexxS above ("Nevertheless, as long as 'confirmed' can move pages from their userspace to mainspace, it won't be a problem, as I almost invariably guide new editors to work in their userspace for their first efforts") to say that we all take different approaches to training. I encourage the exact opposite. I specifically want editors to get comfortable with mainspace edits and discourage sandbox use at edit-a-thons because it leads to "I'll finish this later," and work never sees the light of day. There's really no reason a new editor shouldn't be able to create and publish a new article to the mainspace, especially with hands-on training and guidance at an edit-a-thon. For many, that's the reason they attend. We shouldn't discourage it. Thanks for the heads up, Cabayi. StaceyEOB (talk) 01:33, 6 January 2019 (UTC)

  Ditto, when running events I'm helping new users create articles directly in mainspace, often from a list of redlinks. I applied for event coordinator status specifically to help brand new users bypass the autoconfirmation requirements, avoid CAPTCHAs, and so forth — under direct supervision of course. —Giantflightlessbirds (talk) 08:46, 6 January 2019 (UTC)

  Point to note: In the Chinese Wikipedia (zh), they create a group called eventparticipant. No comment for other things.--1233^Talk 14:40, 6 January 2019 (UTC)

  I use a mixture of approaches depending on the group, with an eye to the kind of work they'll be doing later, and being able to create in mainspace is a part of that. Thanks for the heads up. Lirazelf (talk) 13:17, 7 January 2019 (UTC)

• Support confirmed rights = autoconfirmed rights I understood that "confirming" a new user was to give them the same rights as autoconfirmed rights. I fail to understand the need for two separate rights here, when the difference is supposed to be one being granted by a bot decision based on time and edit count versus the other being granted by a human. It is a problem if these two very similar terms have different meanings. And yes: users at programs and events need to be confirmed to make new articles. Part of the point of organizing events is to facilitate the experience and pleasure of publishing a Wikipedia article. Blue Rasberry (talk) 14:41, 7 January 2019 (UTC)
• OK, I'm not seeing any reason that this was purposefully broken - appears to just be an oversight in the technical configuration, asking devs to fix it now. — xaosflux ^Talk 14:46, 7 January 2019 (UTC)

Extending wgRateLimitsExcludedIPs to outreachdashboard.wmflabs.org

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

@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)

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)

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

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)

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)

@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)

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)

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)

@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)

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)

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)

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

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)

@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)

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)

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)

• 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)

@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)

@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)

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)

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)

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)

@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)

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

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)

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

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)

@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)

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)

• 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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

FYI: Confirmed users may create articles again

Tracked in Phabricator
Task T213003
Resolved

Hello, just an update that (createpagemainns) access has been restored to manually confirmed accounts, allowing them to create articles directly. — xaosflux ^Talk 01:06, 5 February 2019 (UTC)

Proposal: Bot for outreachdashboard.wmflabs.org creations

Hello, following up on the outreachdashboard discussions above, I'm proposing a new direction for this problem: assigning a bot account to outreachdashboard.wmflabs.org. This account would be used for the "create account" action here on enwiki, alleviating the need to every single coordinator to have to request permissions here. This does mean that the accountability for coordinator assignments would shift to the dashboard team, however we mostly rubber stamp anyone that asks to coordinate an event here today. Eventually, this could allow for future dashboard improvements to also be used to set the temporary +confirmed flag on event attendees. The downside, if someone is abusing the dashboard to create bad accounts the dashboard team would need to deal with it - or we could block the bot (blocking all dashboard based creations). I'm asking for support to at least trial this concept for a few months, and have a dashboard developer that can make code changes to make use of a bot account (something like User:OutreachDashboardBot). Please provide any feedback on this below! Thank you, — xaosflux ^Talk 15:16, 17 January 2019 (UTC)

Pings to some prior participants: @TonyBallioni, Swarm, Theredproject, and Bluerasberry: — xaosflux ^Talk 15:18, 17 January 2019 (UTC)

• I support this concept. Seems like the easiest solution and I’m all about practicality. TonyBallioni (talk) 16:05, 17 January 2019 (UTC)
• Sounds like a sensible step to me. Richard Nevell (talk) 16:10, 17 January 2019 (UTC)
• I support this. I want to confirm that this will be the protocol for all events, regardless of en or other wiki, right? I appreciate the admin and tech effort here. If we can get this to work, it will be a step forward. I would like to see if we can get it working ASAP so we can test it in some of the late Jan/early Feb events **before the March craziness**. Especially because our organizers expect to need to make the ACC/EVC requests in early Feb, and I want to make sure we can direct them the correct way, and direct them only once. --Theredproject (talk) 16:43, 17 January 2019 (UTC)

  @Theredproject: this would apply to any event that coordinates efforts via the outreach dashboard, and we certainly could try to drive future events there. It wouldn't preclude the ability to use the traditional method. — xaosflux ^Talk 16:46, 17 January 2019 (UTC)

  @Theredproject: regarding other projects: enwiki is special in that it is the interface to the outreach dashboard (for better or worse - suppose it could be moved to meta....) if a non-dashboard powered event was taking place outside of enwiki - dealing with that event would continue to stay with the community hosting it. — xaosflux ^Talk 16:48, 17 January 2019 (UTC)

  @Xaosflux: sorry for my poorly worded question: yes, you have confirmed that all was as I expected: all of our organizers regardless of wiki project use Dashboard, and the will all be routed through the en wiki User:OutreachDashboardBot bot user. Sound good! I'm here to help test the changes. And thank you all for working together to come up with this plan. --Theredproject (talk) 04:03, 18 January 2019 (UTC)

• If this approach is approved, I can prioritize implementing it on the Dashboard. The current plan would be to have the bot account be used as a fallback; any user who already has account creator rights who tries to create a new editor's account from the Dashboard would do so with their own account, and other users could still create the accounts themselves if they don't get rate-limited, with the Dashboard automatically using the bot account after a rate-limit failure. This means there would be no change to the user experience from last year, Theredproject, except that we won't need to worry about getting user rights ahead of time, and won't need to worry as much about accounts that got rate-limited because the event organizer didn't have the account creator. We could probably have it ready within about 2 weeks of approval (hopefully less time than that, but I don't want to overpromise).--Sage (Wiki Ed) (talk) 17:35, 18 January 2019 (UTC)

@Sage (Wiki Ed): thanks for the note - since this will be step wise, should be easy to let it fail if the user is blocked/locked (and include the user name in the creation log if it 'falls back') eh? — xaosflux ^Talk 18:11, 18 January 2019 (UTC)

@Xaosflux:: I can look into that... I believe that users who are blocked cannot log in to the Dashboard, and would also automatically get logged out after the first action they take that involves fetching a CSRF token, but I may be mistaken about that. But in any case, we plan to include the username of the user on whose behalf the new account is being created, in the log message so that we can follow the trail in case of abuse, and handling requests from blocked users explicitly shouldn't be hard... I think we'd only try with the bot if the failure happens specifically because of rate-limiting and not some other error.--Sage (Wiki Ed) (talk) 18:18, 18 January 2019 (UTC)

This is really smart: "But in any case, we plan to include the username of the user on whose behalf the new account is being created, in the log message so that we can follow the trail in case of abuse" and should alleviate concerns about abuse, however unlikely that abuse is likely to be. --Theredproject (talk) 16:10, 19 January 2019 (UTC)

@Xaosflux: I looked into it further, and I was wrong about blocked accounts — they can log in still — but we have a ready-to-test implementation that only uses the fallback account for rate-limit failures, so it won't be possible for an editor to create a new account through the Dashboard once they've been blocked on en.wiki.--ragesoss (talk) 00:31, 24 January 2019 (UTC)

• Support this concept. Best, Barkeep49 (talk) 21:12, 18 January 2019 (UTC)
• Support This has been discussed for years at Wikipedia talk:Account creator and more recently at the successor forum Wikipedia talk:Event coordinator. The problem which this seeks to address is that currently, our process for creating Wikimedia user accounts for events requires granting sensitive and dangerous userrights to new users. This new proposed system would instead invest the userright in a bot, and imagines that it would be easier to limit the bot than it would be to limit humans with an account creator/event coordinator userright. The imagined additional security would be tied to the meta:Programs and Events Dashboard, which is a program management system which organizes a team leader to oversee program participants. If I understand correctly, the security that the dashboard provides is that if newly created program participant accounts cause problems, then through the dashboard we have a way to identify responsibility in the associated team leader for those accounts and that program. There is no such formal coordination in the MediaWiki platform, but it is helpful to take the coordination of this dashboard which is on WMFLabs/Wikipedia:Wikimedia Cloud Services. The potential drawback that I see to this is that WMF has a major software development investment in a competing product to the dashboard described at 2017 Wishlist, the Grants metrics tool and meta:Community Tech/Event Metrics which were all in development in 2017-18, and may have a future. The social context of this is that WMF might want users in their own tools rather than the Wiki Ed's dashboard. However, the Wiki Ed dashboard has had perhaps 30-40,000 users with maybe 10% of those being repeat users over the past few years. The WMF tools are currently not popular and might not work. I am in favor of building out functionality of the dashboard in this proposal, but there might be some social bumps here due to the competition. If there is any pause in committing to a schedule to build in functionality, then I strongly favor giving the required user rights to humans, until and unless anyone publicly talks through an alternative proposal. Doing wiki outreach is not a crime and it currently requires giving user rights to humans! Blue Rasberry (talk) 16:54, 19 January 2019 (UTC)
• Support This sounds great! Shameran81 (talk) 19:28, 21 January 2019 (UTC)

@Xaosflux: I'm wondering how long you want to keep this discussion open, as it seems that there is unanimous support for the proposal, and all protagonists have spoken except for @Swarm:. (Swarm, it would be great if you could weigh in here.) We are getting organizers asking us about ACC/EVC permissions. I'm concerned about time, as we are 5 weeks from March, and @Sage (Wiki Ed): said that he needs 2 weeks to code this, which leaves us with only 3 weeks before we have 300+ events (and we will need to test and debug!) It would be great if we could bring this discussion to a consensus, so we could at the very least let our organizers know what the plan is. THANKS!! --Theredproject (talk) 19:18, 23 January 2019 (UTC)

• I'm in full support of this as well.  ~~Swarm~~  {talk}  20:47, 23 January 2019 (UTC)

BRFA filed

Hello everyone, I've filed the BRFA here: Wikipedia:Bots/Requests for approval/OutreachDashboardBot. — xaosflux ^Talk 02:41, 24 January 2019 (UTC)

@Theredproject and Bluerasberry: the BRFA was approved and this process is live now. Can someone go through the workflow an ensure that an event coordinator can access the "create accounts" process on the dashboard for requested accounts within the AF program? — xaosflux ^Talk 22:41, 29 January 2019 (UTC)

@Sage (Wiki Ed) and Xaosflux: I set up an instance of the dashboard and looked for any new option to create accounts. I failed to identify any difference. Can someone share some guidance on how I access the new workflow? Blue Rasberry (talk) 16:13, 30 January 2019 (UTC)

@Bluerasberry: the 'new' components are automatic and don't require any change on the coordinators side. When I was experimenting I was a bit lost though, and it looked like processing of 'account requests" had to be done at the 'program' level, instead of the 'event' level - is that correct (and if so is it already part of the process?). — xaosflux ^Talk 16:16, 30 January 2019 (UTC)

@Xaosflux: Okay, now I see a difference. There are "programs and events", which are single things, and "campaigns", which are series. I found a difference but I still fail to see how to operate it.

• 
  start here
• 
  navigate here
• 
  I fail to see how to create accounts here

Blue Rasberry (talk) 16:57, 30 January 2019 (UTC)

@Bluerasberry and Xaosflux: account requests need to be enabled on an individual event for the interface to show up. They are enabled by default for any new Art + Feminism 2019 event, if it was created starting from the A+F campaign page; otherwise, the facilitators for the event can enable account requests via a button in the 'Actions' sections. After that, if there are any pending requests for that event, a link to them shows up in the Actions section, and a link to all the pending requests for an entire campaign will show up on the campaign page, for admins and campaign organizers. This workflow hasn't changed; the only difference is the fallback for rate-limited attempts. --Sage (Wiki Ed) (talk) 17:03, 30 January 2019 (UTC)

Adding @Siankevans, Amandameeks, and MarieInternette: who I believe are going to be working on writing up some documentation. I will be holding a training in NYC on Monday, and will test the process if I need to make any accounts.--Theredproject (talk) 01:54, 3 February 2019 (UTC)

Facilitator account creation walk through

@Theredproject, Siankevans, Amandameeks, MarieInternette, and Bluerasberry:

Not my best tech writing, but someone may be able to work off of this. Here is the walk-though I just did of having a facilitator create an A+F program under the master campaign, and process account requests:

1. Went to the campaing (https://outreachdashboard.wmflabs.org/campaigns/artfeminism_2019/overview)
2. Click on "Create Program+"
3. Filled in the details, my example output:
   1. [3]
4. Had a participant go to the new program page and request an account (used: z_xaosflux_29)
   1. They see: "Your request for an account has been submitted. The Facilitator for this program can finalize your account creation now. Once it is created, you'll get a password for the new account by email."
5. As the facilitator, went to the "Editors" page of the program (e.g. [4]
6. Click on Add/Remove Editors
   1. This created a popout, in the popout click on Requested accounts
7. Click on Create these accounts
   1. My output: success=>"Created account for z_xaosflux_29 ..........

Worked. @Sage (Wiki Ed): its a bit easy for the facilitator to get lost looking for the 'create new accounts' - a suggested dashboard improvement would be to show them a big "Requested accounts-->" button on the program page, much like the one that campaign managers see on the campaign page. — xaosflux ^Talk 02:47, 3 February 2019 (UTC)

I tried to follow these steps, sort of. I found that

• When I went to the MoMA event student page and clicked "create an account" button, my new account was actually created. ("Created account for TheredprojectDemo on wiki.riteme.site")
• When I logged in with my new User:TheredprojectDemo and went to the MoMA event student page I did not see the "create an account" button, as an option. (I think this is intentional, and I think this is correct).
• When I added my new User:TheredprojectDemo as a Facilitator, then logged in with that user and went to the MoMA event student page I saw the "create an account" button, as an option, and tried to use it:
  • First time I got this error (I was never shown a captcha) "There was an error: Could not create account for TheredprojectDemo9999 / TheredprojectDemo9999@gmail.com. https://wiki.riteme.site response: {"createaccount"=>{"status"=>"FAIL", "message"=>"Incorrect or missing CAPTCHA.", "messagecode"=>"captcha-createaccount-fail"}}"
  • I tried again and got the same error, using a different email There was an error: Could not create account for TheredprojectDemo49y07 / Michael+343545@mandiberg.com. https://wiki.riteme.site response: {"createaccount"=>{"status"=>"FAIL", "message"=>"Incorrect or missing CAPTCHA.", "messagecode"=>"captcha-createaccount-fail"}}
  • I replicated this error for the third time... Not sure what else to do here. Sage, please direct me if you would like me to try something else diagnostic --Theredproject (talk) 16:01, 3 February 2019 (UTC)

N.B.: There are 16 'requested accounts' in the A+F campaign pending administrative action right now (not sure what program they came from). — xaosflux ^Talk 02:47, 3 February 2019 (UTC)

@Sage (Wiki Ed): were these from before or after the shift to User:DashbordBot? notes:

• I tried to approve these from my new User:TheredprojectDemo and was told "You are not authorized to execute this request. If you believe you have reached this notice in error, please contact the maintainers of this dashboard to let them know about the problem."
• After I made my new User:TheredprojectDemo a facilitator I tried to approve these again and was given the same error
• I asked @FailedProjects: who has EVC, to visit the requested_accounts_campaigns link, and they also got this error.

Which says to me that you need to be a Dashboard Admin to access this page. I'm not going to immediately approve these, until we finish debugging this. --Theredproject (talk) 16:01, 3 February 2019 (UTC)

• @Theredproject, Ragesoss, and Sage (Wiki Ed): I think what you've run in to is just some UI problems, some buttons don't appear places they should, for example use a private browser or logg off and go to: the student page and you can't request an account, same at the home page but if you go to the base url: https://outreachdashboard.wmflabs.org/courses/MoMA/MoMA_ArtAndFeminism_2019 you can. Perhaps the 'module enroll' box can be shown on ALL pages if current user != a logged in user? — xaosflux ^Talk 16:18, 3 February 2019 (UTC)

Theredproject: Those requests were all older ones, except for the most recent one before your tests. I just cleared out the old ones and your tests, and created the one recent one (from yesterday). The permission structure is the same as before, so if you are the facilitator of an individual program, you should be able to access and create the requested accounts for that program (via a link in the 'Actions' section), while you must be an admin or an organizer of the campaign to view or create the ones for the whole campaign.

The CAPTCHA error is something we might need to tweak the code to account for. I'm guessing it will affect all accounts that aren't autoconfirmed, because they get CAPTCHAs when they try to create an account (separately from the IP limit), and the fallback currently only works in the case of rate-limit failure. I'll make an update as soon as I can.--Sage (Wiki Ed) (talk) 16:19, 3 February 2019 (UTC)

I'm guessing they aren't even getting the option to actually complete the captcha in this case - adding captcha fail fall back to the service account doesn't seem to risky if that is so? — xaosflux ^Talk 16:22, 3 February 2019 (UTC)

That's right. We don't handle CAPTCHA challenges of any sort for dashboard actions, so they just fail immediately. I've just deployed a change to enable the bot to create the account in case of `captcha-createaccount-fail`.

As for the UI issues, I'm open to ideas for handling it better, but those differences you describe are intentional except for the `home` vs base url case. The idea is that there are two modes of using the account creation feature:

1. As a user without an account, I can request one, and that UI shows up when I visit the enroll link, or if there is no passcode set, if I just visit the base URL. (The `/home` version ought to behave the same way; I'll file an issue.) This request goes into the queue, and someone needs to take action to create it.
2. As an organizer, I can create an account for someone else. (This is based around the A+F workflow of sending people without accounts to a dedicated person who will get them set up with an account.) This is what happens if you're logged in and you start from the 'students' tab: the account should be created immediately, and only goes to the queue if the account creation attempt failed.

--Sage (Wiki Ed) (talk) 16:43, 3 February 2019 (UTC)

@Xaosflux: I just deployed a fix for the `/home` vs base URL inconsistency.--Sage (Wiki Ed) (talk) 17:06, 3 February 2019 (UTC)

Thank you, @Theredproject: does this fix your workflow problem? — xaosflux ^Talk 17:30, 3 February 2019 (UTC)

I now see a "request account" link when I'm a brand new user at the Dashboard page for MoMA event. So that is good. When I follow that process, I get this response "Your request for an account has been submitted. The Facilitator for this program can finalize your account creation now. Once it is created, you'll get a password for the new account by email." and I see that request on the requested_accounts_campaigns. (I just deleted it). So that part seems clear:

New User:

1. Goes to Dashboard Program landing Page
2. Requests Account
3. A Dashboard Administrator goes to the Requested Accounts page and approves that account
4. They are automagically added to the Dashboard Program
5. They get password in their email

For the other workflow, I can confirm that I could create account and didn't have the CAPTCHA problem, and got the response "Created account for TheredprojectDemo49y0723432 on https://wiki.riteme.site." Workflow:

Event Organizer (regardless of EVC permissions):

1. Goes to Dashboard Editors page
2. Event Organizer clicks Create Account
   1. Participant types in their username and email and clicks "Check Username Availability"
   2. If username is available, participant clicks "Request Account"
3. The account is created by Dashboard
4. They are automagically added to the Dashboard Program
5. They get password in their email

My main concern here is that a significant percentage of the the account request by New Users (first workflow) will require approval by a Dashboard Administrator. I checked this, by adding my test account to the Campaign as an Organizer, and that still wouldn't let me access the Requested Accounts page. That means it that there are only two people on the campaign who could do this, myself and @Masssly:. Which seems like it will inevitably result in a bottleneck, like the 16 accounts that built up just now. --Theredproject (talk) 19:51, 3 February 2019 (UTC)

example of a facilitator approval page

@Theredproject: this does not require a 'dashboard admin', only a 'program facilitator', however where they click is in a different location. See image to the right and my original directions way up above. — xaosflux ^Talk 21:13, 3 February 2019 (UTC)

Like this: From the program: Click on Editors, Click on Add/Remove Editors, Click on Requested Accounts. I left one fake request in there if you want to see it. Also made my alt (xaosflux_ep) a facilitator for testing. — xaosflux ^Talk 21:14, 3 February 2019 (UTC)

Okay, I can confirm that this worked for me. I didn't see that link previously. So workflow is

New User:

1. Goes to Dashboard Program landing Page
2. Requests Account
3. A Campaign Organizer
   1. Clicks on "Add/Remove Editors"
   2. Then Clicks on "Requested Accounts"
   3. approves that account
4. They are automagically added to the Dashboard Program
5. They get password in their email

@Sage (Wiki Ed): is there any way that the link to this approval could be less UX/UI steps for the organizers? Could a "Requested Accounts" tab show up on the top of the Nave (in Red?) to the right of "Home, Editors, Articles, Uploads, Activity"? Or something like that? I think that Xaos suggested this above, but restating here for emphasis. --Theredproject (talk) 16:13, 4 February 2019 (UTC)

@Theredproject: in you steps right above on #3: "Dashboard Administrator" should read "Program Facilitator". — xaosflux ^Talk 17:53, 4 February 2019 (UTC)

@Theredproject: thank you for catching that. I just went in and changed it.--Theredproject (talk) 17:58, 4 February 2019 (UTC)

@Theredproject and Xaosflux: Wes just updated the UI so that it shows as an alert banner now when there are requested accounts pending approval; these should show up automatically (even without refreshing the page, with updates every minute just like the course stats) for a program facilitator who has the program page open.--Sage (Wiki Ed) (talk) 00:22, 5 February 2019 (UTC)

@Sage (Wiki Ed), Xaosflux, and Wes (Wiki Ed): Thanks for this effort. I am in the middle of a training, and am using this as a talk page demo! I just tested on the training program and don't see the banner. I see it in the requested accounts. Maybe the code has not propagated? --Theredproject (talk) 01:05, 5 February 2019 (UTC)

@Theredproject: I don't see either (tested with a non dashboard admin that I made temporary facilitator as well) - can still add accounts using the procedure above though. — xaosflux ^Talk 01:11, 5 February 2019 (UTC)

@Theredproject and Xaosflux: If you created an account request (without immediately creating it, as you do via the 'Add/Remove Editors' button), then there ought to have been a banner on the course page when you visit it as an admin/facilitator. This worked when I tested it. If you were already on the page before the deployment and didn't refresh, you would have gotten the old behavior; that's the only reason I can think of that would have stopped you from seeing the new UI for a pending account request.--Sage (Wiki Ed) (talk) 17:13, 9 February 2019 (UTC)

@Sage (Wiki Ed): I just tried again, and it isn't any different. I got the green banner saying "Your request for an account has been submitted. The Facilitator for this program can finalize your account creation now. Once it is created, you'll get a password for the new account by email." but no banner on my main account (admin), or my demo account (facilitator).--Theredproject (talk) 01:27, 10 February 2019 (UTC)

@Theredproject and Xaosflux: Bug found and fixed; should be working as intended now (and Theredproject just tested it succesfully).--Sage (Wiki Ed) (talk) 16:54, 10 February 2019 (UTC)

Works! --Theredproject (talk) 16:58, 10 February 2019 (UTC)

Semi-protected edit request on 25 February 2019

I would love to be a Wikipedia Admin, I'm active every day and I love to edit,I edit every day and I hate edit wars I try to stop vandalizing and protect pages! Thanks! Scribbley (talk) 20:23, 25 February 2019 (UTC)

 Not done: there is a big difference between being an account creator, which is the page you asked to edit, and being an admin. If you truly want to be an admin, despite only having 6 edits, please read WP:NOTNOW. Thanks, -- DannyS712 (talk) 20:26, 25 February 2019 (UTC)

Reminder - Outreach Dashboard

Hello all! Just a reminder (mostly related to event coordinator / account creator requests) - if an event is using the Program and Events Dashboard - access groups are no longer required to create accounts even in excess of the normal throttle limit, these are exempted. Coordinators using the dashboard would only need an EVC flag if they will be manually confirming attendees. I don't think a lot of coordinators know this, perhaps we can update the intake to notify them better? If we are still getting lots of needs for +confirmed, we may be able to work with the dashboard dev's to add that functionality in the future. — xaosflux ^Talk 16:12, 5 March 2019 (UTC)

lost pass for old account

User:Unacceptable67 was the alt. I have a lot of editing to do, and some photos to upload. Would greatly appreciate permission to continue as already been verified long ago. --Acceptable67 (talk) 15:50, 24 March 2019 (UTC)

@Acceptable67:, hello. That other account had no advanced permissions configured, your new account will become auto-confirmed after 4 days and 10 edits. — xaosflux ^Talk 17:17, 24 March 2019 (UTC)

Temporary access for an event

Looking back at Wikipedia talk:Requests for permissions/Archive 9 #Temporary grants, I see there's general agreement that the permission may be granted temporarily as a trial period. I'd like to gather opinions on whether it would be acceptable to grant the permission for the duration of a single event.

On May 7, Wikimedia UK is holding the second of its series of "skillshare" events, aimed at encouraging "long-time Wikipedia editors and those interested in becoming technically proficient at more complex tasks to gain skills that will allow them to improve Wikimedia projects", on the topic of using AWB. There's a blog post introducing the event at https://blog.wikimedia.org.uk/2019/04/autowikibrowser-find-out-how-to-automate-mass-edits-on-wikipedia/ so we may get a number of requests individually from interested editors who are going to participate. The other option would be to add the participants as a whole to the check page solely for the duration of the event and ensure that they are removed immediately after its conclusion. Naturally, those more interested can make a request for a more permanent grant of the right in the usual way in any case.

The advantage that I can see would be to to introduce AWB to more editors who may be able to use it productively. The disadvantage is the possibility that participants at the event may run amok and cause chaos. I personally think the latter to be extremely unlikely, but that's just my opinion, of course. What do others think? --RexxS (talk) 13:42, 19 April 2019 (UTC)

@RexxS: we're generally pretty permissive when it comes to training - so I'm not too worried about some temporary grants here - and it looks like this event is geared towards editors that should be able to qualify for access anyway. My bigger concerns are that the event may only focus on the technical aspects and skip over things that could get the editors in to drama like COSMETICBOT or the other parts of the usage guidelines at Wikipedia:AutoWikiBrowser/CheckPage#Guide that we ask people to read before placing a PERM request. — xaosflux ^Talk 14:10, 19 April 2019 (UTC)

Thanks, Xaosflux. The event is being led by Rich Farmbrough, who is probably as aware as anyone of the dangers of not adhering to the usage guidelines. I'll certainly recommend to him that he stresses those aspects in his presentation. Hopefully this sort of training will generate some documentation on what needs to be covered and what works well, so that it can be used and developed by others in future. --RexxS (talk) 14:23, 19 April 2019 (UTC)

I have given considerable thought to this aspect. All the best: Rich Farmbrough, 14:30, 19 April 2019 (UTC).

May 2019

In the description of 'New page reviewer', the words 'page curation hoverbar' are linked to WP:Page Curation, which has a notice at the top saying it's been superseded by WP:Page Curation/Help. Neither of those pages refers to a 'hoverbar'. Could the link be updated, and 'page curation hoverbar' be changed to 'curation toolbar' or another more appropriate phrase? Thanks, BlackcurrantTea (talk) 14:14, 14 May 2019 (UTC)

 Done. I think I got the link and the name of the tool correct. If not, trout me gently. – Jonesey95 (talk) 14:50, 14 May 2019 (UTC)

No trout needed. Thanks! BlackcurrantTea (talk) 16:15, 14 May 2019 (UTC)

Protection level

Aside to the above request, @Xaosflux: Why is this template editor-protected? The intent in the protection policy is clearly that only pages widely-transcluded be template-editor protected. --Izno (talk) 14:28, 14 May 2019 (UTC)

I also don't really see justification in the edit history for the high level of protection anyway, whether template editor or the previous full protection. There was some routine vandalism way-back when, but otherwise? --Izno (talk) 14:31, 14 May 2019 (UTC)

@Izno: while I was the last protector, it was in reducing the prior full-protection to make it more accessible. That was years ago, and reducing this to ECP should be fine now - thoughts? — xaosflux ^Talk 16:07, 14 May 2019 (UTC)

@Xaosflux: ECP would be fine with me, but given the kind of vandalism that occurred, would it be reasonable to try semi first? We can leave move-protection at full either way--I don't think this page needs to go anywhere. --Izno (talk) 16:57, 14 May 2019 (UTC)

@Izno: I've lowered to ECP - main reason is to avoid having a "edit" button where newer users may end up trying to put requests here instead of in the appropriate sub pages. If more seasoned editors screw it up we've got a bucket of trout for them! — xaosflux ^Talk 17:12, 14 May 2019 (UTC)

Yeah, that was the other thing. ECP is reasonable. --Izno (talk) 17:41, 14 May 2019 (UTC)

Yup. New editors are very likey to put requests there. I think we should stick with ECP, for eternity. —usernamekiran(talk) 21:52, 14 May 2019 (UTC)

Semi-protected edit request on 16 May 2019

Wikipedia is a large online encyclopedia and deserves nothing but the best of human resources and excellent interaction within the community. I want to use my knowledge to help make Wikipedia the best online mass message sender to all her clients all over the nations. Thank you. JassenJapheth (talk) 07:18, 16 May 2019 (UTC)

@Xaosflux and Mz7: since you recently processed a request at PERM/MMS, please take a look at this. --Izno (talk) 13:29, 16 May 2019 (UTC)

 Not done @JassenJapheth: to request a mass message, please use Wikipedia:Mass_message_senders#Requesting_a_mailing. Should you find that you are regularly having your requests approved, you can apply to self-service them at the page you linked to above. — xaosflux ^Talk 13:41, 16 May 2019 (UTC)

Semi-protected edit request on 24 May 2019

I would want access to fix typos faster, thank you! Can you escape (talk) 10:44, 24 May 2019 (UTC)

@Can you escape: As this is your first post on the English Wikipedia I'm guessing you're trying to use AutoWikiBrowser on the Romanian Wikipedia. You'll need to ask the people over at the Romanian Wikipedia for assistance with that. Regards, – Þjarkur (talk) 10:54, 24 May 2019 (UTC)

Semi-protected edit request on 26 May 2019

Nasrullah Shahnawaz (talk) 05:33, 26 May 2019 (UTC)

This page is not for requesting user rights. Kudpung กุดผึ้ง (talk) 05:52, 26 May 2019 (UTC)

Announcement: enhanced patrol/AFC acceptance logs

See Special:Permanentlink/899358779#Announcement:_enhanced_patrol/AFC_acceptance_logs. Please comment there. MER-C 14:54, 29 May 2019 (UTC)

Requested change to MusikBot's operation

Please see User_talk:MusikAnimal#I_forgot_to_ask_ages_ago... and provide input. -- Amanda (aka DQ) 08:34, 5 June 2019 (UTC)

Wikipedia:ASDA listed at Redirects for discussion

An editor has asked for a discussion to address the redirect Wikipedia:ASDA. Please participate in the redirect discussion if you wish to do so. Headbomb {t · c · p · b} 08:52, 18 June 2019 (UTC)

An editor has asked for a discussion to address the redirect Wikipedia:WALMART. Please participate in the redirect discussion if you wish to do so. — xaosflux ^Talk 13:43, 18 June 2019 (UTC)

T230304 and account creation being blocked

Tracked in Phabricator
Task T230304

Tracked in Phabricator
Task T230521
Resolved

• @Martin Urbanec: do you have any more information about phab:T230304? Did I miss where this very restrictive change was being communicated to projects? — xaosflux ^Talk 03:33, 15 August 2019 (UTC)
  • Set account create throttle to 2 everywhere as noted in: https://phabricator.wikimedia.org/rOMWCcc631f226ded0656253eb25bc9dd4d8937019b5c — xaosflux ^Talk 03:34, 15 August 2019 (UTC)
    • Hello, yes, I do know more, but since the task has restricted visibility, I'm not allowed to say much - the task is available to me under an NDA. The mentioned restriction was indeed implemented by me, and I decided to implement it as an immediate response to a security incident. The restriction is under constant review, and will be removed as soon as possible. Best regards, --Martin Urbanec (talk) 07:35, 15 August 2019 (UTC)
• phab:T230521 opened to try to get an explanation of what is going on. — xaosflux ^Talk 03:54, 15 August 2019 (UTC)
  • I'm going to comment on that task as well, but I doubt you'd get more information than I wrote above - as said, the information is available only to people who signed an NDA, and as such, can't reveal it to anyone. Best, --Martin Urbanec (talk) 07:35, 15 August 2019 (UTC)

  @Sage (Wiki Ed): we may have an uptick in activity for OutreachDashboardBot while this is going on, mostly just FYI in case you see anything odd at the outreach dashboard. — xaosflux ^Talk 04:06, 15 August 2019 (UTC)

  Pinging @AntiCompositeNumber: since ACN initially brought the Phabricator ticket everyone's attention on the WP:ACC mailing list, I'm hoping that you might be able to provide a little more insight into what's going on. OhKayeSierra (talk) 05:25, 15 August 2019 (UTC)

  I'll just leave this here. --AntiCompositeNumber (talk) 12:00, 15 August 2019 (UTC)

• FYI: phab:T230521 was closed after reverting the restriction. Back to 6/day/user. — xaosflux ^Talk 17:18, 15 August 2019 (UTC)

Correct place to request removal of permissions

Spurred by a post elsewhere (WT:AWB), I came here to see if this was the correct place to request removal of permissions. Whether it is or isn't, it would be nice if there was something which indicated what steps to take (which I think is, 'ask uninvolved admin' and then escalate as appropriate? or leave a request on this page first? or ANI first?). --Izno (talk) 13:43, 16 August 2019 (UTC)

@Izno: I'd be fine adding a Wikipedia:Requests for permissions/Removals or the like subpage here - I think we normally send people to WP:AN (well if an admin sees it in the 'wrong' spot here we just do it here as well - but its sloppy). — xaosflux ^Talk 15:07, 16 August 2019 (UTC)

Normally such requests are posted on WP:AN, and are not so common that Yet Another Noticeboard would be necessary. Jo-Jo Eumerus (talk, contributions) 15:52, 16 August 2019 (UTC)

Yeah, I tend toward Jo-Jo's position here. And besides, if an admin is being requested to remove permissions, that implicates some wrongdoing, so AN(I) or one of the others (e.g. possibly ANEW for rollback edit warring) is probably a better spot to make sure it is resolved. --Izno (talk) 16:16, 16 August 2019 (UTC)

• I dont remember where I read it, but in case if you want your own permissions revoked, the guideline says to ask any admin on their talkpage, or your talkpage. I think {{admin help}} can be utilised in that case. Maybe we should add it in header of RFR mainpage: "Use {{admin help}} in case you want your special permission(s) revoked". In case of other user's, then AN or ANI is the place, depending on circumstances. Given the rare instances of users requested their perms to be revoked, i dont think a special subpage is required. Even in case of disputes, ANI would be preferable as there would be participation from uninvolved, as well as from the editors who are familiar with the accused. —usernamekiran(talk) 16:28, 16 August 2019 (UTC)
• I think creating Wikipedia:Requests for permissions/Removals would be a bad idea and incentive for remove-my-patroller-right, I won't patrol for a week / restore-my-patroller-right I am now active cycles. Even the removal requests I see at AN or elsewhere, many, if not all are pretty pointless. We shouldn't encourage pointless activity. – Ammarpad (talk) 16:40, 16 August 2019 (UTC)

  I'm less interested in the "I want to remove my own permissions" concern and more the "I think this other editor's permissions should be removed" concern. --Izno (talk) 17:35, 16 August 2019 (UTC)

  And creating the proposed subpage will only encourage that. As you said above, if an editor is problematic enough to merit rights removal, then AN/I is the best place for that as there are really more things to discuss not only the right. – Ammarpad (talk) 18:01, 16 August 2019 (UTC)

• From above, looks like we should continue just referring requests to WP:AN (Perhaps slightly improve the directions at Wikipedia:Requests_for_permissions/Header#Removal_of_permissions if they are not clear). — xaosflux ^Talk 18:10, 16 August 2019 (UTC)

  The section can be moved inside the top header, but it has to be shortened actually. That extra note is not needed in my view. – Ammarpad (talk) 18:18, 16 August 2019 (UTC)

  Oh! That section already exists. I guess then my issue is that I didn't know it was so because there is no mention in the top header and there is no TOC for the page. Just add a mention and section link to the top header e.g. "For requests to remove a permission, read [[#This section]]." I might even prefer the table of contents to that; what reason could there be not to have a TOC? --Izno (talk) 18:30, 16 August 2019 (UTC)

  @Izno: I think it is just where the TOC is? Look to the right of this? — xaosflux ^Talk 18:40, 16 August 2019 (UTC)

  Yap, that's where it is right now. Good catch. Let me go see what the best way is to move that, since it's all transclusions all the way down. --Izno (talk) 19:18, 16 August 2019 (UTC)

  We might reasonably use horizontal toc, but I'm just as happy with a right float. --Izno (talk) 19:29, 16 August 2019 (UTC)

Threshold

How was the figure "25 new articles" reached as a threshold for granting autopatrolled? I think that's a fairly high threshold, for example I have about 20 and there's no real issue that should keep me from receiving this feature, apart from this seemingly arbitrary number. ♟♙ (talk) 20:42, 12 September 2019 (UTC)

@EnPassant: this page isn't the guideline, just a note of what the guideline is. You can suggest changes to that guideline at Wikipedia talk:Autopatrolled. — xaosflux ^Talk 23:20, 12 September 2019 (UTC)