Wikipedia talk:Account creator/Archive 1

Archive 1

Granting of this group to people who want to edit editnotices

I've just reverted a change by Wifione that appeared to suggest that we're giving the accountcreator group out to (effectively) anyone who wants to edit editnotices. Have I missed some discussion somewhere that approved this? It has some specific account-creator only stuff that I for one am not particularly happy being given out to almost anyone. Please can someone explain this before reverting my revert? Thanks. [stwalkerster|talk] 03:56, 22 November 2010 (UTC)

• Neither have I noticed any discussion. I presumed (wrongly, I guess after your response) that the account creator permission could be given to those wishing to edit the edit filters. I have no issues with your revert. Best. Wifione _....... ^{Leave a message} 22:33, 24 November 2010 (UTC)

Account creators should not be editing edit notices. Prodego ^talk 00:20, 30 March 2011 (UTC)

Would someone mind explaining overleaf a bit more clearly why account creators have been given the technical ability to do so? Skomorokh 21:30, 30 April 2011 (UTC)

It is the way that overriding blacklisted usernames works. Prodego ^talk 01:34, 14 May 2011 (UTC)

Account creators are simply able to override the title (and by extension - username) blacklist (and a few other irrelevant things). If edit notices had not been protected in a hackish way (by blacklisting the names of the damn things), then we wouldn't be in this situation of account creators being technically able to create edit notices. The long-term solution here is to fix the edit notice protection. [stwalkerster|talk] 11:54, 14 May 2011 (UTC)

• Comment The first hit of the new edit filter has been reported now: Wikipedia:Edit_filter/False_positives/Reports#Ancient_Apparition. —Soap— 12:09, 14 May 2011 (UTC)

I just hit the filter (twice) as well. This is quite unfortunate. :/ Logan _Talk ^{Contributions} 00:18, 20 May 2011 (UTC)

I'm not sure what is achieved by stopping accountcreators from editing editnotices. It may have been accidental that is was enabled in the first place, but has there been any abuse of the facility? If not, I propose we turn it back on. There are occasional times when it is useful for a non-admin to be able to edit these things. — Martin (MSGJ · talk) 11:51, 23 May 2011 (UTC)

This edit filter has now been deleted. — Martin (MSGJ · talk) 15:28, 24 May 2011 (UTC)

Updating policy per my note at Village pump

Per my note here[1] I'm going to update the account creator project page by including the following statement. Kindly suggest any changes if there are any. Thanks and regards. Wifione ^Message 05:13, 24 February 2012 (UTC)

• ACC interface administrators (whether they concurrently are administrators on the English Wikipedia or not) are authorized to accept or reject requests for the account creator flag at Wikipedia:Requests for permissions/Account creator. They also have the right to remove the flag in case the right is misused. Their decisions in these regards will be accorded the status of decisions made by Wikipedia administrators. Those interface administrators who are not Wikipedia administrators may request a Wikipedia administrator to implement their decisions.
  • Alright, much time has passed. Placing material into policy. Wifione ^Message 14:00, 25 February 2012 (UTC)

"Much time has passed?" A day is not a relative example of "much time" (At least, I don't think so). Also, there was not any discussion what-so-ever on this policy change from any user. -Fumitol|talk|cont 19:58, 25 February 2012 (UTC)

Sure; no problems. Discussions at VPP have already more or less agreed to reverting to the long standing procedure. Thanks. Wifione ^Message 03:45, 26 February 2012 (UTC)

I've removed the archive top and bottom templates as Delta removed the addition from the Project Page. I'll also leave a note at WT:PERM asking for comments. But I don't see that there will be a problem as it currently stands. Callanecc (talk • contribs • logs) 04:29, 12 August 2012 (UTC)

I kind of like the idea of being able to approve or decline a request for the user right. It sounds like a lot of fun. But seriously... are there really that many requests? I am seeing 2 or 3 per month this year. I can see a practical value to being considered regarding approving or declining the granting of the right. Those who can bestow the right aren't all involved in use of the right. If i were to mark a request as "approved" and an ENWP admin came along and marked it "not done" well that would be awkward. Similarly if i were to mark one as "not done" and an ENWP admin came along and ignored/overwrote me and granted the user right just because i am not an admin here it could be complicated if the one making the request for the user right were proving themselves to not be a really good fit for ACC. If the proposal was to suggest the bestowal of the right rather than simply approving its bestowal well that would require creating a whole new user group here on ENWP and i doubt that would be welcomed. There are currently myself and 3 others who can approve and suspend a user at ACC but who can not grant or revoke the account creator user right. Depending on how you wish to define "active" that is between half and one third of active admins at ACC. I watch these pages but Mlpearc seems to be faster than i. When he tells someone "no" it does get considered a non-admin closure, which in half-a-sense it isn't. delirious & lost ☯ ^~hugs~ 10:45, 13 August 2012 (UTC)

Confirm users

As documented on mw:Help:Mass account creation, sometimes creating accounts is not enough to avoid problems for workshops on en.wiki, as experienced by Andrew Gray probably due to the very restrictive settings en.wiki has for newly registered users. A solution would be to also add such new accounts to the "confirmed users" group, which basically gives them only the permissions they'd automatically have after four days on any other wiki. Currently only administrators can add this flag, perhaps it should be part of the account creation process and account creators should be able to add and remove it as well. --Nemo 17:09, 22 October 2012 (UTC)

I think this is a situation where it would be better to get the workshop (or school group, whatever) to request the confirmed right for all of the accounts which are created for them, seperately from the WP:ACC process, either a page specifically for it (and there may already be one), or a request to a sysop individually. Mainly because I think this would be a much easier way to go about solving the problem, than to try and get community consensus for the ability to grant userrights to a non-admin group. Callanecc (talk • contribs • logs) 07:49, 23 October 2012 (UTC)

I've experimented with asking people to tell me once they've registered usernames, and while all the names do get registered in advance, only about 30% report what it is before the workshop - outside of a school setting, the first time you're likely to have all the names is once the workshop begins. Confirming on the day does work - we tried it at an event on Friday and we only had one throttling problem - but it requires an admin handy; luckily we had two. I worry a request-based system would be fairly inefficient, as the throttling is most of a problem in the first half hour.

I'm not sure about whether bundling it with AC is the best approach or not, but some way to devolve this right to a wide range people doing hands-on events - be that trainers, campus ambassadors, whoever - seems a very interesting way of solving the problem. Andrew Gray (talk) 08:24, 23 October 2012 (UTC)

Yes andrew thanks for comment Choudhar Rohit Rathi (talk) 00:12, 19 June 2016 (UTC)

requiring identification

I'm curious - was there a discussion somewhere that prompted this change? It seems odd to me. I cannot think of any abuses of +accountcreator so significant as to require identifying to WMF. I noticed the change when reading a discussion on EN/B about assigning user rights to instructors of classes participating in Wikipedia based assignments - they definitely have a legitimate potential need for it, but it seems weird to require them to ID to WMF. It also seems weird to have a userright that can be assigned by administrators (who don't need to identify to the Foundation.) It is also definitely not a requirement that is being followed in practice. Kevin Gorman (talk) 23:25, 15 January 2013 (UTC)

Hi, Kevin Gorman. As I do not know the whole story to the identification change, I have contacted two of the main ACC admins inviting them to explain. I can explain the other parts to this message though.

The account creator right itself is not the reason why users must identify, it is using the ACC interface that requires identification. This is because the ACC interface records nonpublic data that is used to assess a request. However, instructors only see the signup page and thus do not have access to that nonpublic data so there is no need to require them to identify. This is the same with administrators.

Hope this clears things up. -- Cheers, Riley 23:47, 15 January 2013 (UTC)

From what I've understood, Riley is correct. Because of the sensitivity of the data used in the ACC process, one must be identified to WMF in order to access the tool. Please see the access to nonpublic data policy. MJ94 (talk) 23:52, 15 January 2013 (UTC)

Yes, Riley is correct here - the user group doesn't need identification, but the ACC interface does capture and display private data, hence the need for identification. Unless someone needs access to the interface (+mailinglist, +irc channel), they need not identify. [stwalkerster|talk] 23:57, 15 January 2013 (UTC)

