Wikipedia talk:Account creator

My wish - the example case

There have been several conversations here lately and in the past. I see two recurring perspectives raised, which I will call "security" and "event organizers". People who are interested depend on the enforcement of a set of rules to ensure that some security goals are met. "Event organizers" wish to host Wiki outreach events, and encounter the barrier that any event which registers more than 6 new users will be stopped by security measures.

I wish to present an example situation which describes the typical sort of event in wiki outreach. I wish that there could be some kind of middleground or mutual understanding between the security side and event organizer side.

---

Sample event - meetup in the community center of a public library

A librarian is interested in presenting a Wikipedia event. This person has edited Wikipedia 1 time, so while they have an account, they are a new user, and in the current system cannot make a successful bid for account creator rights. Still, they hear of an outreach program, like Art+Feminism or Wikipedia:Year of Science or the WP:Education program and they wish to give it a try. They advertise an event expecting about 15 attendees. The intent is that at the event, over a two-hour period, attendees will register a Wikipedia account and add a sentence and citation to a Wikipedia article.

Under the present security practice

The first six attendees at the event will be able to register Wikipedia accounts. All attendees after that will be unable to register. Attendees who come to edit Wikipedia but find themselves unable to register an account. The event will be sad because some attendees cannot participate on-wiki.

What event organizers desire

There is some reasonable method endorsed by event organizers which allows the librarian to provide accounts to their guests. Everyone present at this event is able to register an account.

---

Event organizations think, but security enthusiasts doubt...'

1. There is no great risk for a librarian to organize an event for 15 people in a library. "Account creator" rights, or some way for event organizers to provide accounts to new users, should be easy to get.
2. There is no particular relationship between being an event organizer and being a wiki editor. Being a wiki editor should not be a requirement of event organizers.
3. Security needs are uncertain and not defined. There is respect for security, but it is not easy to understand why a professional event coordinator working for a library should be restricted from making wiki accounts. Surely this is some mistake.

Security enthusiasts think, but event organizers doubt...'

1. Anyone without an established relationship to wiki projects is too much of a security liability to have "account creator" rights.
2. It is risky for there to be an event without experienced Wiki people closely involved.
3. The current system is working. People who want to host events manage to get account creator rights to to the right people.
4. Anything that lowers the current level of security should be off-topic for discussion.
5. It is okay for the level of wiki-security to be decided without input from event organizers. The event organizers can find a way to both have their event and follow the rules.

My request for now

1. If someone is putting time into a solution to develop account creator tools, please confirm that tool offerings will apply in the above example
2. If someone feels that the example event in the library should not be allowed to happen as described above, could someone speak up and say so to advance the conversation?

Right now, I am advocating for events in libraries. I would like to do that in a way that preserves security. If events in libraries cannot happen by the current rules, then I wish I could understand the security threat, and to the extent of my understanding of that threat I wish to advocate for the rules to change to permit these sorts of events. Blue Rasberry (talk) 23:29, 17 January 2017 (UTC)

@Bluerasberry: A question I have for you before replying to you more generally: Why do you say that "being a wiki editor should not be a requirement of event organizers"? This seems almost oxymoronic to me, very much "the blind leading the blind". Surely it's reasonable to expect someone organizing an editing event on Wikipedia to have at least some basic experience with Wikipedia? Saying that being a wiki editor should not be a requirement of event organizers is almost as absurd to me as saying someone teaching a driver's education course should not be required to possess a driver's license themselves or have actually ever driven a vehicle themselves. In what practical situation can someone who has had zero editing experience with Wikipedia be expected to effectively lead an organized Wikipedia-related event? I think most people would agree that before introducing others to some thing, the person doing the introducing should have some experience with that thing first. --FastLizard4 (talk•contribs) 11:48, 18 January 2017 (UTC)

Hey @Bluerasberry:

Firstly, let me clarify that your "security" perspective is for the most part inaccurately represented (in my opinion) by your wording here. Those of us concerned about security are not interested in enforcing a set of rules as much as we are interested in attempting to prevent known abusive users from continuing to abuse. Sockpuppetry is a real problem on Wikipedia, and some sockpuppets and sockmasters can go undetected for a long time, causing all sorts of long-lasting damage.

The methods we have of combatting this abuse themselves fall along a trade-off between really effective at combatting the abuse while really intrusive to legitimate users, all the way down to being transparent and non-intrusive while also being completely ineffective. We, as the entire Wikimedia community, have the ability to customise how intrusive and effective we want the anti-abuse measures to be, and at the moment I feel they are striking a decent balance between the two extremes.

