Wikipedia talk:Requests for comment/Event coordinator proposal

Draft

@Xaosflux, SoWhy, Kudpung, MER-C, Lirazelf, Bluerasberry, and Stinglehammer: I've created this as a rough draft of what a proposal for an event coordinators user right might look like and the guidelines for granting. I'm not the best with technical details, so if I am missing something about the event dashboard, etc. someone feel free to make changes. TonyBallioni (talk) 15:38, 19 March 2018 (UTC)

Thanks TonyBallioni, I'm bookmarking this & will come back to you tomorrow. Appreciated! Lirazelf (talk) 16:07, 19 March 2018 (UTC)

I like it but it might just need a few tweaks. Anyway, I'd certainly support it. Kudpung กุดผึ้ง (talk) 16:27, 19 March 2018 (UTC)

• Yes, this functionality needs to be available to event coordinators. The user right you are proposing sounds exactly like the userright associated with the old education extension. See Wikipedia:Education_noticeboard#NOTICE:_EducationProgram_extension_is_being_deprecated for the current discussion about that software being wound down. I recommend that you move this proposal out of your userspace and into something more permanent, like either the education noticeboard, the account creator board, the ACtrial, the Programs and Events Dashboard space on meta, or discussion about the programs and events dashboard. All of these are related. Blue Rasberry (talk) 16:54, 19 March 2018 (UTC)
  • I prefer to draft proposals in my userspace and then copy or move them to a new location, and this would only be proposed if ACTRIAL were to be made permanent. I don't see why this would need to be on meta as it is at the moment only affecting en.wiki. I think if we need to have an RfC on it, WP:VPR would be the best place. TonyBallioni (talk) 16:57, 19 March 2018 (UTC)

@TonyBallioni: I am anxious about losing the community discussion here because what is on userpages is not as stable as in Wikipedia: space. May I ask you to commit to move this somewhere very soon? Otherwise I would like to cut/paste this to elsewhere. I am keen to show this to others. I do not want to encroach on your plans for moderating the conversation but this is at the center of many groups' interests. Blue Rasberry (talk) 15:11, 20 March 2018 (UTC)

@Bluerasberry: I'd prefer we get some form of stable proposal first before it is moved anywhere else. Having a wide discussion on the basic text before it is even agreed to what the working proposal will be in one of the quickest ways to make sure a proposal fails in my opinion. I'm fine moving it to project space once a basic working text is established that people seem happy with, but I also don't think an RfC should be run until after the current ACTRIAL RfC is complete, as it would be pointless to make these changes if that change is not accepted. TonyBallioni (talk) 15:12, 20 March 2018 (UTC)

@TonyBallioni: I continue to be anxious about losing this talk page discussion or to invite people to a userpage discussion. I appreciate your convening this conversation and I do not want to lose it. I am not suggesting that you make a live proposal now but I do not like the idea of this being in your space and moderation when it is of general interest. Blue Rasberry (talk) 15:22, 20 March 2018 (UTC)

A few comments: actually as far as account creating goes for events, I think they should only get "(noratelimit)" - if people pick names in collision with the antispoof or blacklist, they should be asked to pick a new name. I don't think I've ever seen a perm request for events that needed to override these, and we routinely ask people to not use these features. Also, I'd love to not have to do this at all, but funnel everything through the program and events dashboard - and let it make the accounts. — xaosflux ^Talk 18:39, 19 March 2018 (UTC)

As far as +confirmed goes, if we go this way it seems fine - but I suggest they always set these with expiration: 10 days/2 weeks, etc. That way we don't clog up that group with people that never come back. If we can automate it in to PEM, then having that set confirmed+10 sounds good too. — xaosflux ^Talk 18:40, 19 March 2018 (UTC)

Another few comments:

1. I don't see the need for eventcoordinator to have all the permissions associated with accountcreator. In particular, the abilities to override the anti-spoof check, and the blacklist check. There may be occasions where those abilities are useful, but creating an account for somebody who forgot to register before an event isn't one of them. They are there in front of you and if they pick an unsuitable name, you just ask them to pick another. However, bypassing the 6 accounts per 24 hour limit is vital for those odd occasions where it's needed.
2. Having +confirmed expire is a good idea, as it avoids clogging up that group when the editor will be autoconfirmed after no more than 4 days anyway. In fact, I can't see any reason why the flag shouldn't expire as early as 4 days after the event, as any participant is bound to be autoconfirmed by then.
3. Why should I or any other event coordinator need to keep asking for the eventcoordinator flag? What purpose does expiring it serve? Either we are going to be trusted to grant +confirmed and understand the circumstances, or we're not. Am I really likely to go around adding +confirmed to random unconfirmed editors between events? If someone is inactive for an extended period, then I can see a security value in removing the right, just as as we do for +sysop, but I don't see the value in adding one more rubber-stamping job that I need to remember to do every time I run an event. --RexxS (talk) 19:22, 19 March 2018 (UTC)

All good points. On point 3, we currently only grant account creator temporarily but there’s a discussion to make certain allowance for that now. I think the distinction being drawn would be between a librarian who doesn’t have much on-wiki experience running an event and yourself. The former we wouldn’t want to have permenantly. Whereas we’d have no problem letting you have it. I’ll tweak in a bit to make this point. TonyBallioni (talk) 19:32, 19 March 2018 (UTC)

• I suggest modifying line #3 in the proposal, indicating that Admins should give the user right to experienced event coordinators permanently, and perhaps give it to first time or one-off event coordinators on a temporary basis initially. I think that we should also require that the user applying for the right be extended confirmed, as we need users here to have at least a decent amount of experience editing the wiki (this was one of the concerns about the first failed RfC, many of the accounts in the 'account creator' group were themselves not experienced enough). Your comment about "a librarian who doesn’t have much on-wiki experience running an event" being given this user right is exactly the sort of thing that might tank this RfC I think. Such a user doesn't have the experience to guide new editors about notability and such forth and thus guide them away from unsuitible topics. For these users, giving the user-right on a temporary only basis might suffice, but I can see a number of pile-on opposes originating from the potential for this user right being given to users with a lack of wiki experience. — Insertcleverphrasehere ^{(or here)} 22:35, 19 March 2018 (UTC)