(edit conflict)Any objections to me editing the description a bit to make clear that identification is required to access the account creator interface, but not simply for assigning +accountcreator? There are a decent (and growing) number of reasons to have +accountcreator without having access to the ACC interface. (I'm an example of someone with +accountcreator who has actively used it who doesn't have access to the ACC interface... though since I've had a contract with WMF, I guess I would meet the ID requirement anyway :p.) Thanks for the fast answers. Kevin Gorman (talk) 23:58, 15 January 2013 (UTC)

(many edit conflicts later...) None of the actual technical abilities the account creator flag grants (specifically: noratelimit, override-antispoof and tboverride) allow access to nonpublic information, but the account creation tool does display information that would otherwise only be available to checkusers. This is the source of the requirement to identify. Regarding administrators being able to grant the right, note that those three rights I mentioned before are also available to the administrator usergroup, and that simply having them does not grant access to nonpublic information. --(ʞɿɐʇ) ɐuɐʞsǝp 00:09, 16 January 2013 (UTC)

I've made a major edit to the page to update it given what's been happening recently and the discussion above. Callanecc (talk • contribs • logs) 08:13, 19 January 2013 (UTC)

Oops, thanks Riley. Callanecc (talk • contribs • logs) 08:13, 19 January 2013 (UTC)

Thanks, looks pretty good to me. I made one minor additional edit to it, because I can see it being potentially necessary for stuff like GLAM and other physical otureach too. Kevin Gorman (talk) 17:44, 19 January 2013 (UTC)

It still says that identification to WMF is required for everything (only for ACC now that I clarified). This doesn't make sense (as said by Deskana and Kevin Gorman) for two reasons:

1. not all account creators need to access the ACC tool,
2. the ACC tool is not on WMF servers but on Toolserver.

Nemo 17:22, 20 January 2013 (UTC)

Your edit has clarified that.

1. If the ACCRIGHT is requested due to involvement in the WP:ACC process then the person will already be identified. The only other reason to have the right is for mass account creation and the only reasn you would be doing that is an Outreach program.

2. Whether or not that is the case we deal with personal and private information which would only be available to Checkusers (specificially email & IP addresses) so have to be identified to the WMF.

Callanecc (talk • contribs • logs) 23:12, 20 January 2013 (UTC)

New qualifying criteria

Im slightly concerned that "involved in the Education Program or other outreach work where they have a need to create accounts without restriction." is a little too loose a guideline for handing out what is potentially a powerful toolset. How do we know that users involved in the education program have sufficient knowledge of the username policy, or technical limitations, not to use override-antispoof and tboverride functions to create inappropriate usernames or usernames that are too similar to existing accounts. How do we know they would not create local accounts that exist and are active on other Wikis but unattached. What type of user in the Education program is eligible and what is the level of trust required? Apologies in advance if this has already been thought through, but I couldn't find mention of it anywhere. Pol430 talk to me 22:54, 9 February 2013 (UTC)

Request an account process needs help

Hello everyone, I'm Callanecc, an administrator on account creation interface. Recently, our project has had an increased backlog in getting accounts for new users. Our numbers are currently over 250 people waiting for accounts on the English Wikipedia. If you could even spare a moment to do a few requests a day to help us clear this backlog, that would go a long way to encouraging new editors to participate with an account. If this interests you and you're willing to help, and you match the following description, then please do apply! Ideal users are:

• Identified to the Wikimedia Foundation or are willing and able to identify
• In good standing with no recent blocks or other sanctions
• Understand and are able to apply the username policy
• Have worked with new contributors
• Keep personal information confidential
• Please see the full list of requirements for more information

We have a very friendly team to help you get started, we also have a private IRC channel where you can ask questions or get help with difficult account requests. If you have any questions for us or about the process, feel free to ask at the talkpage. If you can help out, we would greatly appreciate it. For the ACC team, — Preceding unsigned comment added by Callanecc (talk • contribs) 00:32, 5 December 2013 (UTC)

Link to use the tool

I use this tool at events where a lot of people need accounts in a hurry. I only use it periodically and I forget between uses, and other people with the userright forget also. I think there should be a prominent link to the tool on the page. Historically there has not been any link to the tool for some reason. Wherever the tool is on the page it should be easy to find. Is there any reason to not make it very visible? Blue Rasberry (talk) 20:53, 16 April 2014 (UTC)

Probably a good idea yes, though is this page necessarily easier to get to directly than the account creation page? Sam Walton (talk) 21:00, 16 April 2014 (UTC)

I don't really see the link as necessary. John F. Lewis (talk) 21:04, 16 April 2014 (UTC)

I come to this page by typing WP:Account creator into the search box. I am not sure how the link could be best displayed, but in a way that is not confusing, I think there should be an obvious link somewhere here. Until now there has been no link.

John F. Lewis it is my view that this userright exists to give access to the tool at that link. Why do you feel that a link to the tool should not be on this page? Before the link was there, there were not even instructions on this page about how to find the tool. Blue Rasberry (talk) 21:41, 16 April 2014 (UTC)

The account creator tool set is nothing extra. All it does is allows you to override the blacklist, override antispoof and have no rate limits. No new special pages or interfaces. John F. Lewis (talk) 21:45, 16 April 2014 (UTC)

I see. So anyone may create pages for other people, but only a 6 per day. I thought the actual making of accounts for others was restricted. Blue Rasberry (talk) 02:26, 21 April 2014 (UTC)

Is the tool you're referring to Special:CreateAccount? If so I can see a reason for including it in the see also section, but not a massive box which overwhelms everything else. Wikipedia:Create an account seems to be the more obvious link to follow than Wikipedia:Account creator. I'd support a link to Special:CreateAccount in the see also section as well as a link to the ACC tool. Callanecc (talk • contribs • logs) 02:34, 17 April 2014 (UTC)

As I understand, this page is documentation for a userright, "account creator". The only privilege granted by "Account creator" is use of the tool at Special:CreateAccount. If some is trying to use this tool and they go to Wikipedia:Create an account then they are in big trouble, because that page is for people making accounts for themselves whereas this userright is concerned with helping people make accounts for others. Special:CreateAccount is not something for "see also"; that is the point of this page. WP:ACC could go in see also, because that is the on-wiki work queue. Perhaps I should ask you to confirm the point of this page because perhaps I misunderstand. We can sort the layout after it is settled what is supposed to happen here. I am still a bit confused that this tool has never been linked on this page, when I thought that this page existed to send people to that tool. Blue Rasberry (talk) 02:26, 21 April 2014 (UTC)

Agree with Callanecc, in the "See also". Mlpearc Phone (open channel) 13:16, 23 June 2016 (UTC)

@Mlpearc and Mlperc Phone: I might still not understand. The people who get this userright can make lots of accounts in a day. The purpose of this right is to allow people to make more accounts. Many people who are using this right are not experienced Wikipedians, and they need one name for this tool and and easy way to find it.

If I understand correctly, you want the process of creating many accounts to require users to learn two similar sounding terms, "account creator" the right and "create an account" the process, and you wish to make it less obvious that the two are different things. I feel like this is a level of nuance that should not be expected from the many users of this tool who are new Wikipedians helping with events.

Can you offer any counter-solution that communicates that if a new user knows they have "account creator" userrights, then they also easily find the "create an account" page? Can you say why you think it is sufficient to move the tool to the bottom of the page rather than make it the first thing a person sees? Am I mistaken, or is the purpose of the "account creator" userright to help people use the "create an account" process? Thanks. Blue Rasberry (talk) 05:03, 24 June 2016 (UTC)

@Bluerasberry: New users don't get this userright, it's explained here Wikipedia:Account creator#Becoming an account creator. Mlpearc Phone (open channel) 05:32, 24 June 2016 (UTC)

Propose changes to process for granting userright

I would like comment on making the following change.

---

The account creator flag may be granted to users who are either:

• (...)
• involved in the Education Program or other outreach work where they have a need to create accounts without restriction.

change to

• (...)
• involved in outreach projects in which there is a need to create accounts without restriction

---

I want this change for the following reasons:

• for removal of the "Education Program" affiliation requirement - Currently the rules give special favor to the Education Program, and have since this January 2013 edit by Callanecc. Granting a special place to the Education Program was never discussed here or anywhere else so far as I know. On this talk page in February 2013, Pol430 asked in the "new qualifying criteria" subsection here why the Education Program should get special attention, and no one answered. Because the addition of this criteria was never discussed, I think it could also be removed without much discussion. For further context, the Wikipedia Education Program has not been active in English Wikipedia since about 2014, and was hardly even active at its inception in 2013. Currently the Education Program maintains itself outside of English Wikipedia, and if I understand correctly, it only starts projects with a basis outside English language. Previously, some paid staff of the Wikimedia Foundation were imagined to be available to assist with Wikipedia outreach to schools starting around 2011. In practice, there never was staff support for participating in account creation, and the participants of the Education Program never developed a process for determining how account creator rights should be awarded. I think a new practice should be confirmed to ask that all programs go through the same request process.
• for removing the link to MediaWiki's account creation guide - The information in this link will not be relevant to most people's experiences using the account creator tool. Typical use of this tool would be for someone with account creator userrights to manually create about 10 new Wikipedia accounts for a local in-person gathering at a community center. The link is to MediaWiki documentation outside the context of English Wikipedia and usual Wikipedia event organization. There are details there about MediaWiki development and network administration which is useful for using software to create accounts from a database or to request a block exemption for a range of IP addresses. Almost no one needs that, and this information should not be presented prominently.
• for permitting anyone involved in outreach projects to request this - in practice, the tool is already granted in these circumstances. Even new users who make a request for the tool saying that they need it for outreach work usually get it. I changed the term "outreach work" to "outreach projects" to clear confusion that there might be a requirement to be paid staff for this. At this point, I do not think there is any expectation of professional staff event management when the tool is granted.

I recognize that there were hardly any criteria for granting this tool before, and I am not intending to either add or remove criteria with this proposal. If there is any reason to discuss adding more rules then I would participate in discussion, but so far as I know, the system works well enough now. I want the changes just so that various outreach projects which might have individuals apply for the userright can come here and get up-to-date information about when these rights are granted. Blue Rasberry (talk) 21:22, 3 August 2016 (UTC)

• Support as proposer Grant userright to anyone who requests and who is "involved in outreach projects in which there is a need to create accounts without restriction". Other restrictions and qualifications may be added later. Blue Rasberry (talk) 21:22, 3 August 2016 (UTC)
• @Swarm, Mlpearc, Xaosflux, Phil wink, Liz, ~riley, Gobonobo, KrakatoaKatie, Pharos, and Theredproject: You all have participated in talks about accountcreator userrights in the past. I though I would signal you here to ask for your thoughts on changing things a bit here. If you had any comments about what has worked well and what could be better, then please share. See also some discussions below. Thanks. Blue Rasberry (talk) 21:29, 3 August 2016 (UTC)
• I Support this proposal, as it makes clear the vital importance of this role to event and meetup organizers. Every spring we need to grant this permission to WP:A+F event organizers, and clarifying the ways that this role is appropriate for them will aide and ease our effort.Theredproject (talk) 18:08, 5 August 2016 (UTC)

Temporary access

Tracked in Phabricator
Task T12493

Right now there is some confusion about when users can have the accountcreator userright permanently and when it needs to be held temporarily, perhaps for 1-2 weeks.

Here is an example of a problem case about permanent granting of the tool. Documentation here has never said anything about whether users should have permanent or temporary access to the tool. However, on the page for requesting the tool, reviewers have a practice of saying that the tool can only be granted immediately before an event and that it will be removed after.

In the case linked above, there was hesitation to give the tool to an experienced Wikipedia contributor who had been organizing in-person Wikipedia events for years. The hesitation was due to the person not stating a short date range of about a week for when they should get the tool and when it should be removed. I think people who routinely organize events and who have Wikipedia experience should be able to keep the userright indefinitely.

If there is supposed to be a system for distinguishing who gets this tool permanently and who gets it temporarily, then someone should draft a guideline for that. Until someone drafts a guideline, I think that persons requesting access should be able to choose for themselves whether they wanted it permanently or temporarily. Other thoughts? Blue Rasberry (talk) 21:22, 3 August 2016 (UTC)

• Note - there is a mostly stalled ticket to enable group expirations phab:T12493. — xaosflux ^Talk 23:38, 3 August 2016 (UTC)

• I've always been pretty willing to give this to even newer editors that have some sort of specific plan, but I'm not really in favor of a "I might use this one day" type of request. — xaosflux ^Talk 23:41, 3 August 2016 (UTC)

  Xaosflux Right now almost all userrights are presumed to be granted indefinitely, so far as I know. I am not aware of where I might copy text from elsewhere to indicate that this userright goes temporarily to some people, or if it should be permanently granted to others. There are a few hundred people in the world who to to in-person Wikipedia meetups several times yearly, and I might suggest that any of those could be candidates to have permanent account creator status just because of their history of organizing events. How complicated should the documentation here be? Do you have any starting ideas for drafting it or drawing lines? Do you feel bold enough to say that no one should permanently have this userright? Blue Rasberry (talk) 13:45, 8 August 2016 (UTC)

  If someone is "regularly" creating accounts as part of ongoing outreach work - then leaving it in place is fine by me. It is pretty easy to come by. Conversely, if someone is not actually ever creating accounts then flipping it off should also be no big deal. — xaosflux ^Talk 13:56, 8 August 2016 (UTC)

Resolved

Fair enough - I now think it is not so complicated. Blue Rasberry (talk) 22:16, 8 August 2016 (UTC)

I am indifferent about making a distinction between temporary or permanent access. I think I oppose the idea of temporary access if no one drafts the rules, and I support the idea if someone types out any idea that gets a few comments in support. Any rules would be good for me. The biggest problem for me as an organizer is not having rules and having ad hoc conversations that can have different outcomes at different times. Blue Rasberry (talk) 13:45, 8 August 2016 (UTC)

• I Support this, and I like User:xaosflux's augmentations to this simple protocol. So: User can decide whether they are requesting temp or perm, and duration of temp; either way, they should have a concrete plan. Theredproject (talk) 18:13, 5 August 2016 (UTC)

Multi-site events

In February 2016 there was planning for Art + Feminism, which is a Wikipedia outreach project to encourage people in many different locations to meet in local community centers and edit Wikipedia together. Typical events in this series might be a meetup of 15 people in a local library. Because more than 6 new users might show up to any of these events, part of the planning includes anticipating that more than 6 new accounts might need to be made quickly at any location. In 2016, the way this was done was to give account creator rights to 1-2 people at each location so that everyone who attended an event would be able to get a Wikipedia account on that day. As it happened, Art + Feminism had about 100 events with anticipated attendance of 15 new editors at each one. I am not sure of the final stats, but 1500 people really did participate in the event and edit. Almost all of those were new accounts made in a single day.

There was a short discussion about this on the account creator request board but most of the discussion happened at Wikipedia:Administrators'_noticeboard/Archive279#Large_group_of_users_requesting_accountcreator_permissions. Concerns included the following:

• People who grant account creator rights typically are not involved in planning in-person outreach, so had trouble understanding what happens during in-person Wikipedia events
• Persons who organize in-person events are almost never involved in Wikipedia content security, including vandalism, management of userrights, and general risks to Wikipedia
• The people who wanted account creator rights were often new accounts which were not even autoconfirmed. There was no rule against this, but it gave reviewers pause
• The channel for discussing this would seem to be the account creator request queue, however, there are not well developed guidelines here for discussing this
• The guidelines developed here anticipate use by paid staff of the Wikipedia Education Program, their affiliates, or people whom they oversee. Actually, that system of practice never came into being, and outreach works a different way than described for that system from 2011

In the end for that case, account creator rights were managed by particular admins outside the context of the "account creator useright request queue", but still, I wish there were clear guidelines in the queue for determining when an outreach project can request these userrights. Ideally any individual administrator who grants userrights should also follow guidelines described here, but there is hardly guidance here to follow. There are a range of ongoing projects right now which regularly deputize local event coordinators to host Wikipedia meetups. Sometimes, the person who has the skill set to organize a great in-person event and help register new accounts is not a person who themselves edits Wikipedia, so I think having a history of editing Wikipedia should not necessarily be an evaluation criteria for getting the userright. Some people imagine that a long editing history should be required, but enforcing that is not entirely aligned with current outreach practices. If anyone wants to help develop more rules, then I would participate in developing them. As someone who organizes outreach, a rule that would work for me is, "If a user requests account creator rights with the approval of an outreach project, then they should get the userright on the basis of their affiliation with that project. That project should demonstrate capacity to be responsible for fixing any problems associated with the granting of the userright."

Art + Feminism 2017 is in March, and I expect again that there will be 100 meetups and 1500+ attendees almost all on one day and almost all new Wikipedia accounts which need to have someone with accountcreator userrights physically present at the event. That means that many people will need the right for this event. I would like to plan for this in advance. There are a range of other projects which do similar things, including many collaborations overseen by Wikipedia contributors in New York. Thoughts? What needs to be discussed now and in advance? Thanks. Blue Rasberry (talk) 21:22, 3 August 2016 (UTC)

• I've got one easy solution for this: WP:IRC, have some remote volunteers man an IRC channel for this event - the hundreds of local site coordinators can just join an IRC channel - who know what else they could run in to that is needed. — xaosflux ^Talk 23:34, 3 August 2016 (UTC)
• Comment: As one of the lead organizers for WP:A+F I can attest to the importance of resolving this matter. The numbers were actually about 75% higher than above: 180 meetups, on 6 continents, with 2500 participants. With that many people, we have to work as efficiently as possible. User:Xaosflux IRC is great for backchannels, but it isn't going to solve this problem. Because the intake process is so carefully structured and has to be accomplished so quickly, we need the organizers to be able to create accounts for new editors as they arrive and register for the event. Given that these events range from 15 to 600 people arriving in a short period of time, we need to empower these event organizers. Theredproject (talk) 18:18, 5 August 2016 (UTC)

  Gotcha, may still be useful to have your coordinators have a remote-live support link for anything that comes up, getting a channel ready (that can be joined from a browser) could still be helpful for you. I've got no objection to getting the tools in place for success; one issue we ran in to last year was trying to funnel large volume through WP:PERM - having some admins taking care of the processing on a dedicated event page, using meaningful log entries, and being committed to performing the clean up in a timely manner should alleviate any of the confusion from last time. — xaosflux ^Talk 18:29, 5 August 2016 (UTC)

Request userright on behalf of another person

A common usage of this userright is for an event coordinator to use it to help new users register accounts. For example, perhaps a conference or meetup is expected to have many new Wikipedians make accounts, and a person with account creator userrights helps those new users create accounts.

Many userrights on Wikipedia need to be requested if granted. A challenge with this userright is that many people who have used it historically are new users who are not trained to do much more other than create accounts. Such users may have difficulty requesting the userright. I propose that experienced users can request this userright on behalf of newer userrights, especially for temporary use at events. Letting an experienced user request this on behalf of less experienced users avoids the following problems:

• It establishes a chain of responsibility if something goes wrong. If a new user requested this and something went wrong, they could hardly be responsible. It is nice to have someone oversee temporary access to the userright, especially for new users.
• New users might not be able to navigate the request system. Some people who need this right might have 0 Wikipedia edits. This is not a right that is granted based on Wikipedia experience.
• The current documentation for this userright is in flux or years out of date. It was never up to date. There is no guidance or instructions here that making coming here useful, because people receiving the right cannot find training or instructions here for the usual usage. Currently, the rules say the right is granted to users who frequently create accounts or to people in the education program. There is no education program on English Wikipedia, so that criteria is obsolete. Users who frequently create accounts in the way described are a completely different demographic and use case from users who manage in-person events. The only way that event coordinators can get the userright is with special exemption, and it is weird to keep asking for special exemption when actually the rules just need to be updated.
• It gets reviews on this review board, rather than having the userright granted through undocumented back channels by asking an admin outside of this request queue. It is ideal to keep requests for this userright here, rather than for this board to have a reputation for being difficult and for event coordinators to need to seek other ways with less bureaucracy to achieve the same end.

Any thoughts? @BU Rob13 and Mlpearc:? Blue Rasberry (talk) 22:15, 8 August 2016 (UTC)

I'm mostly opposed to this - if you have never edited how are you expected to be familiar with the username policies enough to be creating massive number of accounts? — xaosflux ^Talk 22:18, 8 August 2016 (UTC)

I think there is a disconnect here between event organizers and people on this page. The difficulty is that the users for this userright are a different demographic from the people who are making decisions about who should get it.

I fail to recognize how username policy familiarity would be useful for a person managing a check-in desk at an event. The typical usage of this tool is merely the usual account creation signup page, except that when there are more than 6 accounts the process does not automatically fail. When I use this, I am not checking for nuance in the policy. When this userright is used, the main responsibility is to sit at a desk and keep someone from stealing the laptop. Users make accounts at the check-in desk then return to their own computer to do wiki things. The person at the desk hardly pays attention, except to maybe reload the account creation page while a line of people use it.

Xaosflux - have you ever run a Wikipedia checkin desk? I am not even sure how many different ways this userright is used. I get the idea that many people here are not imagining a registration desk at a conference when they think of this tool. Blue Rasberry (talk) 22:32, 8 August 2016 (UTC)

So the thought of an unattended - yet logged-in - page strikes me as seriously bad security practice, verging on WP:COMPROMISED. If unattended signup is truly needed, there are other avenues to persue here, such as a temporary lift of the rate limit for a specific IP address (this can be requested with the instructions here). If it is granted to a specific user account, I'd definitely be expecting that user to be doing the creations themselves (under instruction from the new user) and sending the account password via email using the relevant checkbox on the creation form. As such, yes, I would expect the user doing the creation to be vetting the account names against the username policy - and the user should have a decent enough understanding of that policy to be able to do so quickly. Other options include asking attendees to create their account at home before coming to the event, and WP:ACC to request experienced users create their account for them. This definitely should be a right granted on at least some experience. [stwalkerster|talk] 22:44, 8 August 2016 (UTC)

Stwalkerster It is really weird asking people to physically pass around their laptop to a line of strangers at in-person events, but here are reasons why this happens:

• Obviously the tool is made with intent to give physical control of a laptop to another person, because in the design of it new users are asked to create a password. It would be silly for one person to ask for another person's password out loud by voice then type it for them.
• It saves time if people type their own username, password, and email rather than doubling the labor by requiring two people for this
• If one person asks for another person's email, then the person being asked is under pressure to give it. It is a Wikimedia community value that users can register without providing an email. This is much easier to communicate in a standard way if people make their own accounts and have the option to not provide an email. It should not be expected that event coordinators could train all registration workers to communicate that Wikipedia does not require a password to register

Geting an IP cap exemption is difficult for these reasons:

• It is hard to explain to anyone how to get their IP address range
• Even in the best case it is hard to get the IP address before the event. Often the IP cap exemption can only be requested after the event starts, and that creates too much tension to have work to do in that chaotic time.
• The IP exemption is not granted in a consistent or predictable way. It is more complicated than account creator rights, and even account creator rights are difficult to manage.
• Many events are managed without any in-person experienced Wikipedian. Experienced Wikipedians need to follow documentation to request this. For completely new users there might not be a single example of anyone navigating the instructions to get the cap removed. There are too many steps.
• Any recommended process should be easier than alternatives. The process to beat at this point is asking an admin to grant account creator rights for someone. For IP cap removal to become worthwhile, one might remove admin rights to grant account creator userrights.

I would be happy to talk by phone or webcam about logistics of these things. Talk could be on wiki, but this entire issue might have too many variables to concisely express because of the clash of on-wiki practices and in-person event coordination needs. I want to find a alignment between security, Wiki hierarchy and due process, and workable event management practices. Blue Rasberry (talk) 23:36, 8 August 2016 (UTC)

(discussion about bot registration moved to own section below Blue Rasberry (talk) 15:37, 9 August 2016 (UTC))

@Bluerasberry: I thought I made my views apparent, as far as the ACC flag, the user who wants their userrights changed has to make the request, period. Mlpearc (open channel) 23:32, 8 August 2016 (UTC)

@Bluerasberry: let me address your points individually:

• Obviously the tool is made with intent to give physical control of a laptop to another person, because in the design of it new users are asked to create a password. It would be silly for one person to ask for another person's password out loud by voice then type it for them. No. No no no no no. If you actually look at the account creation form, it can work in one of two ways - either you create an account specifying a username, password and optional email address, OR a username and an email address and it sends the password by email. If you are specifically asking someone to provide their account password verbally, that account is by definition compromised, and should be blocked as such.
• It saves time if people type their own username, password, and email rather than doubling the labor by requiring two people for this Sure - this option is available to them by creating an account at home or using a data connection to do so, or by having the cap lifted.
• If one person asks for another person's email, then the person being asked is under pressure to give it. It is a Wikimedia community value that users can register without providing an email. This is much easier to communicate in a standard way if people make their own accounts and have the option to not provide an email. As above, sure, they can register without providing an email address, but they lose the capability to recover their account with a password reset later, or for others to collaborate more easily.
• It should not be expected that event coordinators could train all registration workers to communicate that Wikipedia does not require a password to register - Why not? Why, in any circumstances, should the people helping with the registration have any idea what passwords a user is choosing? It is very simple to just check that checkbox to use a temporary random password.
• It is hard to explain to anyone how to get their IP address range - If you're in a venue, ask their network/IT team. If you're in something like a cafe, ask someone to google "my ip".
• Even in the best case it is hard to get the IP address before the event. Often the IP cap exemption can only be requested after the event starts, and that creates too much tension to have work to do in that chaotic time. Per the instructions linked above, "It is highly recommended to do this several days in advance, even if you don't know the IP yet.". If it's a larger venue, ask their IT team in advance when your booking is confirmed. If it's a cafe, perhaps stop by for a coffee a few days beforehand? It just requires being a bit organised about it.
• Many events are managed without any in-person experienced Wikipedian. I'm not sure I like this, it sounds very much like the blind leading the blind.

[stwalkerster|talk] 00:04, 9 August 2016 (UTC)

Stwalkerster

• I am not going to respond to the points on which I agree, which is most of what you shared. So to those points, yes!
• No one should ever share passwords. Because account creation asks for a password, that means that it expects that one person will transfer their physical logged-in device to another person for the purpose of account creation. You said, "an unattended - yet logged-in - page strikes me as seriously bad security practice" but this is how the tool is designed. One of the two ways to make an account is as you said "create an account specifying a username, password and optional email address" which can only be done correctly by giving a person some privacy while they use a device that is being passed around without the device owner overseeing its use. I wanted to establish that physically passing a device around a room among strangers is an anticipated workflow, and not a forbidden security risk.
• I get the idea that you have not organized Wikipedia events. Examples of venues with IT teams who are incapable of providing IP ranges in advance for events are most universities, practically all museums, practically all libraries, practically all academic conferences, and in general any institution which spends a huge amount of money on IT. Examples of organizations which can provide an IP range include completely unfunded hackerspaces and the coffeehouses they patronize. It is not a reasonable assumption to assume that IP addresses will be reported on request, and it is also unreasonable to assume that if reported, the reports would be accurate. Having an event depend on the correct IP reporting is such a fragile situation and great risk of people's time. If 10 minutes are lost and there are 20 scientists in the room, then what a tremendous waste!
• Event attendees cannot register accounts at home. We push as hard as we can to get people to register in advance, but this is just impossible in many cases. Doing this anticipates both advance registration and an conveying an understanding of how useful it is to create an account in advance. With other websites making accounts is not a big deal, so people do not expect it for Wikipedia.
• "It just requires being a bit organised about it." If there is a conference coming up and you ask for an IP range they will think you are a terrorist. Asking for an IP address is exactly the kind of thing that normal people think terrorists do. It is very likely that they will collect your name and report you to security for planning to sabotage the event's wifi or worse. I am not aware of any way that an individual can write to someone and ask for the IP range and get taken seriously by event coordinators, except to make them afraid. Conceivably we could make letter head, an online explanation for backup, and other comforting support materials but overall this question is sketchy.
• "blind leading the blind" Is that not why we are all here?

Blue Rasberry (talk) 00:49, 9 August 2016 (UTC)

"Event management" bot or tool for new account registration

(this section was moved from another one because it is a separate discussion about a new tool Blue Rasberry (talk) 15:37, 9 August 2016 (UTC))

I would not even be completely opposed to letting a bot, operated by an administrator, run some sort of event check in utility to create accounts (bots can override the throttle, but not the blacklist or antispoof checks). — xaosflux ^Talk 23:12, 8 August 2016 (UTC)

Bluerasberry Specifically, the bundling of (override-antispoof) and (tboverride-account) is what my concern is, if used by people who have no understanding or acceptance of what these are for. — xaosflux ^Talk 23:05, 8 August 2016 (UTC)

Xaosflux I am not sure how a bot check in would work. Yes - the blacklist and spoof overrides are not needed for this use case. The barrier at events is allowing lots of people sign up relatively quickly. Blue Rasberry (talk) 23:36, 8 August 2016 (UTC)

Basically an end-run around the account creation interface - perhaps hosted on labs - input screen for entering information, bot account creates the account --- security would have to be discussed but could work (think of a kiosk screen (like a table touch pad) - key in your info, done - the event coordinator would be in charge of the computer, but not necessarily the process). — xaosflux ^Talk 23:50, 8 August 2016 (UTC)

More so could be part of a "event management" tool even - check in existing users as well. We may have some bot people interesting in building such an interface if it would be useful? — xaosflux ^Talk 00:00, 9 August 2016 (UTC)

@Xaosflux: I am unable to say whether a bot would be useful, because I am having difficulty understanding what a bot would do. Please let me try to repeat your question, and you can comment about whether I understand. Suppose that -

• There is an in-person wiki event including new users
• more than 6 people will register accounts, which hits the limit and no more accounts can be made from that IP address
• the problem to address is that more accounts need to be created at that event
• there are a range of potential solutions to the problem, but all of them have drawbacks

I think that you are proposing to make some kind of event management tool for new account registration. This tool would have these characteristics:

• To the end user registering an account, they have a typical account registration experience and do not see any difference
• behind the scenes, there is some tool which is making accounts in a way that does not blocked by the account creation cap
• somehow this tool is managed differently than the other options for addressing this problem, including exchange of account creator rights, IP exemption lifts, and the other workarounds
• in comparison to giving account creator rights, for example, the tool does not carry with it a liability about blacklist or spoof overrides, which is a stated concern for freely giving access to that userright
• presumably access to the event management tool would have a lower barrier to access and use than other options

Are you asking me if I would use an "event management" tool like this? The answer is yes. I cannot comment on how much work it would take to set up a tool, or the comparative cost of using other options. However, if such a tool existed and it worked in that way, then I anticipate that it would be made available routinely or universally at all in-person outreach events that could possibly have more than 6 new account registrations. In English Wikipedia, that would meet a need at an event per week at current activity levels. If any developer wants to discuss use cases for such a tool to consider its development, then I could say more. Blue Rasberry (talk) 15:37, 9 August 2016 (UTC)

Can bluerasberry be an account creator?

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.

---

@Bluerasberry: While we are on this subject, why do you still have the ACC flag ? You last used it on May 20, 2016. @Xaosflux: seems Bluerasberry still has the ACC flag, last used in May. Mlpearc (open channel) 00:24, 9 August 2016 (UTC)

Mlpearc I'm not in the account creator group - not sure what you are referring to? — xaosflux ^Talk 00:28, 9 August 2016 (UTC)

(re-ping @Xaosflux: ) Sorry, I got the pings switched, I was referring to Bluerasberry, seems they no longer need the flag, last used in May. Mlpearc (open channel) 00:31, 9 August 2016 (UTC)

 Not done See the note on my talk page. — xaosflux ^Talk 00:59, 9 August 2016 (UTC)

Pings to editors as to new location @Mlpearc: @Bluerasberry: — xaosflux ^Talk 00:48, 9 August 2016 (UTC)

@Mlpearc: I coordinate events as described at WP:Meetup/NYC. I do at least 15 of those a year plus others. Usually other people arrange account creation but I should have it if needed, because since it is wiki it is uncertain who will be at events. What do you think about people having it for as long as they regularly do in-person outreach? Blue Rasberry (talk) 00:55, 9 August 2016 (UTC)

@Bluerasberry: You haven't used the flag since May, you can request it when needed just like everyone else. Mlpearc (open channel) 00:58, 9 August 2016 (UTC)

Mlpearc May I have it indefinitely for as long as I help coordinate events? Blue Rasberry (talk) 01:01, 9 August 2016 (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.

Extended discussion from PERM

Moved from WP:PERM

Mlpearc deleted this request saying in the edit history, "The user needs to make the request". Mlpearc, I asked for a series of clarifications at Wikipedia_talk:Account_creator. If you have interest on commenting on the policy I would appreciate whatever thoughts you have. In the past sometimes event coordinators have requested account creator rights for new users who are going to be managing events. I am trying to do this here. It is difficult for me to explain the bureaucracy here to new users, and if anything, this user might come to this post and sign their name to indicate that they want the rights. If that were to happen, I do not immediately see how that saves time, increases understanding, or protects from risk of misuse of the right. Since this is a userright associated with events, can I take some responsibility for oversight here? Can anyone take oversight in such cases? Blue Rasberry (talk) 21:27, 8 August 2016 (UTC)

@Bluerasberry: Users should ask for their own rights. If the user can not figure out how to place a request, they don't need this flag. Mlpearc (open channel) 21:31, 8 August 2016 (UTC)

Mlpearc Please don't clerk PERM. Your comments are certainly welcome, but accepting/declining/removing requests is something that should be exclusively done by admins. This is one of the only areas where that's true. Having said that, Bluerasberry, permissions other than autopatrolled must be requested by the user. I have no problem with you filling out most of the request, but it can't be considered until the user at least indicates here that they'd like the right. ~ Rob₁₃^Talk 21:33, 8 August 2016 (UTC)

@BU Rob13: This allows me to clerk this page. Thank you. Mlpearc (open channel) 21:41, 8 August 2016 (UTC)}}