Looking to your sample event, it takes a very naive and innocent view on how things could run. Let's look at it from both a legitimate user and a malicious user perspective.. Our brand new librarian user who wants to run an event asks for these account creator rights. They say they're a librarian wanting to run an event, not knowing anything about Wikipedia's standard practice, and (let's say) they are granted the right, and the event proceeds as normal. Later that day, another user comes along, says they are a librarian wanting to run an event, is granted the right, and proceeds to create 100 sockpuppet accounts and cause a significant amount of damage. How do you tell these two users apart in such a way before they're given the permissions needed to do a lot of damage?

Let me also go through your points about what you assume people think:

1. You are correct that a librarian organising an event for 15 people is low risk, and I personally don't have a problem granting a librarian or other event organiser the ability to bypass the account creation ratelimit, and I doubt anyone would if we knew it was the event organiser and not an imposter (yes, this has happened).
2. It's also not a security concern that there is no relationship between an event organiser and an experienced user. This is much more one of knowledge - how do you expect a librarian to know what makes an article pass the general notability criteria (or even that it exists and where to find it)? This, and other policies/guidelines/etc, will only be known by an experienced user. The concern that will be raised is one more of the blind leading the blind, as FastLizard4 has said. This is something which I don't feel is appropriate to discuss here though, in a discussion about user rights and security. If librarians think that they know enough about Wikipedia editing and policies to be able to guide others after only making a single edit, then they have either spent a fair amount of time reading the Wikipedia namespace, or are kidding themselves. This is as much the fault of Wikipedia for the huge amount of policy we somehow generate as it is the fault of the event organiser for assuming they know much more than they probably do.
3. The security needs are definitely known and certain, there is no mistake here. As I've mentioned above, the issue is one of implementing the needs versus their side effects, not one of defining them. I think that if we can provide a way, such as the extention to the ACC tool proposed by Xaosflux above (and which I've started implementing), for event organisers to have a trusted way of creating accounts for attendees, with a small amount of verification from the event organiser (let's say if they're a librarian, email the ACC team from their library email address). If it can be made simple enough then I see no reason this specific case would be blocking any more.

...and from the security perspective...

1. As the account creator group currently exists and is used, yes, I agree with this.
2. As mentioned, not a security concern at all.
3. No, it's not working. This is evidenced by this discussion, and many discussions in the past. This right, and the ACC tool, have never been intended for use by event organisers - the right was added for the ACC tool originally, and intended to be used by experienced users with knowledge of when to apply the extra rights bundled with the no ratelimiting. Usage by event organisers (and editnotice editors !!) has been a secondary usage of the rights provided, despite being non-ideal. So far (with the exception of Xaosflux), everyone (that I've seen) has pushed problems without offering any reasonable suggestions for solutions that improve the current situation, rather than improving slightly in one area and degrading a lot in another.
4. Not off-topic per se, but anything that lowers the current levels security should be well-thought and considered given the extra workload and likely extra damage it will give. Solutions that lower the security without having a plan to deal with this are not complete solutions.
5. This is also wrong, but I understand where this is coming from. It should be, and is, the community as a whole who should be deciding this. Unfortunately, it seems a lot of event organisers don't even know the community exists, and thus aren't able to give their input. This is another way that if event organisers were more involved in the community, things would be better all-round. As a community, we should be taking this into account, but the balancing act I mentioned above is a very hard one to get a good answer to, and probably impossible to get correct.

With regards to the extension to the tool I'm working on:

1. It should be usable in your sample case, if that librarian registers a tool account and creates an event entry on the tool, then gives us a ping from their official email address so we know it's legit. This is the lowest-yet barrier to entry, and from that point the librarian can use the tool to create the accounts quickly and easily (one button press per account to create is my plan), and also addresses most of the security concerns. The issue will be letting event organisers know this exists, and getting this up and running with an example event - but I presume that we can add this to whatever guiding information is given to event organisers.
2. It's more than welcome to go ahead.

I hope this helps to clarify the issues at hand here from the other side of the fence so to speak, and how this issue is actually a really challenging one to solve well due to the seemingly mutually exclusive goals of stopping abusive/banned users from creating further accounts, and allowing events such the library to create accounts for all their participants without issues. [stwalkerster|talk] 13:40, 18 January 2017 (UTC)