+1 there. Anyone without 30 days/500 edits is not qualified to teach others how to edit or trusted enough to not hand out Confirmed like candy to trolls at halloween. Legacypac (talk) 22:53, 19 March 2018 (UTC)

@Tony: Something to think about: at Wikimedia UK, we run the Training the Trainers programme. The course takes place over two days and has personal one-to-one feedback afterwards. In addition, we always try to ensure that newly accredited trainers get a chance to work with an experienced trainer when they start delivering training. That represents a quality assurance process that gives me confidence in the trainers who volunteer on behalf of WMUK. When an institution contacts the WMUK Office to set up an event, we ensure that we supply a trainer. So, the way I'd view your hypothetical librarian is that either they are already an accredited trainer, or they will be working with one. I wouldn't envision granting eventcoordinator in any case to someone who didn't already have experience in the role, other than in exceptional circumstances. Now, I know that what happens in the UK doesn't necessarily happen everywhere, but the idea of having quality assurance for running events (and hence for granting this user right) is good practice we could encourage. --RexxS (talk) 22:51, 19 March 2018 (UTC)

@Legacypac and RexxS: There are many Wikimedia outreach programs which recruit totally new editors to do outreach. The skillset which makes a good wiki editor is distinct from the skillset for hosting a social event. Many good wiki editors should not host or train, and lots of people who host and train do almost no online wiki activity.

I collaborate with Wiki NYC where we confirm about 100 workshops a year and have awareness of more. Event hosts who do not edit wiki often include subject matter experts, people who manage event spaces, and people who are highly sociable community organizers. Please reconsider your firm stand saying that the only way to throw a party is to have a Wikipedian organize it. There are other ways to have successful Wikipedia editing events in which a host with no wiki experience can get new users to sign up and contribute productively. In NYC we see this regularly and often. Blue Rasberry (talk) 15:18, 20 March 2018 (UTC)

@Lane: I'm sorry I gave you the impression that I insist on only Wikimedians organising events. I don't take that view, but I do strongly believe that a capable Wikimedian needs to be involved in the delivery. We're all painfully aware of the problems caused in the past when professors set their students the task of editing Wikipedia without any involvement of Wikimedians. I'm glad that NYC has successful events, but I'd worry about any event that didn't have the input of somebody experienced enough to be able to guide the participants through the complexities of WP:V, WP:N, WP:OR and WP:WEIGHT. Without some informed guidance, it is all too easy for participants to end up with the bitter experience of seeing their hard work rapidly deleted or reverted. --RexxS (talk) 17:29, 20 March 2018 (UTC)

@RexxS: I know that bad experiences can happen without experienced Wikipedians, and it is always preferable to have one, but frequently events happen with only new editors. Check this out -

Art+Feminism 2018, right now 240 events with 2300 editors who created 1000 new articles and edited 6000 total. For most of these programs, the organizer is a new Wikipedia user who learned what they know from watching some how to edit Wikipedia videos. Check out the 2016 and 2017 campaigns also. This model of outreach is not just for A+F, but also is the most common Wikipedia model for outreach to schools. These outreach programs might not teach any of the rules you list.

Wikipedia operates on a massive scale and recruitment can have unexpected outcomes. In NYC and in most places in the United States we usually omit teaching WP:5P, Wikipedia:Core content policies, Wikipedia:Trifecta, and other rules. It is hard for me to summarize the culture of training here but it is different from the UK. I cannot speak to the relative cost / benefit outcomes as compared with the UK but the US is more eager to invite large groups of people to edit with no experienced Wikipedians moderating. So far as I know, Wikimedia UK would say that this outreach strategy is crazy, but then Wiki UK has paid staff whereas the entire US has to operate on a nearly $0 budget. Blue Rasberry (talk) 18:12, 20 March 2018 (UTC)

I'd add my support to RexS's third point, having to repeatedly ask for permission seems unnecessary. From my own work I can also forsee situations where temporary access would be a useful option to have. Lirazelf (talk) 12:32, 20 March 2018 (UTC)

• Confirmed to expire in 10 days should be 5 days. Any account created within 5 days before or the day of the event that makes 10 edits will be autoconfirmed within the 5 days anyway. Legacypac (talk) 22:59, 19 March 2018 (UTC)

• Comments--
  • Over-riding the anti-spoof check and the title-blacklist check are meant to be executed by us, account-creators, in very specific cases, after a series of checks.I strongly fear that unbundling these two features to event coordinators is not helpful by any means as it is not prudential to expect them to be aware of the concerned guidelines and the right may be non-intentionally abused to create user-names which are generally non-permissible.The only flag that they need is the one to override the rate-limit on account creation.~ Winged Blades^Godric 02:54, 20 March 2018 (UTC)
  • I also concur with ICPH's idea about the requirement of a minimum decent level of experience.My evaluation of the major editathon-fuck-ups in the recent past almost always point to inexperienced leads running the show and......But, discretion is an inherent factor at PERM and exceptions can be made in certain situations.~ Winged Blades^Godric 02:54, 20 March 2018 (UTC)
  • I also concur with Rexxs that that the right ought to be permanently granted to experienced outreach/editathon-conductors.But, first time apppointees ought to be temporally granted unless and until they have a track record to speak for themselves.~ Winged Blades^Godric 06:41, 20 March 2018 (UTC)