@Mlpearc: My apologies, stricken. ~ Rob₁₃^Talk 21:55, 8 August 2016 (UTC)

I am in a pickle. The event is two days away, so I am late in asking. This user does not have an email address associated with their account. I do not know them, but instead am a few degrees removed from the event organizers. They have not logged into Wikipedia in three months. I doubt they are anticipating a 6-account barrier at the event. I am ashamed to send them to this request page, because if they read the WP:Account creator criteria, then obviously they do not meet the stated criteria. I am not sure if they know how to navigate Wikipedia to make requests.

Would you think less of me if I just asked an admin to grant the rights, so that I do not go through this queue? I would like to do things the right way, and I want to respect community processes. On the other hand, I would like this resolved in an efficient way. It is not best to ask for rule changes or clarity in the middle of a challenge, but I drafted Wikipedia_talk:Account_creator#Request_userright_on_behalf_of_another_person to start discussion. I am not convinced that more good than harm would come from me asking a new user to come to this board and attempt to make a userright request. I feel tempted to just ask for the userright from admins who coordinate events, because that's the usual way to do this. Thoughts? Blue Rasberry (talk) 22:24, 8 August 2016 (UTC)

@Bluerasberry: Any Admin can grant the right after the user post their request. beamjockey must make the request, if you go to an Admin to end-round this request page would not be appropriate and may have consequences. Mlpearc (open channel) 22:42, 8 August 2016 (UTC)