Stwalkerster Thanks for everything you said. To keep the conversation focused, I want to especially thank you for confirming that the sample event - a new user librarian who hosts a small wiki event - should be allowed to proceed, and that policy decisions about security should be mindful that this is the sort of activity that should be expected. We could set baseline expectations anywhere, but as start to discussion, I think that expecting this sort of event to happen is a good starting explanation. Previously, some policies have discouraged these kinds of events.

The conversation could continue in lots of directions but I wish to briefly address only a few points, then if useful, more could be said.

Blind leading the blind Part of the pushback against allowing 6+ accounts to be created at events is an expectation that anyone who has the power to do this should be an experienced Wikipedian. The rationale is that successful Wiki events are presented by experienced Wikipedians. I am going to sidestep this issue, and say that whatever the case, this logic does not matter in the current practice. The Wikimedia Foundation and other major players incentivize new users to host events for other new users. This happens on the scale of hundreds of thousands of dollars of funding. This has happened yearly since at least 2014. For various reasons, it is challenging to track outcomes and challenges with these events. Anecdotally, I can say that current policy with mass account creation is not matching current practice. I do not want anyone hunting events to criticize their management, but one outreach campaign which I think would invite a little scrutiny is meta:1lib1ref. In this event, Wikimedia Foundation staff ask people who have never edited Wikipedia and who do not have accounts to host events to teach others to edit Wikipedia. Please do not misunderstand; this is not unusual, this is the current state of Wikipedia outreach, and this is how outreach projects from the WMF and from wiki community groups work. I am not endorsing this outreach strategy and I wish for more conversation, but among all the ways that outreach is done, this is one of the ways and it seems to have comparable efficacy and impact as compared to other strategies to the extent that can be determined when there is hardly data for anything. See at meta:The_Wikipedia_Library/1Lib1Ref/Coffee_Kit, they recommend "Ask participants to create accounts ahead of time (preferred method), Have an account creator available, Request a temporary exception", which is the standard advice and which also makes no sense whatsoever. None of those three options are viable for the 100-200 English language events booked every year in which a new user tells other new users to do wiki. When the enwp rules say, "do things this way..." it results in an unintentional conspiracy in which many strangers all silently wonder if what they are doing is the right process, and no one speaks up even if there is a very high failure rate.

Automated sign in regardless of what crazy current practices are in place, if an automated sign in dashboard is developed, and if it is freely granted to event organizers, then all these problems go away. The situation which I would not want is the development of a tool which is more complicated to access than the current paths for mass account creation. The tool has to have totally new users in mind.

Vetting The event coordination community can make all sorts of concessions to increase security, but whatever policy happens, there needs to be compromise, discussion, and advance agreement. One concession from the security side might be that if a new user gets an account creation tool - whether a user right or an automated tool - then maybe a certain number of experienced Wikipedians need to sign off on that. The question was raised about how to differentiate a librarian from a bad actor. That's easy enough - someone calls the library and talks to them on the phone, or perhaps meets them in person. A lot of the infrastructure in wiki security presumes that doing things like finding a venue's IP address and posting a request through IRC is easy, but things like documenting in-person relationships and having phone conversations is hard. From an event organizer perspective, it is the other way around. Organizations like wiki user groups can maintain professional relationships with all sorts of organizations can be made to agree to sign off on some responsibility for tools. There are lots of potential compromises for giving out tools with lower barriers, but if I would propose one, it would be something like deWP's meta:Personal acquaintances, where an offline relationship goes through some kind of multi-user confirmation process in order to have greater access to specialized tools for special situations.

Thanks for anything you can do. I think we understand each other, and I really appreciate that you have enough insight and ability to outline what would need to be done to address this challenge. Blue Rasberry (talk) 15:00, 30 January 2017 (UTC)

Thank you Stwalkerster and Bluerasberry for having this discussion. As one of the organizers of Art+Feminism this is a significant hurdle we experience, though we are by no means the only organizers who experience this. May I offer one slightly different perspective about the off-network trust structures that are present in A+F and other similar efforts: Many (though not all) of these efforts are organized though off-wiki trusted networks; either one member of the extended network has reached out to someone to catalyze an event, or we have worked with the same person more than one year in a row with success. We know their names, locations, and most of the time we know their professional title at the institution they work for. And we have successfully organized year over year with no incidents.