• I think the proposal is a good way to go forward, taking into account the proposed changes above, especiall those by Rexxs. I also would strike 4. Event coordinators should only confirm users who are physically present at an outreach event. Not only does it needlessly prevent trusted editors from confirming users they know personally but are absent but it also prevents virtual outreach events from happening. If I hold such an event over Skype, why should it be treated any differently? Regards SoWhy 08:46, 20 March 2018 (UTC)
  • SoWhy, I think your objections would be better served by rephrasing the clause as "4. Event coordinators should only confirm users who are actually attend the outreach event for which the Event Coordinator privilege was granted", which would more closely match the community's expectations of the privilege's use. If the event was declared as a virtual event at the time Event Coordinator was granted, then virtual attendance is OK, otherwise not. Cabayi (talk) 09:47, 20 March 2018 (UTC)

    @Cabayi: Since I agree with RexxS and WBoG above that some users should be granted this right permanently, this change does not work. What might work is a wording like 4. Event coordinators should only confirm users who actually participate in an outreach event. Regards SoWhy 09:59, 20 March 2018 (UTC)

    Hmm...You have raised a quite salient point and the phrasing looks nice enough:)~ Winged Blades^Godric 10:34, 20 March 2018 (UTC)

    I'd agree that being able to confirm remote participants would be important/userful, not least to take accessibility issues into consideration - a student with mobility issues participating remotely, for example. Lirazelf (talk) 12:15, 20 March 2018 (UTC)

    SoWhy, that's a much more succinct wording than mine, and it hits all the right points. I agree 100%. Cabayi (talk) 12:48, 20 March 2018 (UTC)

    I'm fine with that. Re: permanence, we currently hand out accountcreator to people without overly much experience on-wiki, which is part of the reason for most people that we set it to expire. There's discussion to make it permanent for repeat users who are trusted and active on-wiki now, but for the random librarian with 17 edits who needs it to run an editathon at a university library we would not be granting it permanently. If we were to require extended confirmed to be granted eventcoordinator, I would be fine with the above changes. TonyBallioni (talk) 15:06, 20 March 2018 (UTC)

  I would just like to add my support to this kind of solution should ACTRIAL be made permanent. Thanks! Jason.nlw (talk) 15:10, 20 March 2018 (UTC)

  I too would like to add my support to this kind of solution should ACTRIAL be made permanent. I also echo the comments made by RexxS and Lirazelf about trusted trainers not having to repeatedly seek permission and being granted the right permanently. Used judiciously this granting of rights could resolve a few issues and actually make everyone's lives easier without sacrificing quality control. Thanks! Stinglehammer (talk) 15:48, 20 March 2018 (UTC)

Online training for "program and event coordinator"

Various training modules are at https://outreachdashboard.wmflabs.org/training.

"Program and event coordinators" might take these training courses:

• Running Editathons and other Editing Events
• Support and Safety

These trainings are fine, but they are also sort of drafts and could get more community input. The dashboard has the functionality to badge or certify anyone who completes a training module. If the wiki community likes, it could require users to complete a training module as a prerequisite to requesting other permissions.

I am not saying that we should expect anyone with "coordinator" permissions to do training, but we could offer it, and we can get metrics about who completes it. Blue Rasberry (talk) 16:06, 20 March 2018 (UTC)

Round 2

I've made tweaks to the draft based on the comments above, and moved it to project space as I think we have a somewhat clear consensus on what a proposal should look like (even if some minor tweaks are needed to the wording.) Pinging those who have commented thus far @Bluerasberry, Xaosflux, SoWhy, RexxS, Stinglehammer, Jason.nlw, Cabayi, Lirazelf, Winged Blades of Godric, Legacypac, Insertcleverphrasehere, and Kudpung: pinging those who have already commented. TonyBallioni (talk) 16:13, 20 March 2018 (UTC)

• Fine from my perspective.~ Winged Blades^Godric 16:16, 20 March 2018 (UTC) ~ Winged Blades^Godric 16:16, 20 March 2018 (UTC)

I've rewritten the lead to articulate the actual problem. [1] There is no problems with running events, only a restriction in newly registered users moving newly created pages into mainspace without assistence (someone else does it, AfC, applying for Comfirmed PERM, or waiting 4 days) Legacypac (talk) 16:24, 20 March 2018 (UTC)

I think I preferred the previous wording, to be honest - it's not just the fact of being able to move articles, it's the knock-on effect that has on the event organiser's ability to control the event (see RexS comments above) and the overall effectiveness of outreach activity. Lirazelf (talk) 16:39, 20 March 2018 (UTC)

I've tweaked again. Hopefully this explains the problem but gets away from the question as to if this has a measurable impact, since that is disputed. It is felt by many in the outreach community that it does, so that should be enough to mean that we need to address the issue. TonyBallioni (talk) 16:46, 20 March 2018 (UTC)

• Looks okay. Technical question: If an account has 'confirmed' and makes 10+ edits, is 'autoconfirmed' given alongside 'confirmed' or only when the 'confirmed' expires and they edit after that? Regards SoWhy 16:37, 20 March 2018 (UTC)
  • Autoconfirmed is a check that the system runs anytime an editor attempts to take an action, not an actual user right. We used to go through and remove +confirmed once people had met the test (10 edits/4 days). Now that we can set flags to expire, we usually just assign for a given period of time and let it expire on the assumption they will meet the conditions by then. TonyBallioni (talk) 16:46, 20 March 2018 (UTC)

• Without going too far in to BEANS territory - there is still some issue with the way this works on the technical level, at least until one day someone fixes phab:T85538, thus not leaving it on long-term for people without a continuing need and that are generally non-disruptive. — xaosflux ^Talk 18:03, 20 March 2018 (UTC)

• Also, I don't think there is an existing mechanism for "only allow temporary of x" group granting - this may get bogged down in developer time. — xaosflux ^Talk 18:08, 20 March 2018 (UTC)

• See also phab:T91928 for a related concept. — xaosflux ^Talk 18:08, 20 March 2018 (UTC)