Mlpearc Is it an acceptable outcome to you if the event is cancelled? Is there no other way? Can I not take responsibility somehow? Can the Wikipedia:Year of Science program take responsibility and promise to clean a mess if something goes wrong?

If another admin grants the userright out of process of this page, would you remove the userright or have it removed? Blue Rasberry (talk) 23:53, 8 August 2016 (UTC)

Bluerasberry The main issues I have here are mostly that a) we don't actually know that this user is even involved in this event, which could be confirmed by them simply confirming this request on this page, and secondly concerns about accounts becoming compromised, which could be easily resolved by them saying they'll keep control of their account and create accounts via email, again by posting here. Thus, responsibility for this event going south is entirely on those organising it, who - in my opinion - should at least be contactable in a reasonable timeframe. If that's not by email, then checking their notifications/talk page regularly in the days leading up to the event - I don't feel this is unreasonable in any way. If something goes wrong during the event, how would we contact them at that point? [stwalkerster|talk] 00:14, 9 August 2016 (UTC)

@Bluerasberry: I think the bigger problem you're likely to have is that a user who can't navigate to this page and make an edit here is (a) very unlikely to be able to successfully create the accounts if needed; (b) very unlikely to understand our username policy, and; (c) extraordinarily unlikely to be familiar enough with our policies to know how to run an event and instruct others on our core content policies. Why is someone who's unable to navigate a wiki holding a major outreach event? ~ Rob₁₃^Talk 22:46, 8 August 2016 (UTC)