I also want to ask whether the discussion of the potential for sockpuppetry from this process may be a red herring: it is quite easy for someone to create multiple accounts simply by going to a different coffee shop or library; they don't need access to special account creation tools. Furthermore, they would be downright foolish to try to do that through these tools, as these tools/permissions make it possible to track every account created by said creator thus it would leave their digital fingerprints all over their socks. Theredproject (talk) 19:01, 1 March 2017 (UTC)

@Theredproject: The issue here is someone being granted the account creator right then leaving their login session open on a publicly accessible computer at the event for anyone to use and create their account; this breaks the very "track every account created by said creator" link you speak of since it means there is no longer a guarantee that the individual granted the Account Creator permission is actually the person who pressed the button to create the account. The new Editathon/Events augmentation to the existing ACC system stwalkerster and I are working on aims to address this directly by making the practice no longer necessary, by providing a place for all attendees of an event to easily request an account be created, from which the authorized account creator(s) for the event can quickly and easily vet to ensure that there is nothing untoward going on and create the accounts. This closes the security gap by making it so that an account creator no longer needs to leave their login session open for anyone to use, and has added real security benefits like making it far more difficult for, say, a compromised single laptop being used for account creations keylogging the passwords of all created accounts (a security edge case definitely, but this is the sort of thing that must be considered and addressed). The virtue of knowing that the requests are being reviewed also helps to discourage nefarious use of the system by any potential unethical attendee.

It is indeed quite easy, as you point out for someone to create multiple accounts simply by going to a different coffee shop or library - that's why many of those same end up getting IP blocks placed on them, necessitating assistance when creating an account in many cases and is one of the reasons why the ACC project, and thus the Account Creator user right, exists in the first place.

As for the vetting mechanism A+F uses for event organizers, that's precisely the kind of thing we're looking for to ensure that we're giving rights to people who can be trusted to not misuse them, and is exactly the kind of system we have in mind for the design of the event account creation system we're working on. --FastLizard4 (talk•contribs) 12:32, 2 March 2017 (UTC)

@FastLizard4: Ah! Thank you for that clarification re: the fear of an open login terminal. Let me offer a further clarification that an open terminal is something that never happens at A+F or other such events. We explicitly instruct all of our facilitators to create accounts for people one on one. Typically these events have ~20 people attending and 2 to 5 facilitators so things are very one-on-one. For large events like the one we are running at MoMA next weekend, we have a sign in desk, where one of the lead organizers with account creator status (Siankevans, Failedprojects, and myself) sits and registers people for the event, creates accounts for them on our machines, and directs them to trainings, or thematic editing rooms. At the start of the event all of us will be there handling the rush of people, though by noon we only need one of us with account creator perms there. Many of our WMNYC allies like Pharos, Bluerasberry, Aliceba, Mozucat, Doctorxgc, et al are distributed throughout the three floors of the building we work on, and will create accounts as needed with said permissions they have a permanent basis because of their involvement with edu programs and outreach. I hope this clarifies that an 'open terminal' is not something that has not, nor would not ever take place at an A+F event.

Additionally, thank you and stwalkerster for pursuing a technical solution you think might solve this problem. Given UX/UI best practices, I welcome the opportunity for members of our initiative, as well as other similar projects to provide feedback and guidance on use case scenarios and workflows as you develop the UX flow, to ensure that the end result is something that will work in the environment in which it is deployed. We are working actively with the Dashboard team, and have already provided feedback they have integrated into the product prior to its beta rollout for AF 2017. Theredproject (talk) 16:13, 2 March 2017 (UTC)

FastLizard4 Thanks for the feedback and setting clear expectations. Blue Rasberry (talk) 16:15, 2 March 2017 (UTC)

WMF proposed policy change

The Wikimedia Foundation is proposing policy change at this discussion - Allow users in the Account Creator user group to add users to the Confirmed user group

Blue Rasberry (talk) 21:16, 7 August 2017 (UTC)

@Bluerasberry: this does not appear to be a policy change being requested by the foundation, but by community volunteers. Please let me know if I'm missing something there. — xaosflux ^Talk 02:24, 8 August 2017 (UTC)

Perhaps I am mistaken. I am not sure. Blue Rasberry (talk) 02:57, 8 August 2017 (UTC)

It's community driven. ACTTRIAL is supported by some foundation resources, but is not driven by them, nor are how we define who may grant this flag. This is however a useful RfC for people watching this page. — xaosflux ^Talk 03:46, 8 August 2017 (UTC)