• New text looks great, made some minor grammatical fixups. This is coming a little late but I'm not totally convinced by the above (or rfc discussion) that there needs to be a new flag separate from accountcreator. AFAICT the net effect would be to keep the +confirmed ability away from WP:ACC? Is the idea that experienced organizers/those with small groups would get this, allowing their participants to create articles, while the larger, inexperienced events would be given accountcreator and must play in draftspace? Basically, this would also change how account creator is given. ~ Amory (u • t • c) 18:18, 20 March 2018 (UTC)

  @Amorymeltzer that was already tried. The discussion failed because many of the accounts that have account creator weren't seen to be experienced enough for the new permissions, among other reasons. — Insertcleverphrasehere ^{(or here)} 18:43, 20 March 2018 (UTC)

  In other words, what I said above? Event coordinator for experienced outreachers, account creator for inexperienced outreachers (and WP:ACC)? ~ Amory (u • t • c) 18:49, 20 March 2018 (UTC)

  The community didn't want it bundled with account creator in August (See this VPR discussion). The community also rejected a proposal that was very similar to this that was put forward after the initial proposal failed (see this discussion.) Part of the issue here is that in some ways, account creator will have more powerful rights (override blacklist, etc.) This is also why I think it is so important to have this discussion be distinct form ACTRIAL: there is a lot to work out even on the technical end of it, and we need to craft a proposal that is also likely to pass. TonyBallioni (talk) 18:58, 20 March 2018 (UTC)

  Assuming this is a new user "group" - add others to group x would be specific to the group. — xaosflux ^Talk 18:32, 20 March 2018 (UTC)

• Not sure if I like "Administrators may at their discretion temporarily grant the permission to editors who are organizing outreach events but do not have significant experience on Wikipedia", I'd prefer "Administrators may at their discretion temporarily grant the permission to editors who are organizing outreach events and have less experience on Wikipedia". I think this is potentially a sticking point in the RfC that might cause it to fail, so we definitely need the wording to be right. — Insertcleverphrasehere ^{(or here)} 18:20, 20 March 2018 (UTC)
  • See this request at PERM as an example. We routinely grant account creator to people with next to no experience, and so I was basing it off that. Issues like this are why I think this really needs to be a distinct discussion after the ACTRIAL RfC outcome is determined. There are a lot of issues raised in both of the August RfCs that will need to be addressed, and it is much less straightforward than "Yes" or "No".TonyBallioni (talk) 18:58, 20 March 2018 (UTC)

Question: ACTRIAL only impacted the ability of new accounts to move or create in mainspace - so that seems the only issue here. Why can't we just say that clearly? [2] Am I missing something? Legacypac (talk) 18:41, 20 March 2018 (UTC)

One thing you may run in to is about (auto)confirmation: ORIGINALLY this was designed to be a very low bar to prevent drive by vandalism, ACTRIAL is a 'new' concept and balancing its goals with confirmation may be needed. — xaosflux ^Talk 19:28, 20 March 2018 (UTC)

The face of Wikipedia has changed over the years, xaosflux. It has now become one of the most powerful types of media of its kind and as such is suffering brute force attacks from people and organisations who want to be in it. It's now actually 80% of the inappropriate new pages. Vandalism is only about 5%. The remaining 15% is general rubbish, some of it harmless, but Wikipedia is not the place for it so it has to be prevented. Kudpung กุดผึ้ง (talk) 20:35, 20 March 2018 (UTC)

Indeed Kudpung! As one of the biggest proponents of new page review - what do you think of new page creation occurring at edit-a-thons? Personally, I think having E-A-T pages go to Draft (not as part of the AFC process necessarily) for review by the event coordinator(s) makes a lot of sense - but the 'old school' wiki values are a bit strained by it. — xaosflux ^Talk 21:24, 20 March 2018 (UTC)

We have disasters like the 'List of Monuments in Nepal' effort that dumped hundreds of unsourced unpopulated lists in mainspace in 2014. These have been theough AfD, MfD x2, and G13 deleted and restored twice. I've tried to fix up a couple but I can't find sources for them.

I'm seeing a lot of noise from outreach people. In their arguments I'm learning about virtual editathons with new users, so few leaders that there is no time for an experienced editor to look at new creations, and how people with no on wiki experience often hosting these events. Every work around is dismissed as unworkable. None of these stories supports making exceptions for events.

I'm coming to firmly believe only autoconfirmed editors should be mainspacing new pages period end of sentence. If 100 Confirmed newbies at an editathon add a bunch of junk thanks to an inexperienced host getting a new PERM who do we talk to? If the established editor makes the inappropriate moves we can have a discussion quickly. If they go through AfC we have a process there already.

If there is WP:NODEADLINE why is it such a panic to get new pages into mainspace from an event? Who cares if we wait a couple hours till the coordinator gets to them, 4 days until the creator can move them, or at worst a few week at WP:AfC? The topic was not covered for 10 years so why the panic? Legacypac (talk) 21:45, 20 March 2018 (UTC)

See NerdLab YYC (edit | talk | history | protect | delete | links | watch | logs | views) for a very recent example - they managed to find a workaround alright and create an article about a completely non-notable organisation. I've added a list of similar-ish topics created at the same time using the same methods at User:Smartse/canada. SmartSE (talk) 23:50, 20 March 2018 (UTC)

I think these are points worth raising in an RfC, which is why I thought, and still think, that it should take place on it's own. FWIW, I still support this because I generally support giving people the tools they say they need to get the job done. At the same time, I don't think this is as uncontroversial as a lot of people think (see the previous RfCs and some comments here and at WP:ACPERM). TonyBallioni (talk) 00:45, 21 March 2018 (UTC)