BU Rob13 That is a fair question. The explanation is that there is no particular relationship between a good Wikipedia editor and being socially skilled at hosting in-person events. When you advocate for holding back the userright, your presumption is that the people who need it require basic Wikipedia skills. This is not the case - the requirement is to sit at a desk and give physical control of a laptop at a registration desk to people who need accounts. A laptop which is logged into a Wikipedia account with this userright can allow new users to create accounts at a screen that looks identical to the usual registration screen, except that it bypasses the 6-account limit. The skill that is required for this userright is physically sitting at a desk facing other humans, greeting them, and inviting them to fill out Wikipedia's registration form. It is not required that the user explain anything about Wikipedia.

You might want more information, and more information is at Wikipedia_talk:Account_creator#Multi-site_events. I would appreciate comments there.

To respond to your points (a) to operate this userright, a user needs to login and then reload the account creation page after each personally who physically uses the laptop to make an account. I know this works because it has happened dozens of times. (b) correct, they will not understand username policy. I wish that blacklist and spoof rights were not bundled with this, but there is no other way to get past the 6-account limit except to get a bundle of rights. I am not aware of any event at which blacklist or spoof override rights have been abused among the thousands of accounts which have been made in this way, so I am not sure that the fear of risk is realistic (c) the person who has account creator rights has to physically be present. People joining in by camera for training need not be. Regardless, many very new and inexperienced Wikipedians like hosting events. The old education program did this 1000 times and other programs since this have done this for at least several hundred events with very inexperienced users.