I updated the link to the archived discussion. Also, I do not remember what I was thinking when I posted this, but obviously paid WMF staff were highly engaged in the establishment of this wiki community policy. I hardly understand what was requested here. Blue Rasberry (talk) 13:39, 12 March 2018 (UTC)

Propose change to give access to anyone doing outreach

In response to NOTICE:_EducationProgram_extension_is_being_deprecated at Wikipedia:Education_noticeboard I am proposing a change that the rule be to routinely grant account creator userrights to anyone engaged in a Wikipedia outreach program. This would change the text about granting the userright to anyone engaged specifically in the Wikipedia:Education program, which starting from about 2014 has transformed into all the activities which anyone can now track with the meta:Programs and events dashboard.

The archives of this talk page have records of discussion about all the challenges associated with granting this user right for events. I asked @Xaosflux: to support this policy change because that user is facilitating some changes to the policy about the education userrights which this policy references. Blue Rasberry (talk) 22:14, 8 March 2018 (UTC)

I'm in general support of letting people that regularly run events to hold on to account creator access. I don't think we need to be too formal about it either. The way I see it is, put in a request at WP:PERM/ACC - if you find you are coming back regularly ask for it to not expire - if you don't use it for a year or so then someone will probably remove it. General comments anyone? — xaosflux ^Talk 22:47, 8 March 2018 (UTC)

@Mlpearc, BU Rob13, FastLizard4, Stwalkerster, and Cyberpower678: In the past you all commented here about regulating access to account creator rights. My perspective is that the infrastructure here creates a conflict between wiki event organizers, who need to create lots of accounts for new users at in-person events; and wiki security enthusiasts, who need some standard of quality control which is not currently defined and which frequently is counter to the needs of doing events.

Please see that the WMF is deprecating the old education module and with it the userrights which, until the change in this thread, was one of the checks on who gets account creator rights. With this change I am advocating for anyone who is hosting events to be able to get account creator rights. With current rules I anticipate that this will bring a trend of easier access to account creator rates and more long-term granting of this right, even among people who are not actively using the tool. There are dozens of people like me, for example, who rarely make accounts, but who present lots of wiki workshops and serve as a backup if things go wrong and other account creators are unable to manage the registration process. Recently there was a review at "Can bluerasberry be an account creator?" about whether I should have account creator userright long term. The soon-to-be-deprecated education module granted this to me; as we are re-writing the rules, I still want to retain long-term access to this userright, and also I want a trend of more people who routinely organize in-person wiki trainings to get access to it.

I acknowledge that these changes can cause a range of social and security challenges. If anyone has anything to say about this, now would be a good time to speak up while paid WMF staff are overseeing the changes. Paid WMF staff set up the old wiki policy and they might be able to make commitments to smooth over aspects of the transition if anyone had any development requests. Thoughts from anyone? Blue Rasberry (talk) 13:35, 12 March 2018 (UTC)

@Bluerasberry: To be clear, the WMF does not control the English Wikipedia's policies on this, the enwiki community does. With SUL in place, this does have cross-wiki implications, which could have cross-project impact. (E.g. if an local project account creator creates a bunch of accounts that violate guidelines on other projects -and- then the accounts are used on those projects). I think where WMF can be of great use would be in getting account creation bundled in to the PEM Dashboard, having the event dashboard do the creations (completing avoiding IP throttles). — xaosflux ^Talk 14:11, 12 March 2018 (UTC)

Account creations may create a global SUL but they're not really global. There may be a username that violates some local policy on some Wikipedia, but if it doesn't for the wiki it's going to be primarily used on, then it's not really the concern of the global community. As a global renamer we are mostly concerned if the requested username violates the home wiki's username policy. We also of course use common sense when evaluating requests.—CYBERPOWER (Chat) 14:15, 12 March 2018 (UTC)

@Xaosflux: I do not think there is any clarity in where WMF engagement starts and stops. Yes, I confirm, nominally the wiki volunteer community establishes policy and outranks WMF decisions. In practice, the WMF allocates a US$ 100 million / year budget and that money and power comes with influence. It is a statement of fact that WMF staff are a major drivers in developing ENWP policies.

Yes, I agree, I would very much like for account creation to be bundled with the P&E dashboard. There would be many obvious benefits of that, including being able to identify which new user registered in association with which event, and creating a communication channel and chain of responsibility between any given program and the team organizing it.