(edit conflict) I'm a bit on the fence there xaosflux. There's a disparity between the pragmatic and the philosophical interpretation of something as conventional as an encyclopedia, and Wikipedia/Wikimedia has become something of a grey area between a work of reference and a socio-political movement. Personally I find the old-school values as outdated. They were good at the time Wikipedia was created, but is getting on for 20 years ago and it has developed out of all proportion its founders could ever have imagined. The mantra 'The encyclopedia anyone can edit' is as hollow as it's true. The founders certainly never meant that to mean 'The encyclopedia any one can wreck, vandalise, to use for spam or making money out of'. There are empassioned people however who interpret that founding statement as an irreversible dogma and refuse to accept that something has to be done about it and they are intractible as flat-earth theorists. The Outreach people belive that ACTRIAL is some conspiracy to thwart their work. Because they are so disconnected from the encyclopedia they represent and promote, they don't even realise from my comments that I also have a lot of hands-on experience at live editathons both in the UK and here in Thailand (I don't get paid for it either and requests for even some minimal funding have always been refused by the WMF). I was also one of the initiators of getting the draft namespace created. It does its job. I think the claims and fears of many facilitators are greatly exaggerated - there are plenty of reasonable and easy workarounds available. '...anyone can edit.' never did mean 'anyone can create a new article immediately in mainspace'. At editathons we get all types, but in my experience most participants want to learn the technicalities of editing. Most of them don't attend the sessions with the determination of getting an empassioned article published on that day. Perhaps the earth is ovipoid. Kudpung กุดผึ้ง (talk) 22:13, 20 March 2018 (UTC)

• I don't see the need for the bureaucracy of a new userright, or having to turn off confirmation ability 10 days after the event. That's just not a very dangerous operation. I'd change the software to automatically let any user with +autopatrolled (or similar) confirm new accounts without their even having to ask. The occasional screwups I see resulting will be insignificant in the face of the massive unrelated screwups we deal with every day. The confirmations would all be logged, so if someone went crazy and confirmed a bunch of spammer accounts, the confirmations could all be undone with a script. As for making many accounts from one IP, event coordinators apparently already deal with that somehow (+accountcreator?) and seem satisfied, so we don't need more machinery for it afaict. 173.228.123.121 (talk) 08:24, 21 March 2018 (UTC)

CAPTCHAs

A post at WP:VPR described new editors trying to create articles in their userspace. Problems arose from the need to enter captchas for external links. Presumably this proposal (that an event coordinator could set +confirmed for new accounts) would resolve that situation. If so, it might be worth mentioning the issue. Johnuniq (talk) 00:12, 22 March 2018 (UTC)

This is an issue at editathons, perhaps as big or bigger than the 'article creation' issue, and is another very good reason for implementation of this proposal. very disruptive at editathons and punishes users for adding references. — Insertcleverphrasehere ^{(or here)} 00:28, 22 March 2018 (UTC)

It is a problem at editing events not just for the minority who are creating articles, but also for those improving articles by adding content. In the past, I've spend considerable time making sure that everybody understands the paramount importance of providing references to support their text, only to then find them being asked to jump through the CAPTCHA hoop almost every time they add a reference. Once ironic effect of ACTRIAL is that I've stressed even more strongly the importance of registering an account at least five days prior to the event – a by-product of needing (auto)confirmed to create/move new articles is that in working round that, we alleviate to some extent the burden of CAPTCHA. Some events last all day and a keen editor may have to go through that particular annoyance dozens of times during that time. I understand that CAPTCHA serves a useful purpose in stopping spam from automated scripts, but we don't get many automated scripts signing up for editathons in my experience. I would regularly find having the ability to grant +confirmed for a few days even more valuable in improving the editing experience for participants by eliminating CAPTCHA, than for giving them the ability to publish new articles themselves. --RexxS (talk) 01:16, 22 March 2018 (UTC)

Is there any possibility of creating a whitelist of the main reliable sources, so a link to bbc.co.uk gets in unchallenged but a link to cheapviagra.spamfarm.tk still throws up a Captcha? Certes (talk) 13:59, 28 March 2018 (UTC)

@Certes: yes, please discuss at Wikipedia:Reliable_sources/Noticeboard#Whitelisting_sites_for_newbies. The list is very small right now (MediaWiki:Captcha-addurl-whitelist). — xaosflux ^Talk 14:11, 28 March 2018 (UTC)

That's an excellent idea, Certes!

Points 3 - evidence

I think this new permission is a very sensible one, and would like to offer you a good example of why an admin should be able to grant this permission to editors with very limited Wikipedia experience. If you visit this Editathon page, you'll see it was an created by an editor after only their 11th edit (See their edit history). They organised and ran the event brilliantly and had the foresight to apply for an IP exemption on account creation in advance. This single permission would have been useful for both them and for me. By the time of the event a month later this university librarian had mastered Wikipedia sufficiently well to have created accounts for others had they been able to. (As an aside, this event took place during WP:ACTRIAL and none of us had any prior concerns about coping with moving draft articles into mainspace - not that that actually came up on the day. We did give each attendee this handout, though. Regards, Nick Moyes (talk) 10:12, 22 March 2018 (UTC)

Wikipedian in residence

Should all WIRs get the event coordinator right by default (if they're not already admins)? I believe outreach and editathons are major activities for WIRs, unless I'm very mistaken. Roger (Dodger67) (talk) 16:13, 23 March 2018 (UTC)

I'm (probably) in favor of this, but I'm not sure it needs to be explicitly written as such: according to this there are around 50 active WiR, some for quite some time and some not enWiki-related. I think we can manage that in an ad hoc fashion, so perhaps in the guidelines for granting it can be suggested that WiR should probably be given it freely for the duration of their position. At any rate, WiR are well-vetted and would be the clearest users of this, so I'm sure many sysops (myself included) would feel comfortable just giving it to every new WiR upon appointment. ~ Amory (u • t • c) 19:06, 23 March 2018 (UTC)

Becoming an online editor: perceived roles and responsibilities of Wikipedia editors

Hi, a quick note to say that judicious granting of the ability to confer confirmed user status on new editors to trainers and Wikipedians/Wikimedians in Residence would be massively helpful and go a long way to alleviating any issues with ACTRIAL affecting outreach work. Editathons have proved a great way to get academics, librarians and members of the public from different disciplines in the same space contributing to Wikipedia; something I hope we would like to see more of. A number of our editathons have been on under-represented topics, such as addressing the content gender gap, where the focus has been on creating new articles to help address the issue. This has often been the key motivating factor for many participants and that moment of ownership where they publish at the end of the day helps Wikipedia editing 'click' for them in terms of what I call being a 'knowledge activist' in addressing areas of under-representation. And no we're not just talking about having a 'Wow!' moment just for the sake of it. This matters in terms of new editors engaging with Wikipedia.
A new research paper has just been published on Becoming an online editor: perceived roles and responsibilities of Wikipedia editors which goes into these areas and helps explain what I am talking about. It makes for an interesting read and I would commend it to you in terms of providing more context for this discussion. I have to concede that academics and librarians are time-pressed a lot of the time so they may not contribute to Wikipedia all the time but what I want is them to see the point of contributing when they do have a moment and for them to see the process of how to add quality contributions to Wikipedia from beginning to end (only 2 articles I believe have ever been deleted in the 26 months of the residency here in Edinburgh). Ultimately, that participants come out of the supportive environment of an editathon workshop with the skills, motivation and positive experience to continue and encourage others to become involved. Which is my experience to date as I find the positive experience of one person leads onto other editathons and other in-curriculum work which generates more quality articles for Wikipedia using scholarly literature and library/archive collections.
After supporting Content Translation work too for the last four semesters we are keen that our editathons also allow proficient bilingual and multilingual speakers to translate quality articles into other languages too. This is something that also requires confirmed user status. And as already mentioned, the captcha codes are a real nuisance and hinder participants from having that positive first experience with Wikipedia we would like to see engendered from the editing workshops we run here at the University of Edinburgh. For all these reasons, if the trainer is there to support and vet new articles, I think having the Event Co-ordinator having the ability to grant confirmed user status to newbies is the best way to go to achieve the aims of Outreach and meet the needs of NPP / NPR that ACTRIAL addresses. Stinglehammer (talk) 13:08, 28 March 2018 (UTC)

Just create a placeholder article for them

For what it is worth, what is against the idea that an event coordinator would just create a placeholder article for the participant, after which they can do the first edit to turn it from the placeholder article into a real article. In that way no advanced rights are needed for any editor, and event participants could even just edit from an IP without having to create an account. --Dirk Beetstra ^{T C} 15:24, 28 March 2018 (UTC)

If the coordinator is going to be interactive, why not just have them do this via "move" from user sandboxes or Draft space? — xaosflux ^Talk 15:31, 28 March 2018 (UTC)

@Beetstra: Note, a big thing here would be if the coordinator is autopatrolled, this "new article" would bypass a lot of the new page patrol controls. — xaosflux ^Talk 15:32, 28 March 2018 (UTC)

I was thinking such things, but if the coordinator anyway has to be there to give the accounts rights, then they need to be responsive there as well (after all, the event coordinator, after giving rights, is somewhat responsible for what the editors there leave in mainspace, otherwise I would probably not support them making pages in mainspace; disclaimer, I have no idea what goes on in such events).

I was also thinking the 'move after creation' .. that leaves also some form of control (again, if the event coordinator is responsible). --Dirk Beetstra ^{T C} 15:38, 28 March 2018 (UTC)

Agreed this is a possibility. It's something some outreach people don't like (no sense of ownership, etc.) which is why I created the proposal, but also why I think it should take place after the ACPERM RfC. Sorting out the best way to handle this is important, and worth a discussion on its own. TonyBallioni (talk)

I was also thinking another way around, and that editors could just acquire the right to flip autoconfirmed bits on editors automatically with any ‘given’ right. I see no reason why this should be specific to events of a certain nature. OK, I trust you to behave in mainspace (knowing that abuse of that trust can be met with more direct effects). —Dirk Beetstra ^{T C} 16:48, 28 March 2018 (UTC)

Empty placeholdr pages in mainspace are going to get deleted by NPR before the event gets going. According to outreach people some successful event coordinators are barely autoconfirmed themselves. A few editors just want people to be sit down at an event (even attending virtually) create a brand new account (no preplanning) and create unlimited new pages with no CAPCHA even all under the supposed supervision of another inexperienced editor.

Another possible easy work around - event coordinators often need Acct Creator rights. Could they create however many new accounts 5 days before the event and hand them out at the event? That seems like reasonable prep work that could be done in advance. The new user changes the password and starts editing. After the 10th edit the account is auto-confirmed and can create new pages. We could see who created the account and catch anyone making up spammer accounts right? Would that run afoul of the shared use if accounts rules? The creator would not actually be using the new accounts to edit, and surely an event coordinator would know more than 5 days in advance they are going to hold an event and the maximum people they expect to attend. Legacypac (talk) 17:11, 28 March 2018 (UTC)

@Legacypac: I would not create them empty, but with a {{event placeholder template}} or something similar.

Your solution is also nice, though I foresee problems with the name of the account. —Dirk Beetstra ^{T C} 17:25, 28 March 2018 (UTC)

WP:eAfC (event AfC) - an AfC clone especially for events, with different tags and without the mandatory review bit, just move them to mainspace, enable cats, remove tag, and be done? —Dirk Beetstra ^{T C} 17:31, 28 March 2018 (UTC)

or just use AfC - getting permission to use the script is easy and the tool kind of helps with cats - though I prefer sometimes to let NPR add the Cats as here are some editors that specialize in Cats and Wikiproject tagging and they do a far better job than I can on it.

For the non-throwaway accounts Wikipedia:Changing username. Legacypac (talk) 17:57, 28 March 2018 (UTC)

@Legacypac: don’t get me wrong, even with the alternatives here, I don’t really see the need even for this whole workaround. For me, the whole editathlon and event stuff is a mere red herring, seen the many already existing and working workarounds. Create dummies, find some admin who can hand out a handful of confirmed bits, move on sight, dummy accounts prepared, and doing bloody 10 proper edits and not focus on creation only (it is an EDITathlon, not a CREATathlon..) all work without the need of new advanced rights. —18:04, 28 March 2018 (UTC)

Agreed - just trying to provide solutions. Legacypac (talk) 19:03, 28 March 2018 (UTC)

I think this section is a bit of a distraction from the constructive solution proposed in the sections above. Placeholders create several issues for event organisers. Firstly, even with templates i have know them to be deleted before editing gets going. Secondly, an important part of outreach work is being able to measure and monitor the work of participating editors. If you create a placeholder then the stats show that you created the article, not them. And if it is nominated for deletion, the trainer will get the notification and not the editor. My grant givers often require me to provide evidence of all users who participated in events and statistics on what they created. In order to use tools like Wikimetrics properly users have to have actually created their articles. As for the myriad of 'existing workarounds' - from a training perspective you want the process of contributing to Wikipedia to be as simple and streamlined as possible. Bombarding new users with a range of solutions, which they wont understand, damages their confidence and enthusiasm to keep contributing. Jason.nlw (talk) 06:41, 4 April 2018 (UTC)

If the event holder creates the new topics they can more easily look at their list and check them. New users don't need to know a range of work arounds for a problem that goes away in 10 edits 4 days. Nearly everyone will say "that is a good idea" if told "Wikipedia requires new editors to have a little bit of track record to prevent creation of new vandalism only pages." — Preceding unsigned comment added by Legacypac (talk • contribs) 07:51, 4 April 2018 (UTC)

Most events end up with a different set of participants on the day from those who signed up for the event earlier. Similarly, some participants often end up working on a topic that I didn't know about beforehand. The "workarounds" in this section put far too many complications in the path of organising an event for no good reason. I am trusted enough to create an account for an event attendee, so if somebody doesn't trust me to also grant them confirmed status for a temporary period of about four days, they really ought to be telling me that to my face, and providing some bloody good reasons why they want to make organising unnecessarily more difficult for me. --RexxS (talk) 17:43, 4 April 2018 (UTC)

The push back on ACREQ by outreach people with no experience or interest in NPR is not helping the case for any exceptions. A little perceived inconvenience for an event organizer who can simply explain that Wikipedia has a 4 day cooling of period to reduce vandalism is barely worth discussing when outreach people are happy to waste thousands of hours of other people's volunteer time to patrol and delete the 80% of non-AC pages that need to be removed. Then all our suggesions for work arounds are dismissed as unworkable. Legacypac (talk) 18:09, 4 April 2018 (UTC)

Please read WP:LISTGAP.

All of us are volunteers and I don't go around belittling your contributions to the encyclopedia just because you haven't produced the same number of modules or featured/good articles, or trained as many new editors as I have. We all contribute in our own way, and it all has value. I understand perfectly well the value of NPP, and I'm quite cognisant of the difficulties and hard work involved. However, I wouldn't put barriers in your way if you wanted to improve the NPP process, because I would assume that you know what you're talking about. It's really annoying to see that you don't extend the same courtesy to me in the reciprocal circumstances. You clearly have no idea of the problems involved in organising and running events, yet you feel empowered to chip in with half-baked "work-arounds" without ever having suffered the effects of them yourself. Then you snidely infer that I'm "happy to waste thousands of hours of other people's volunteer time to patrol and delete the 80% of non-AC pages that need to be removed". That is complete bollocks, and you need to withdraw that, or show us all where I've ever advocated it. Have you ever considered the possibility that if your suggestions are being dismissed as unworkable, they might just be unworkable (or at least hugely inconvenient)? --RexxS (talk) 18:32, 4 April 2018 (UTC)

Lets try to turn the thermostat down in here. The workarounds are meant to be just that: workarounds. They will only be temporary until a permanent solution can be found. With the right selection of tools (not too much power, not too little), I feel confident that we can get support for an Event Coordinator user group. Dedicated outreach editors being allowed to be able to grant temporary confirmed status doesn't seem like a large mountain to climb, and doesn't seem to be a hill that any of us are going to have to die on. Lets calm it down in here and wait until the end of the ACTRIAL RfC. — Insertcleverphrasehere ^{(or here)} 20:44, 4 April 2018 (UTC)

It's not just my suggestions that are dismissed - it is many different experienced editor's suggestions. Outreach people are acting like they are the only ones who matter and we have to hold up the world until their concerns are met. AC ran for 6 months and I never saw much complaint or effort to create a solution. Anyway, I wanted to share how some people evidently feel about what's being said by some outreach people, but you evidently don't understand, so go figure out a solution. Legacypac (talk) 21:33, 4 April 2018 (UTC)

many different experienced editor's suggestions: not one of whom is experienced in outreach.

Outreach people are acting like they are the only ones who matter and we have to hold up the world until their concerns are met: the hell we are. You're the one who's acting like those in outreach don't matter. I'm as strong a supporter of ACREQ as you are, but you're content to stick barriers in the way of other contributors' work, while falsely claiming that I'm trying to hold up its implementation. Take the cotton wool out of your ears and put it in your mouth for a while, and you might eventually realise that the solution is in this proposal that you're so negative about. --RexxS (talk) 16:17, 5 April 2018 (UTC)

Sheesh, It's a bugger when you know you are right and these other idiots just won't listen to you. · · · Peter (Southwood) ^(talk): 19:10, 5 April 2018 (UTC)

I was talking about those who oppose ACREQ not you RexxS. I'm up for any reasonable solution - just pointing out the potential pushback and a reason why. The last time this was raised in a RFC there were many editors against any exceptions. Legacypac (talk) 19:32, 5 April 2018 (UTC)

Phabricator task

Hello all. I have created a Phabricator task to track the development of the new group if the RfC concludes with a vote in support: phab:T193075. — Trevor Bolliger, WMF Product Manager (t) 19:20, 25 April 2018 (UTC)

Thank you, Trevor. That's very helpful. --RexxS (talk) 20:17, 7 May 2018 (UTC)

Closing this RfC

Although I believe the original intent was to run this RfC for a month, the consensus seems pretty clear. It would be great if someone could go ahead and close the RfC so that we can get this new user group in place before all the WMF developers leave for the Hackathon. Ryan Kaldari (WMF) (talk) 05:06, 7 May 2018 (UTC)

The patches seem to have been written in anticipation of the rather clear result and seem to be ready to be rolled-out and merged, according to phab:T193075. That shouldn't require more than a few days, so we still have a bit of leeway before folks head for Barcelona for the 18 May opening. Nonetheless, it's probably worth asking the question whether an uninvolved closer is willing to make a slightly early close. So, pinging a few of my favourite closers: @Harry, Dave, and Acalamari: to see if they are willing in the circumstances. --RexxS (talk) 20:30, 7 May 2018 (UTC)

Note from an opposer, in case that perspective is wanted: I support closing this RfC. Discussion has run its course: nothing new is being said, all that's really happening is people are adding more support votes. —Compassionate727 ^(T·C) 21:12, 7 May 2018 (UTC)

Post-closure tasks

What needs to happen to put the results of this discussion into effect? I can think of a few things – please feel free to add to the list:

• Phab ticket for technical implementation (phab:T193075)
• Writing documentation, such as WP:Event coordinator and updating WP:UAL
• Creating a process page for the right (under WP:PERM?)

Best, Kevin (aka L235 · t · c) 13:45, 8 May 2018 (UTC)

Yes, please be sure to create a page of the right, and a perm process. The page of the right will be needed to link the mediawiki default names to, as well as give it a readable name (e.g. "Event coordinator" as opposed to what the devs will code it as like "evcoor" or the like"). — xaosflux ^Talk 14:37, 8 May 2018 (UTC)

@Xaosflux: The devs have coded it as eventcoordinator. --Ahecht (TALK
PAGE) 16:34, 8 May 2018 (UTC)

@Xaosflux: the page for the right itself is created. I haven't created the PERM process as I'm not sure how it will interact with MusikBot (ping MusikAnimal) and if it needs any special setup for that. TonyBallioni (talk) 01:57, 9 May 2018 (UTC)

I've actually documented adding new permissions at User:MusikBot/PermClerk#Adding a new permission. That's just to get the bot to process the page. Setting up the page(s) is a little involved. I'll go ahead and create some of them — MusikAnimal ^talk 02:09, 9 May 2018 (UTC)

Okay maybe that wasn't so hard :) I think everything is in place. You just need to transclude Wikipedia:Requests for permissions/Event coordinator on Wikipedia:Requests for permissions and add a link in Template:Requests for permissions. Once that's done I can enable the bot clerking. I take it there are no hard prerequisites for this right? Makes sense if there are not, but you can still instruct the bot to report certain things that may be helpful, such as a very low edit count or account age — MusikAnimal ^talk 02:30, 9 May 2018 (UTC)

Oh, we do need a user talk template, like {{account creator granted}}. I'll leave that to someone else. After that's created I can update the userRightsManager script — MusikAnimal ^talk 02:45, 9 May 2018 (UTC)

 Done at {{event coordinator granted}}. TheDragonFire (talk) 12:19, 9 May 2018 (UTC)

Could someone clarify if Wikipedia:Event coordinator is to be marked as a policy, guideline or information page. There seems to be some quite a bit of variation between user rights pages. TheDragonFire (talk) 05:07, 9 May 2018 (UTC)

In my opinion, due to the level of support for this RfC, any portion of the page that implements the proposal is policy. In any event, after the wording is finalized, get a consensus on the talk page (doesn't have to be huge) to make the entire page policy – I doubt anyone would contest it. Kevin (aka L235 · t · c) 05:25, 9 May 2018 (UTC)

FWIW, most of the other pages on rights use {{subcat guideline}} or {{information page}}. ~ Amory (u • t • c) 09:50, 9 May 2018 (UTC)

@TheDragonFire: / @L235: / @Amorymeltzer: {{procedural policy}} might be a good top box. We probably should standardize all of these user right pages. Take some examples from WP:EFH, WP:FMV, WP:PMR. — xaosflux ^Talk 16:52, 9 May 2018 (UTC)

This is more a conversation for WT:PERM, but agreed, for the behavioral perms (everything but confirmed, extended confirmed, and autopatrolled; i.e., Edit filter helper/viewer, Account creator, Event coordinator, File mover, Mass message sender, New page reviewer, Page mover, PC reviewer, Rollback, Template editor) anyway. I'd be wary about applying the word "policy" to all those pages, and I'm not sure "procedural" really fits for most of them. EFH for example is much more about the granting (procedural seems fine, if out of place) while others like FMV and WP:Rollback are more about the use (behavioral guideline via {{subcat guideline}}). And then of course WP:NPR is a weird inbetween — a WikiProject subpage that's also critical to the functioning of the 'pedia. For the others (C, EC, autopatrolled), the current information page seems appropriate. ~ Amory (u • t • c) 18:01, 9 May 2018 (UTC)

Amorymeltzer, WP:NPR doesn't have to be a sub page, it's just where I put it when I created it. I suppose strictly speaking it ought to be at Wikipedia:New page reviewer, but it's probably not worth moving it now. Kudpung กุดผึ้ง (talk) 11:25, 14 May 2018 (UTC)

I had put a version of the same "information" template that appears on WP:PMR, WP:TPE, and WP:NPR, which seemed the most appropriate at this point in the process since the entire text of the page hasn't been vetted to the point required for a guideline or a policy. --Ahecht (TALK
PAGE) 21:00, 10 May 2018 (UTC)

• Technically implemented: phab:T193075 - gerrit:430418 deployed. Kevin (aka L235 · t · c) 18:28, 14 May 2018 (UTC)

Requesting

All of the infrastructure appears to be in place, so I've made myself a test request at Wikipedia:Requests for permissions/Event coordinator and we can see how the system works when ready. Thanks to all who worked on it. --RexxS (talk) 20:58, 13 May 2018 (UTC)