I would be happy to talk with you by phone or video if you want more information about running in person events. I help with the events as described at Wikipedia:Meetup/NYC/Event_archive#Past_events. Blue Rasberry (talk) 23:48, 8 August 2016 (UTC)

@Bluerasberry: You say that "but there is no other way to get past the 6-account limit except to get a bundle of rights". This is factually untrue; indeed, stwalkerster pointed you directly to a page that outlines a procedure for just that - allowing an override of the 6-account limit on a per-IP basis that doesn't require granting of user rights. This is the preferred way to handle an editing event. (I saw that you also asserted that asking a venue for their IP addresses means they'll think you're a terrorist; I consider this laughably absurd, and unless you can provide evidence of this actually happening, this assertion screams of a red herring.) You also say that "The old education program did this 1000 times and other programs since this have done this for at least several hundred events with very inexperienced users" - just because other people do it doesn't make it correct. As stwalkerster pointed out, allowing others to use someone else's account for any purpose is a significant information security failure, and anything you assert otherwise doesn't change this basic fact. You also assert that, "I am not aware of any event at which blacklist or spoof override rights have been abused among the thousands of accounts which have been made in this way" - this is not proof that it has never happened, nor again does it change the basic fact that the rights are abusable in such a manner. You want us to consider that our process is broken and needs to change - I think it's only fair to ask you to consider the same about your own processes. --FastLizard4 (talk•contribs) 01:43, 9 August 2016 (UTC)

FastLizard4 I agree that the situation is absurd. I am not sure what else to say, except that when non-tech people get asked a tech question they panic. It is difficult to get access to the tech managers at venues and directing the question to the front desk is unlikely to return a quick resolution.

It seems like we both have perspectives. As someone who regularly organizes events, my experience has been that going through all the steps to get IP exemption is difficult in New York City because of challenges in explaining technical needs. If it is helpful, I can describe what would make these requests easier. If the community had available a draft text explaining the need, describing how to get an IP address, and how to verify that asking for an IP address is a legitimate request, and if this text were formatted nicely on a letterhead that conveyed authority, and if this sort of document could be sent as a PDF, then the barrier to making this request would go down. There is all kind of infrastructure that would be useful to create to make wiki events have a bigger impact, but right now, the surest way to make an event go well is to have people there with account creator userrights. If the venue gives the wrong IP address and no one has those, then the event is sunk.

I am unable to say how risk should be managed, but in general in the Wikipedia community, lots of risks are taken to give people access to benefits. I regret that the tool event organizers need is bundled with tools of no use for that purpose, but if there is already trust in a person to do public presentations about Wikipedia, then they should also somehow get the tool they need to do their project. There are all kinds of concessions that could be made. For right now, I need a path to clear an event organizer to get the tool. The tool exists to be granted to some people and English Wikipedia does not even have workable documentation for getting the tool to people who organize events. I would talk more - I hope this tool's review process can develop. Blue Rasberry (talk) 12:58, 11 August 2016 (UTC)

@Bluerasberry: Disregarding the technical support venues (should?) provide, is there some reason why you simply can't, during setup for the event, use a computer to navigate to one of the multitude of websites that returns your public-facing IP address, and provide that to an admin for ratelimit exemption? And on the off-chance the venue's IP address changes or they have multiple, simply repeat as necessary? --FastLizard4 (talk•contribs) 02:11, 12 August 2016 (UTC)

FastLizard4 our admins can't remove rate limiting by IP, this has to be done by sysadmins - it is not "easy" to do rapidly. — xaosflux ^Talk 03:23, 12 August 2016 (UTC)

FastLizard4 I agree with Xaosflux, unless something about this process changed. There is no need for any wiki admin to set up an IP cap exemption because anyone who can write the patch can do it. The request system is actually a place to for a non-technical person to request the writing of the patch, but even after that, the patch has to be deployed and it takes one of the sysadmins to do that. The usual schedule for deployment is weekly so with any request either wait a week or get on IRC and beg for anyone to deploy it. There seems to be a public request system at wikitech:SWAT deploys but it makes no sense to expect a brand new user to coordinate the multiple people with technical skills who are involved in this. A non-technical person new to Wikipedia can need assistance from 3-5 different people to do this with a week's notice. When an event is happening then a solution needs to happen in minutes, and IP cap lifts are something that take too long and are complicated to request. An alternative is to give them account creator userrights, which can be done by any admin instantly. If you know of more up-to-date documentation on this then please share. I hardly understand the IP cap lift process. Blue Rasberry (talk) 10:46, 13 August 2016 (UTC)

@Bluerasberry, Xaosflux, and Stwalkerster: My sincere apologies, I had intended to reply, but I plain forgot. Yes, you are correct, I misunderstood the documentation and I withdraw the point about requesting ratelimit exceptions as necessary. However, I did think of a compromise solution that may be amenable to all parties involved, though it may be something of a paradigm shift from how things "normally" work on Wikipedia.

Basically, my idea is to create a new userright, though it's really more of a user role. We'll call this new userright "Editathon Checkin" for the purposes of my proposal, though I imagine there will be a better name for this going forward if we decide to pursue this. Basically, leaving the current Account Creator right as is and with the current restriction to trained ACC members, education outreach folks, etc., create a new Editathon Checkin user right that can be assigned/revoked by admins. The idea I have is to have this right combined with role accounts just created for the purpose of creating accounts at editing events. These role accounts should be granted the Editathon Checkin right, and should have usernames indicative of their purpose (e.g., "User:WikiConference North America 2016 user creations"). The Editathon Checkin userright would grant the ability to create accounts and bypass the account creation ratelimit, but not the ability to override the titleblacklist or to override antispoof. This addresses the concerns of only allowing properly trained users to use these abilities, while allowing one to bypass the ratelimit. But, furthermore, the Editathon Checkin userright should revoke all other permissions, including the ability to edit - or, to put it another way, an account with the Editathon Checkin userright should only have the ability to read pages, create accounts, and bypass the account creation ratelimit, explicitly revoking everything else. This addresses security concerns by ensuring that such accounts may only be used to create accounts, and no one could do anything else with them. The use of a role account with a name identifying the event also serves as an audit trail for the purposes of abuse tracking. How does this sound to everyone? --FastLizard4 (talk•contribs) 03:53, 27 August 2016 (UTC)

This would work and satisfy many concerns stated. Mlpearc (open channel) 04:11, 27 August 2016 (UTC)

FastLizard4 I am not sure. The point on which I agree is that the need for managing events is a userright or tool which allows account creation without the blacklist or antispoof rights. I am not prepared to advocate for the best way to do this. Establishing role accounts or group shared accounts sounds controversial to me. If that became a norm, then that would set a precedent for a complicated range of uses, including the establishment of role accounts for organizations, a trend to set up one-day Wikipedia disposable accounts, a community of users with multiple Wikimedia accounts, and a tradition of designating certain human-managed processes as being so unusual that they cannot be managed by a user's personal account. All of these things could happen, but I would not lightly recommend doing so many things that clash with usual practices without talking things through with others. I expect that there are a few dozen people who could each spontaneously start reciting opinions about this for an hour each, all of whom would have a concerned perspective. The workflow you proposed is valid, but I also think that many other people would question why anyone would choose that one over any of the many alternatives.