I want the development you describe for the meta:Programs and Events Dashboard to happen. The WMF probably right now has a budget allocation of US$ 100-300,000 tied up in the tools for program management and is likely to make 1-2 million dollars of investment in outreach management and grant reporting over the next 5 years, with that amount aside from the actual funding of programs and events. On the wiki community side there are about 10 volunteers on this page advocating for policy, most of whom have never organized an event and who have 0 budget for engaging in this policy process. The wiki community has challenges convening the right conversations about policy or even articulating needs. I am not sure how to promote a discussion which matches the impact that this policy has but I expect that what happens here will direct the near-future flow of millions of dollars for tens of thousands of people on a global scale. Blue Rasberry (talk) 14:33, 12 March 2018 (UTC)

• Sure Why not?—CYBERPOWER (Chat) 13:44, 12 March 2018 (UTC)
• Comment I thought we had not long since had a discussion about this somewhere, perhaps at the Pump or ANI, and there was huge opposition to the idea that just because someone was running an outreach program then that did not mean they should hold the account creator right. Perhaps my memory is wrong but I'm pretty sure it is not. The problem is, I cannot remember the details. Maybe advertise this in some more well-trafficked forum?

Purely from my own perspective, I'm not wonderfully happy about it because we've had an awful lot of rubbish - including loads of copyvio etc - when events such as Dalit History Month have happened. They've taken masses of time to find and fix, and that despite supposedly being supposedly overseen by experienced Wikipedians. - Sitush (talk) 23:26, 12 March 2018 (UTC)

@Sitush: new accounts can't really do much more then IP editors - has any of the "rubbish" you've seen been related to the actual creating of accounts though? — xaosflux ^Talk 00:00, 13 March 2018 (UTC)

Well, if newly-created accounts then run amok at an edit-a-thon then, yes, I've seen it. Obviously, actually creating an account is a purely administrative/bureaucratic thing and cannot in itself be classed as "rubbish" ... but the immediate result of doing so can be. I've just dug around VPP and ANI archives for a few minutes trying to find the past discussion, which involved some very long-term contributors etc, but I'm blowed if I can find it and for some weird reason (perhaps related to bot activity?) the last edited dates on a lot of the archives bear no relation to the date of the thread, eg: I found a thread involving me from 2014 that was timestamped in the search results as 2017 - that makes it much harder to dig stuff out. The discussion was within the last 14 months, and probably much more recent. - Sitush (talk) 00:13, 13 March 2018 (UTC)

Found it here. It is actually about a slightly different issue but given the concerns raised there regarding who was granted thr AC right, it may still bear noting. - Sitush (talk) 00:22, 13 March 2018 (UTC)

I remember that, and was a general opposer as well (to non-experience editors being account creators, especially indefinitely) - but assuming there is actually an edit-a-thon, they can edit without logging in, so have you seen any specific problem that only came across because the editors had an account? — xaosflux ^Talk 00:29, 13 March 2018 (UTC)

No, except for what I consider to be a fact: that AGF or no AGF, people tend to trust named accounts rather more than anons and so things slip through. Turning this on its head: what benefit is there to them having a named account created for them? I'm not familiar with the ins and outs of the outreach programs, except in so far as they seem to cause a lot of problems. Of course, perhaps it is only that they appear to cause problems because when they are running ok there is rarely a mention of them, so perception is biassed. - Sitush (talk) 00:48, 13 March 2018 (UTC)

@Sitush: You are right to have concerns. In the past the wiki community has opposed the change I proposed here. I do not have complete data to show you, but I have some. In the United States maybe there are 300 wiki community events and another 400 programs for students in classes. Maybe 5000 new editors sign up and actually edit through outreach in a year in the US, but I do not have good data. Any kind of event - whether community event or class program - gets tracked in something called the "meta:Programs and Events Dashboard" and would produce a report like for this physical therapy class. The change since about 2014 is that there is more awareness that WMF funding programs provide maybe US$2 million/year to encourage this kind of outreach but there is limited tracking on how well outreach works. Regardless of the problems, the WMF will continue to encourage more outreach with funding and staff support.

You asked about the benefit of anyone having an account made for them - the benefit is so that the event organizers can track them for reporting to sponsors and also so that the wiki community and WMF get research data about who has the most effective outreach and training. Most programs in the United States work fine but here also there are a lot of highly trained wiki outreach people providing support. For other places I cannot say.

To see an example of the simplest kind of new article that a new user might make at an event check out Quail and Millet (Kiyohara Yukinobu). For this a museum donated images of most of its art and supported Wiki editors in making articles for each one. The standard here was that there had to be some citations. This model for new users making new articles is expanding. This is not the usual kind of outreach, which usually asks people to add more, but it might be surprising to experienced Wikipedians because it starts off new users with an image, some sources, and an infobox. Blue Rasberry (talk) 13:32, 13 March 2018 (UTC)

Yes, that old discussion is relevant because during wiki events often the goal is for people to make new articles.

• I'm fine with trusted editors having this right long-term. I'm not fine with outreach folk who do not have on-wiki experience being granted this long-term. As long as such a distinction is drawn, I support this change. ~ Rob₁₃^Talk 01:18, 13 March 2018 (UTC)

@BU Rob13: Under what circumstances can you support someone with 0-25 edits getting account creator rights for 10 days? A trend in wiki outreach has been encouraging librarians, museum staff, and subject matter experts to recruit a community base to host a wiki event. Often the event coordinator has a skill set of being popular and a good socializer, but might not edit wiki themselves. This happens at least 50 times a year in the US already. The user right being nominated for deprecation gave "course coordinators" the social privilege of giving these kinds of new editors account creator rights. There have been protests about this in the past where some people said that only experienced Wiki editors should get the rights, even temporarily. I do not have good advice about this! I want these events to happen, I say that I am not aware of any history of security breach, but it is correct to say that the account creator userright carries risks to pass around. What do you think about new users with the right? Blue Rasberry (talk) 13:36, 13 March 2018 (UTC)

@Bluerasberry: I think you are worrying a bit more than needed, a recent review of Wikipedia:Requests_for_permissions/Archive shows that most anyone asking for this access related to events has been getting it without much issue (and almost all of the denies are either obvious denial reasons or come back when your event is going to take place). Also, on follow up to PEM improvements - I think the request an account process is working a lot better now. See my example event here. There is now a request an account button, I think it is still using the address of the user clicking it though - I saw WikiEdu recently got a permanent exemption for their dashboard (dashboard.wikiedu.org) in phab:T126541 - perhaps it can be replicated by outreach? — xaosflux ^Talk 14:16, 13 March 2018 (UTC)

@Xaosflux: I tried out your "request an account" feature. It worked great! I can only see the new user side of this and not the interface for the event organizer to get an alert and approve new accounts, but assuming that the requests immediately go to the organizer then this is a viable system for managing events. You have demonstrated that you understand the challenge to address and yes, this is a solution. Blue Rasberry (talk) 14:28, 19 March 2018 (UTC)

(edit conflict) I'm always fine with such editors getting the right for a verifiable event. I just don't want them given the right long-term. They should come back to the requests page every time they have an event if they don't have a record of good contributions on Wikipedia. We're happy to help them run events, but we need more checks when we don't have an on-wiki history to know they're trustworthy. (To be clear, I'm not saying anything about the value these editors add to the project; conducting in-person events is incredibly impactful. It's just harder to judge trust/competence in these cases.) ~ Rob₁₃^Talk 14:17, 13 March 2018 (UTC)

@BU Rob13: Okay, thanks for that. There has been some ambiguity in the past and I would like to firm up the practice of routinely giving new users account creator rights when they can verify that they are hosting an event in any of the usual ways. What you describe works. Blue Rasberry (talk) 14:28, 19 March 2018 (UTC)

• 'Comment: Could the proposer or anyone else compare and contrast the proposal to the current way of doing things? Is gaining ACC a burdensome process now? ☆ Bri (talk) 19:58, 20 April 2018 (UTC)

Typical problem case - IP block at school for event

I wanted to share a discussion about permitting account creation at an event. There is a two-day, higher profile editing event at a college. Maybe 100 people will be there including lots of school faculty. There is an IP block associated with the school. About 5 highly experienced Wikipedia editors who also have organized 100+ in-person events are trying to anticipate for account creation and remove the school's IP block. There is no obvious path for us to do this. See

• User_talk:Graham87#Please_allow_my_students_to_register_their_accounts

No one is doing anything wrong here. The situation is just that some people do security, and some people do events, and there is no way for effective communication between these interests. The security side cannot articulate a request for the outreach side to fulfill, and the outreach side has no path to make an event safe enough to remove an IP block.

The block is inexplicable - maybe something happened at the school years ago, but getting any explanation of why the block exists is not possible.