I can say that I am seeking a benefit and not a particular process. I would prefer a simpler process over a more surprising one, but I acknowledge the need to do complicated, counter-intuitive things that other websites do because Wikimedia projects have their own security problems. The most certain thing that I can say is that I would talk through the process more with anyone who wanted to discuss the issue. I can also get as much community comment into this as anyone else can, just because I live in New York and more Wikipedia events happen there than any other single city anywhere. There are a lot of people in New York who have in-person experience with this challenge and who each have had in-person discussions about this with 30+ other people who have organized in-person events. For tech decisions like this it is often difficult to get user feedback, but I think the time is becoming ripe where there is a userbase who could give thoughtful feedback on any potential solution proposed. What should happen next to advance discussion? Blue Rasberry (talk) 20:38, 27 August 2016 (UTC)

@Bluerasberry: Well, the role account in my workflow is mostly so there's a way CheckUsers can check the origin of an account easily and to prevent the use of a potentially unmonitored (or not closely monitored) check-in/account creation kiosk for any purpose other than account creation, but of course it's not required as there are other potentially valid approaches. The core component of my proposal is the user right that grants a ratelimit bypass without allowing overriding antispoof or the username blacklist; if we don't go with the role account approach, that reduces the "Editathon Checkin" userright to simply granting the ability to bypass the account creation ratelimit without changing/granting/revoking anything else. This does leave the concerns, though, of allowing others to gain access to a user's account, which would seem to go against WP:COMPROMISED and could possibly already be considered a shared-account scenario. (Basically, in my mind, if any user at any point allows another person to do something with their account without sitting between the other person and the keyboard, if you will, that qualifies as account sharing with all its associated security risks and policy implications.) On the other hand, we could combine the proposed userright with some kind of external OAuth application to mitigate the abuse potential, or we could play with how granular we want the role accounts to be - for example, instead of requiring a role account per event, requiring each event-running group to have a role account which can be reused between events. But yes, wider input would definitely be helpful at this junction. I imagine WP:VPP or WP:VPR would be the appropriate venues moving forward for wider discussion of these ideas with the community (though I'd like to see if I can't get more feedback here from others as well before continuing). --FastLizard4 (talk•contribs) 03:26, 28 August 2016 (UTC)

FastLizard4 I confirm support for "user right that grants a ratelimit bypass without allowing overriding antispoof or the username blacklist". Here are the ways which have been discussed for managing this right.

1. Grant it like a typical userright (default expectation). A challenge with this is that it continues the conflict that the account creator userright has always had with WP:Compromised.
2. Grant the userright only to a role account. A challenge with this is that at meta:Role account there is not much precedent for any Wikimedia project to manage role accounts without social conflict.
3. Grant the userright to a bot. The bot would then create accounts through an interface which simulates the existing interface, but somehow cannot be abused in ways that the userright could be. This idea has been raised but not developed.
4. Develop existing infrastructure, like the noticeboard and other request systems for crowdsourced human response. This option has so far had the most support overall but I am not sure that any event coordinators support this, and they are the ones who need the service.
5. Disallow new Wikipedians from hosting Wikipedia events, and grant the benefits of account creation only to experienced Wikipedians.
6. Give the current account creator userright indiscriminately to anyone hosting events
7. Give the current account creator userright indiscriminately to anyone approved by an event coordinator, like an education program

I can go with any of these except "disallow new Wikipedians from hosting events". Are there other options here? Blue Rasberry (talk) 18:21, 31 August 2016 (UTC)

Userright for event management

Suppose that someone is convening a Wikipedia event in which new users will register new Wikipedia accounts for the purpose of editing Wikipedia, such as in an WP:EDITATHON. Here is a narrative drafted as some premises associated with the concept of an editathon. Is there anyone who doubts any of these premises?

1. Wikipedia in-person events are usually good.
2. The Wikipedia community should encourage people to organize Wikipedia events.
3. Hundreds of Wikipedia events have been organized, and to date, there is no broad Wikipedia community recognition of harm coming as a result.
4. At Wikipedia events, new users may be invited to register accounts.
5. Wikipedia currently enforces a 6-account limit per day for a given IP address.
6. If more than 6 users try to create accounts, then all users beyond the first 6 are blocked by the limit.
7. Typical event venues have a single IP address available for connecting to the Internet.
8. The "account creator userright" is a right granted to selected users which allows that user to create any number of accounts from a single IP address.
9. If people at an in-person Wikipedia event has the account creator right, then those people can make accounts for every person at an event if more than 6 want accounts.
10. It is customary at in-person events to plan for the challenge that more than 6 users will need accounts.
11. There are multiple ways to address the challenge, including having people with the account creator right or other ways.
12. Among event organizers, having people with account creator rights is the preferred way to address the challenge.
13. Among event organizers, the alternatives to having people present with account creator rights are problematic enough to discourage some events entirely.
14. It takes no special expertise for a person to operate the tool for which the account creator right grants access. The process is comparable to hosting a registration desk.
15. A new user who has never edited Wikipedia will usually be an excellent operator of the tool associated with the account creator rights.
16. The social skills associated with event hosting are not necessarily within the same skill set as being a Wikipedia editor. Someone who has never edited Wikipedia can host an excellent in-person Wikipedia event.
17. An event host is a capable user of the account creator tool for registering accounts for groups of people at Wikipedia events.
18. Granting the account creator userright is a liability because the userright can be abused.
19. The Wikipedia community has never identified a case in which the account creator userright was abused by someone using it for event registration.
20. The liability associated with the account creator userright is worth recognizing.
21. Historically, the way that the right's liability has been managed for event is that anyone hosting an event may have the right for the duration of the event and some time before and after.
22. Historically, the account creator right has been granted for many reasons, including a user having any affiliation to a larger Wikipedia outreach program.
23. The number of in-person English Wikipedia events which host more than 6 new users is increasing. Perhaps there were 200 of these events globally in 2013, and perhaps there were 1000 of them in 2015.
24. More in-person events creates increased pressure to have good Wikipedia policy
25. It seems like there is a conflict between people interested in hosting Wikipedia outreach events and people who want increased Wikipedia security.
26. People who host outreach events want to register more Wikipedia users, even if that creates risk to security.
27. People who want increased security wish for more control over account creation tools, even if that means discouraging new users from registering accounts.
28. Ideally, everyone who attends any Wikipedia event should be able to register without burden beyond the normal registration process, and security should not be compromised in the process.

If anyone cares to endorse this narrative of things then that would be helpful. If anyone objects to any part of this then speak up, because I intend to continue passing this narrative around as event management policy is developed. I numbered all this to try to identify parts which anyone might dispute. Over time, I think I have heard arguments on every numbered item here, so I think all of these statements are controversial but here they are as I see them. Blue Rasberry (talk) 20:03, 1 September 2016 (UTC)

 Comment: I don't see any problem, every editor (I believe) has been granted the flag when it was needed, maybe an account(s) just for in-person account creation, and a password could be given by any admin (after a password reset). Mlpearc (open channel) 21:07, 1 September 2016 (UTC)

New feature in development - automatic expiration of user rights

There is a custom of assigning account creator rights for a limited time. Right now, this means that an admin grants the rights, makes a manual note somewhere to remove them later, then manually removes them after the time has passed. This system depends on human notetaking and is subject to user error.

In the recent meta:2016 Community Wishlist Survey there was a vote for all sorts of features. The top 10 features are going into development now. One of the 10 selected features is Allow user rights to expire automatically. Perhaps in some months this feature will be developed and made available. When it is, then I expect the request process for this user right to change to use this feature. Blue Rasberry (talk) 17:55, 16 December 2016 (UTC)

Using off-wiki tools to register new Wikimedia accounts

I have previously mentioned here that I coordinate Wikipedia outreach events. Here in New York City we do about 2 in-person events a week. Neither the Wikimedia Foundation nor the Wikimedia community invests much money in these, but the hosts do, and the cost of all these events in NYC and elsewhere is a cause for many people looking to their success. To give some idea, reserving a room in NYC with wifi and coffee for 25 people for a two hours easily costs USD $500. Slightly more complicated events have costs that jump to $2000+, even if it is free for attendees and is not costing the Wikimedia community any funding. If there is an organizational partner, like a small branch of the city library involved, then there are extra expenses and someone pays. Events always have Wikipedia community members present to provide support, usually by explaining how to contribute to Wikipedia. Somehow when someone provides a space, and there is coffee, and there is staff presence from a museum or library, the event seems more serious and Wikipedia contributors want Wikipedia to work at its best. This seriousness is a contrast to on-wiki support, which has no urgent scheduling commitment and in which no volunteer is strongly compelled to do things like be on call at a certain time to provide support.

Some people are looking to circumvent the on-wiki account creation process because it is so likely to fail. "Failure" means that new users attend an event but have difficulty creating a Wikipedia account. I would prefer to manage wiki-registration on wiki but the conversation has been difficult here. Online contributors tend to feel that it is okay to have time delays, while in-person wiki organizers expect account registration to be an instant simple process.