I am sharing this not as an off case, but as the norm for hosting events. Rarely do any complaints actually escalate to an on-wiki report. More commonly, event coordinators have the event disturbed because of a block and no one ever reports the situation. I am going to make an estimate that this repeating conflict causes ~US$200,000+ / year to evaporate or at least lose impact, give negative experiences, lose a recurring partnership, etc. Much of this money is donations to the WMF which goes in the form of grants and even WMF staff outreach and then gets smashed.

I get the idea that all of this problem is because of a miscommunication, and actually, convening a few video chats with the right circle of people could resolve this years long, 100+ event problem. Outreach coordinators would do something to increase security but there are no clear rules. The demand that I hear from the security side is that there should be more security sensitivity on the outreach side. Probably the cheapest and easiest path to this is to have a paid staff WMFer on a phone hotline at hand to receive calls to release blocks on events, which is an absolutely bonkers solution to this problem except for being the most practical and feasible solution I can imagine.

Alternatively, maybe there could be some miracle solution to this incorporated into the Wikipedia:Requests for comment/Event coordinator proposal. I have no good ideas regarding the technical side of this, but I know how outreach works and I see regular disturbance of highly funded outreach! This is a financial and reputation liability for the WMF and all partners! Blue Rasberry (talk) 17:33, 20 April 2018 (UTC)

• similar case - Wikipedia_talk:How_to_run_an_edit-a-thon#Blocked_editing_at_high_profile_event

Blue Rasberry (talk) 18:12, 20 April 2018 (UTC)

Wikipedia:Event coordinator

With the pending creation of the event coordinator user right, do we want to update this page to shift individuals who are currently granted account creator to request that right? It will have (noratelimit), but without the ability to override the blacklist or the anti-spoof mechanisms. TonyBallioni (talk) 18:44, 8 May 2018 (UTC)

I'd think so, in general if they are here because they are "coordinating an event" they should go to a new EC intake instead of AC. — xaosflux ^Talk 20:19, 8 May 2018 (UTC)

My thoughts as well, but I did want to raise it before making any changes. TonyBallioni (talk) 20:49, 8 May 2018 (UTC)

I'm happy to remove the outreach provisions and turn this into a mainly ACC-only thing. Do we need additional community consensus around this, or is it just natural cleanup? TheDragonFire (talk) 03:04, 12 May 2018 (UTC)

Natural cleanup. There are only a few admins who regularly patrol that PERM page, and they are all semi-reasonable people. ;) No need for an RfC for basic stuff, especially if no objections here. TonyBallioni (talk) 03:19, 12 May 2018 (UTC)

• Agree. ~ Rob₁₃^Talk 14:15, 12 May 2018 (UTC)

Userright established

• Wikipedia:Event coordinator

Thanks TonyBallioni + others. Blue Rasberry (talk) 16:35, 14 May 2018 (UTC)

"Account creators" listed at Redirects for discussion

A discussion is taking place to address the redirect Account creators. The discussion will occur at Wikipedia:Redirects for discussion/Log/2021 April 14#Account creators until a consensus is reached, and readers of this page are welcome to contribute to the discussion. TAXIDICAE💰 16:55, 14 April 2021 (UTC)

Note 2

Note 2 to this page is currently written such that it seems to apply to all title blacklist entries. However, basically all of the ACC requests I see requesting override of the blacklist match only an entry that is marked <newaccountonly>, meaning that account creation requires the tboverride right, but page creation should be completely unaffected.

I was either unaware of or forgot about this note, and have been overriding the blacklist accordingly without those users having any apparent issues. Is anyone aware of any issues with creating accounts that only match newaccountonly entries, or do those only apply where the blacklist entry lacks the newaccountonly attribute?

Cc. @Oshwah as writer of this note. — Mdaniels5757 (talk • contribs) 00:47, 4 August 2024 (UTC)

Hi Mdaniels5757! As far as I know, the option to override the title blacklist applies to all entries that are saved to the blacklist. Entries within the title blacklist that are tagged with <newaccountonly> only apply the restriction to new accounts (meaning that only new accounts are not allowed to contain the current entry). I'll review the note and revise if needed. Please let me know if you have any more questions or if I can help clarify anything else. Thanks for letting me know about this! ;-) ~Oshwah~^{(talk) (contribs)} 01:03, 14 August 2024 (UTC)

Discussion at Wikipedia:Templates for discussion/Log/2024 October 23 § Template:Account creator/right place notice

 You are invited to join the discussion at Wikipedia:Templates for discussion/Log/2024 October 23 § Template:Account creator/right place notice. –Novem Linguae (talk) 16:45, 23 October 2024 (UTC)