It might happen that this

• meta:Grants:Learning_patterns/Six-account_limit

directs people to an off-wiki registration tool for events. The standard practice would become to register people in an off-wiki tool rather than ask for permission from the Wikipedia community to register groups.

I have mixed feelings about this because I want people to use the on-wiki interface because I like community involvement in everything. However, if there are social barriers to that, then off-wiki software can manage the registration in other ways. The social barrier to asking for permission on wiki to register groups is high. I do not feel safety in the current policy for reasons stated in discussions in the archives. In the current system, a high profile planned event with 50 people in attendance might be barred from registering accounts if a pseudo-anonymous volunteer fails to grant permission through the odd request system here. There is a general bias here against in-person events, and this tool never was designed with event support in mind.

There are like 50 people in off-wiki conversations about this in different places. I have no capacity to coordinate this massive international multilingual conversation which involves multiple Wikimedia projects in multiple languages, and there is no central point of contact or anyone managing this problem. I thought I would share the chatter. Honestly I do not know where conversation will go, but I can say that the staff and financial cost of events is a driving force for wanting a solution. It is really upsetting for a Wikipedian to organize an event and sort lots of details, only to find that eager contributors at an event have challenges registering accounts. The available options have a high chance of failure.

I hope to keep the sympathy of people at this board for the need to get Wikipedia accounts to people at events. Blue Rasberry (talk) 16:15, 21 October 2016 (UTC)

• Cyberpower678 - what are your thoughts of adding some sort of interface to the Account Creation Tool Server to do "event registrations", I'm thinking high level: An event coordinator registers their event with ACC with dates and gets some sort of "event password" - then using a new feature can use that interface to create accounts that would get funneled to an account creating bot account. Possibly even adding Add (confirmed) to users access to the 'account creator' user group. — xaosflux ^Talk 14:36, 12 January 2017 (UTC)

  I don't think this would be good for ACC. It would require a rewrite of some parts, and control of a bot that has admin access. I don't have direct access to ACC because it contains sensitive information and as such is only limited to 3 people. I do imagine an interface can be built fairly quickly that can be geared towards automated account creation for event purposes. I'll run it by ACC devs into creating a separate tool for events. If something like this were created, it would need certain security measures to prevent abuse, especially if the bot is immediately granting confirmed access to these new accounts. My idea for such a tool is that an event is registered to the tool which requires initial approval, from other admins, and flagged as approved on the tool accordingly. It's given a start time and an end time for which the tool will grant account creations. Approved events will have an event code handed to the registering organizer. The organizer will then hand the code to the attending users at the event. These users will then register for an account, providing their email, name, and requested username, and supply the interface with the event code. The interface will validate the code, and either create the account associating the account created to the event, or deny the request. An adminbot can create the account immediately and grant confirmed access if desired.—CYBERPOWER (Chat) 15:22, 12 January 2017 (UTC)

  Bot would only require 'account creator' access not admin access - but still sensitive. — xaosflux ^Talk 16:17, 12 January 2017 (UTC)

  With "current" settings it would require admin, but I think we'd have general support for giving the account creator group the ability to add (but not remote) 'confirmed' access to users. — xaosflux ^Talk 16:18, 12 January 2017 (UTC)

  I don't think it's advisable to grant that ability to account creators. It could be open to abuse by the existing account creators not in ACC.—CYBERPOWER (Chat) 19:25, 12 January 2017 (UTC)

I appreciate whatever you can do. Thanks for commenting and let me know if I can do anything to indicate the community support and need for this. Wiki outreach organizers need a practical solution to be able to register people at in-person events based on in-person social conversations and interpersonal relationships instead of keeping a system that favors only event organizers with deep wiki editing experience. The skills to plan a social event do not always overlap with the skills to edit Wikipedia and negotiate rights on talk pages.

There are lots of models and maybe this password model could work. If trusted Wikipedians could be granted some password which allows event organizers to register enough accounts at events then that could work. Whatever happens, there needs to be a path for someone to be able to host in-person events and register everyone in attendance. Blue Rasberry (talk) 16:20, 12 January 2017 (UTC)

Editing on mobile, excuse typing I actually think this would be a reasonable amount of work but not too hard to implement on the new rewrite of the ACC tool that's currently in code review by @FastLizard4:. For those of you (un)lucky enough to have used WebEx, this is my basic idea - a password would be created by the event organizer which then is used by all attendees in their account request. The organiser can then log in to a cut-down version of the tool (not showing private data) and approve/deny requests as necessary, these being created with the organiser's account via OAuth. This allows the organiser to take responsibility for these as necessary, and give the ability to escalate requests to the main team when unsure etc. It also gives a better audit ability as to where requests came from, and allows the private data to be kept more secure than what I've heard these events are like previously. Note this is an initial idea, kinks might not have been fully worked out in it. [stwalkerster|talk] 17:41, 12 January 2017 (UTC) Edited for spelling [stwalkerster|talk] 19:23, 12 January 2017 (UTC)

I am familiar with WebEx. I understand what you are describing. Yes, from a user perspective that system could be applied to events in the way you just spoke. Compared to the current process this seems easier for users, and if you say that this system also increases security, then that is a win-win proposal. Blue Rasberry (talk) 17:52, 12 January 2017 (UTC)

It's up to stwalkerster on whether or not to implement this, but if this can be routed to an account creating bot, it would avoid the need to assign and remove account creator flags from the organizing user. Also start and expiration times should be given to these approved organizers. The code only is valid for the duration of an approved window of time, and requests made outside that window end up in the standard ACC queue, or get declined. After 7 days, or whenever the data purge script operates, the special organizer account becomes disabled/deleted and all requests become accessible in the standard queue. As a side note, we really outta remove password logins in favor of OAuth.—CYBERPOWER (Chat) 19:25, 12 January 2017 (UTC)

• @Bluerasberry: See https://github.com/enwikipedia-acc/waca/issues/281 —CYBERPOWER (Chat) 21:10, 12 January 2017 (UTC)

I did my best to post comments and show support. I could do more if that is useful.

• I commented on the proposal described above
• Suggestion - combine with WikiEduDashboard, which is an imagining of combining this interface with an existing popular workflow

Blue Rasberry (talk) 21:49, 12 January 2017 (UTC)

@Cyberpower678, Stwalkerster, and FastLizard4: Communication can be challenging and I want to do my best to establish mutual understanding. To back up from the posts on github, I posted an example case below about a typical event and the problem encountered. I am wishing for a way to lower the barrier to make those kinds of events possible, or otherwise, a statement of pushback on those kinds of events so that I can know what the problem is.

Maybe we are already on the same page but by reading development specs I could not quite follow. The example below is supposed to be a practical case that is prohibited now but that I wanted to make more possible by some method in the future. Blue Rasberry (talk) 23:32, 17 January 2017 (UTC)

Is there a Special page that will list the users that I have created?

Not specific to the discussion of WP:Account Creator, but is there a Special page that will list the users that I have created? I am hoping there is something that can take a date range. This would be useful in tallying the number of new accounts created at "Learn to edit Wikipedia" workshops or edit-a-thons. Peaceray (talk) 06:04, 23 February 2017 (UTC)

Hi Peaceray, this page will tell you that. Callanecc (talk • contribs • logs) 09:33, 23 February 2017 (UTC)

@Callanecc: That's perfect! Many thanks! Peaceray (talk) 16:33, 23 February 2017 (UTC)

Do passwords expire?

Hi - I received an email from a student who said that they tried using the password and account name that they were assigned via the account creator process, however when they tried to log in recently they were told that the password was incorrect. Do passwords expire with account creator? There's nothing on the email about this. The email itself is from October. Shalor (Wiki Ed) (talk) 00:52, 28 November 2017 (UTC)

@Shalor (Wiki Ed): checking on this, in the meantime can the user use the "forgotten password" utility to reset it, as they have access to the email address? — xaosflux ^Talk 01:18, 28 November 2017 (UTC)

@Shalor (Wiki Ed): the mediawiki default value for this is 7 days, and I don't see our configuration value set to override it. — xaosflux ^Talk 01:21, 28 November 2017 (UTC)

• I'll see if the password reset option will work for them - hopefully it will! I will definitely make sure to let teachers know about the expiration date for the passwords. I'd expected the students to set up their accounts once they have the emails sent, since they have some review content that they need to go over and they also have to register on the student dashboard, but some seem to have waited until the last minute. I don't suppose that there's a way to put that in the email that gets sent out? Shalor (Wiki Ed) (talk) 17:33, 28 November 2017 (UTC)

  @Shalor (Wiki Ed): it should. I've udpated MediaWiki:Createaccount-text with the expiration information. — xaosflux ^Talk 18:29, 28 November 2017 (UTC)

• Thank you! I know that the email a student sent me didn't have any information about the expiration, so that will definitely be helpful! Shalor (Wiki Ed) (talk) 15:35, 29 November 2017 (UTC)