Wikipedia:Requests for comment/Event coordinator proposal

One of the points of feedback on the recent autoconfirmed account creation trial has been that some Wikimedians who work in GLAM and outreach activities to conduct edit-a-thons and trainings felt that the trial negatively impacted their ability to bring in new members of the Wikimedia community. In order to help meet these concerns, I am proposing that a new eventcoordinator user permission be created with the following abilities and guidelines for use and granting:

1. The eventcoordinator user group will receive the ability to temporarily add +confirmed to newly created accounts, and will also receive the (noratelimit) right in order to help with account creation. This will allow the Confirmed new accounts to create mainspace pages without waiting 4 days and 10 edits and allow the creation of many new accounts from the same IP address.
2. Event coordinators should set the expiry time of the confirmed user right to no more than ten days from the time it is granted.
3. Administrators should only permanently grant the eventcoordinator user right to editors with an established record of editing on Wikipedia. Administrators may at their discretion temporarily grant the permission to editors who are organizing outreach events but do not have significant experience on Wikipedia. Users who have not edited in over a year may have the permission removed for inactivity.
4. Event coordinators should only confirm users who actually participate in an outreach event.

TonyBallioni (talk) 14:24, 18 April 2018 (UTC)[reply]

1. Support as proposer. I generally believe in giving people the tools to do their "job" on Wikipedia, especially when for some of them, it is actually their real life job. There is a significant faction of people who say they need this, so I believe we should give it to them. TonyBallioni (talk) 14:24, 18 April 2018 (UTC)[reply]
2. Support with the caveat that #2 should read
   Event coordinators should set the expiry time of the confirmed user right to no more than ten days from the time it is granted. end of the event."
   After all, events might last longer than 10 days and the point of the expiry is to remove the right when it's no longer needed for the event. Regards SoWhy 14:31, 18 April 2018 (UTC)[reply]

   ​ Yes, but after 10 days they'll be autoconfirmed. Primefac (talk) 14:33, 18 April 2018 (UTC)[reply]

   I almost changed it and then remembered why it was worded that way. 4 days is the autoconfirmed threshold, so giving a user 10 days allows for extra time to hit the edits, but the minimum "tenure" bit is no longer an issue. TonyBallioni (talk) 14:36, 18 April 2018 (UTC)[reply]

   The edit requirement to reach autoconfirmed is also a thing. --Izno (talk) 14:38, 18 April 2018 (UTC)[reply]

   @Izno, TonyBallioni, Primefac, and Kelapstick: While it's likely that most editors will have reached 10 edits by that time, it's not certain. There are plausible scenarios were the edits only happen after 10 days (for example if the rights are assigned on the first day but editing only starts two weeks later), so I see no reason to add language that might be problematic if we can also use language that certainly won't be. Regards SoWhy 14:41, 18 April 2018 (UTC)[reply]

   That's a fair point, and generic useful description rather than a prescriptive firm one size fits all timeline. I think your line still needs some work SoWhy, as you're saying ten days after the end of the event, when perhaps it should say Event coordinators should set the expiry time of the confirmed user right to end no later than the last day of the event. Which would give leeway to allow the grantor to grant until the end of the event (regardless of length), but not longer. Noting also I cannot imagine someone participating in a ten day editing event not reaching ten edits actually requiring a confirmed account, but I also see no harm in it either. --kelapstick^(bainuu) 14:46, 18 April 2018 (UTC)[reply]

   Is a confirmed user also given the autoconfirmed permission, or will that block it? Or will the user be granted the autoconfirmed permission following the first edit after their confirmation expires? —Compassionate727 ^(T·C) 14:54, 18 April 2018 (UTC)[reply]

   This is an important question. If there are additional restrictions (such as having to perform an additional edit after the "confirmed" status expires to be "autoconfirmed"), I would think removing the expiration requirement altogether from this proposal would be preferable if we want to retain editors after such outreach events. Answered by TonyBallioni below. --Ahecht (TALK
   PAGE) 15:27, 18 April 2018 (UTC)[reply]

   I think 10 days was proposed either at the ACPERM RfC or the talk page (I can't keep track of all the discussion regarding ACTRIAL). I typically just assign the permission for 7 days when it is requested for an ALT, on the assumption that if they get it beforehand, it isn't a big deal as it will expire in a short bit. I have no real objection to any language people want to come up with on that point, either in the RfC or as part of the "tweaking phase" if this passes. Also, this was an edit conflict and mainly replying to kelapstick, but confirmed does not block autoconfirmed. TonyBallioni (talk) 14:57, 18 April 2018 (UTC)[reply]

   @Kelapstick: I'm fine with wording it like that. Regards SoWhy 15:21, 18 April 2018 (UTC)[reply]

3. Support It seems sensible to me that you shouldn't need to be an admin to provide confirmed access to users at an event you're hosting. SoWhy I don't think that confirmed would be needed for longer than ten days, since after after ten days they should have enough edits to be autoconfirmed anyway. In reality we should have a default (or maximum) of ten days (or fewer) in the granting of confirmed anyway, since it's only a temporary right. --kelapstick^(bainuu) 14:35, 18 April 2018 (UTC)[reply]
4. Support as an useful adjunct to ACPERM. · · · Peter (Southwood) ^(talk): 14:44, 18 April 2018 (UTC)[reply]
5. Support Logical, in light of ACTRIAL looking to becoming permanent next month. Courcelles (talk) 14:55, 18 April 2018 (UTC)[reply]
6. Support to address the concerns of event coordinators at the ACTRIAL RfC. In-person editing events are an important piece of our outreach program. If the folks who currently coordinate these events think this would be helpful to them, then I'm all for it. Ajpolino (talk) 14:58, 18 April 2018 (UTC)[reply]
7. Support as a mitigation for the main drawback of ACPERM. MER-C 14:59, 18 April 2018 (UTC)[reply]
8. Support as mitigation for ACPERM. Supervision by an event coordinator should give as much control over these new editors as is needed. Certes (talk) 15:05, 18 April 2018 (UTC)[reply]
9. Support Participants at edit-a-thons receive training and guidance that far surpasses the experience that is required to become confirmed. Vexations (talk) 15:16, 18 April 2018 (UTC)[reply]
10. Support This is just common sense. "confirmed" is such a low bar to clear, and there will be tracability/accountability. I would have no problem with this proposal even without an expiration date. --Ahecht (TALK
    PAGE) 15:27, 18 April 2018 (UTC)[reply]
11. Support as a reasonable approach to the issue raised. It might be a good idea to specify that whoever grants confirmed status should be present with that user at the outreach event. Otherwise we cannot take for granted that the user has access to the support we presume outreach events to offer (i.e. the person could just be any user who wants to be confirmed). — Rhododendrites ^talk \\ 15:33, 18 April 2018 (UTC)[reply]
12. Support It shouldn't be necessary, but it sadly seems to be in the light of ACTRIAL. Mike Peel (talk) 15:37, 18 April 2018 (UTC)[reply]
13. Support. While opposition to ACPERM was very low, the event organisers made a very clear and understandable case for this requirement. Kudpung กุดผึ้ง (talk) 15:39, 18 April 2018 (UTC)[reply]
14. Support. I am not a regular at events but I did help at a student edit-a-thon recently. The students were told to set up accounts in advance but few did. It is painful to watch people enter CAPTCHAs over and over for hours, which is what happens when an unconfirmed user adds a web reference to a page. Having experienced users move pages from userspace to mainspace at the end is not ideal, as it creates a logjam of tasks at the end of the editathon, and dilutes our message that contributors are responsible for their own edits. In the longer term I'd like to see a broader solution to the CAPTCHA problem, perhaps using something like ORES to distinguish between humans and spambots in less than four days. In the meantime this is a step in the right direction. Clayoquot (talk | contribs) 16:03, 18 April 2018 (UTC)[reply]

    Question, because I assume you'll know more about this than I do: could you clarify what about starting in the user or draft space and having the coordinators move the pages to the mainspace makes the contributions seem less important? Everything I've read elsewhere indicates that new users editing in good faith are perfectly happy to start outside the main space. —Compassionate727 ^(T·C) 16:12, 18 April 2018 (UTC)[reply]

    Sure, thanks for your question. Yes, it's good for new users to start articles outside of main space. The point I was trying to make is that I would like them to be able to move articles to main space themselves when they feel the article is ready. That would help drive home the message that Wikipedia is a system where we ask for forgiveness instead of permission - i.e. contributors publish and THEN others review - and I feel that's a core concept of what Wikipedia is about. Clayoquot (talk | contribs) 16:25, 18 April 2018 (UTC)[reply]

15. Support per ACPERM, but I suppose, in a small way, this is also an unbundlement of sorts. —SerialNumber54129 ^{paranoia /cheap sh*t room} 16:10, 18 April 2018 (UTC)[reply]
16. Support - I have never been a proponent of limiting article creation to autoconfirmed users, so I have no problem lending my support to loosening the restriction a bit when it seems reasonable. — Godsy ^(TALK_CONT) 16:19, 18 April 2018 (UTC)[reply]
17. Richard Nevell (talk) 16:20, 18 April 2018 (UTC)[reply]
18. Support This gives the people who run events the tools they asked for. It keeps the more or less the status quo we had for article creation at events as we had prior to ACPERM so it can not make things worse. I also think it is important for those who work events to see that the community at large is responsive to their expressed needs. Jbh ^Talk 16:31, 18 April 2018 (UTC)[reply]
19. Support, Editathon editors are good faith editors, and are given a bit of help to get to grips with notability/etc. As a result they are not really the same kind of new editor to the one that ACtRIAL/ACPERM was designed to rein in. It makes sense to make an exemption and help out event coordinators this way. — Insertcleverphrasehere ^{(or here)} 17:03, 18 April 2018 (UTC)[reply]
20. Support, seems reasonable accommodation to outreach events. Renata (talk) 17:21, 18 April 2018 (UTC)[reply]
21. Support. At the ACPERM discussion, a clear and supportable case for this new user right was made, and I don't think the fears expressed in the Oppose section (at the time of my !vote) present any serious risk . Boing! said Zebedee (talk) 18:02, 18 April 2018 (UTC)[reply]

    Regarding concerns that this will make it easier for people showing up at events to produce bad articles, I think the first thing to say is that without ACPERM (ie the way it's always been) they already can produce whatever bad articles they wish, so the implementation of ACPERM plus eventcoordinator doesn't change that. Further, the vast majority of bad articles (by an overwhelming margin) are simply not created at events - as anyone who has spent any time working at NPP and CSD knows. ACPERM will throttle back the torrent of bad articles in general (as ACTRIAL has clearly demonstrated), and eventcoordinator will merely reset the status quo for events. Boing! said Zebedee (talk) 09:16, 19 April 2018 (UTC)[reply]

22. Support I have been organizer at 100s of in-person Wikipedia events. People at events are eager to do right and produce higher quality content than other online only new users. When people come to a Wikipedia event they often have a hope to create a new article and have a memorable, positive experience. The Wikimedia Foundation actively funds in person outreach all over the world and part of the experience is publishing an article. Taking away the ability to publish makes outreach much more complicated. Continue to expect that event coordinators will do right and offer appropriate training for new users to publish according to the rules and have a shared Wikipedia editing experience with a group of wiki colleagues. Blue Rasberry (talk) 18:48, 18 April 2018 (UTC)[reply]
23. Support per all my comments in prior discussions of this issue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:56, 18 April 2018 (UTC)[reply]
24. Support. There are many places in Wikipedia where we have chosen to apply a low bar in order to prevent most of an undesirable situation, without imposing much at all of an inconvenience on good faith users. For example, determined sockmasters can evade semiprotection, but almost always it is enough to stop vandals. Likewise, ACPERM should not be regarded as a front-line measure to ensure all articles are up to standard, but as a sufficiently minimal barrier to keep out most the flood of crap. Attendance at an actual outreach event is for most people a higher barrier, and people will also have in-person guidance. This is enough to "keep out most the flood of crap" from such people—but it stands to reason, and I believe outreach people when they say, that event attendees are mostly well-intentioned. By only giving the eventcoordinator right on a permanent basis to experienced editors, attendees who receive +confirmed will also have experienced help, and will therefore be in a much better place to create good content than a normal new editor.
    In short, we should trust experienced event coordinators to manage events well and make them great for the encyclopedia and new editors alike; the opposes, on the other hand, hold no water. BethNaught (talk) 19:14, 18 April 2018 (UTC)[reply]
25. Support per above. A sensible choice. -FASTILY 19:41, 18 April 2018 (UTC)[reply]
26. Support to retain status quo within Outreach after the 4/10 rule kicks in. Otherwise enthusiastic new editors attending events may feel discouraged. Cesdeva (talk) 20:00, 18 April 2018 (UTC)[reply]
27. Support not going to harm anything. We have NPR to catch low quality problematic pages. Legacypac (talk) 20:05, 18 April 2018 (UTC)[reply]
28. Support a really valuable thing in a well-run editathon. Jheald (talk) 23:40, 18 April 2018 (UTC)[reply]
29. Support. I think this is a needed adjustment to avoid crippling good-faith outreach and editing events. Will there be bad articles created at editathons? Sure, but it's a manageable amount and we don't have to worry about bad faith and paid editors in these cases. Articles created at editathons are much more likely to be high quality, notable, and worth including in the encyclopedia. I don't see a compelling reason to force such users to jump through a lot of hoops to create in Main namespace. Kaldari (talk) 23:50, 18 April 2018 (UTC)[reply]
30. Support -Never been to an event, and never will, but this seems like a good idea. Beyond My Ken (talk) 00:27, 19 April 2018 (UTC)[reply]
31. Support Good idea. Experience will show if it needs tweaking. Johnuniq (talk) 00:55, 19 April 2018 (UTC)[reply]
32. Support wholeheartedly per my comments at the ACPERM RfC; this is absolutely required following ACPERM. I'll note that this is actually my second choice, as I still believe folding this into accountcreator would be cleaner. I fear one will become vestigial. ~ Amory (u • t • c) 02:00, 19 April 2018 (UTC)[reply]
33. Support as stated. This will help us grow and adds flexibility for those running these events. -- œ^™ 05:35, 19 April 2018 (UTC)[reply]
34. Support. A good new permission with a demonstrated need. Tazerdadog (talk) 07:49, 19 April 2018 (UTC)[reply]
35. Support During the just-closed ACPERM discussion we more-or-less promised the event organizers that something would be done to meet their concerns. We'd better follow through now and I don't see that serious harm will result: Noyster (talk), 08:56, 19 April 2018 (UTC)[reply]
36. Support, happy with the response to my questions and glad to support this initiative. We need good content creators and anything that can assist in recruiting new editors, particularly in areas less-well-covered, is a Good Thing, providing it doesn't create other issues to the extent the proposal is a net negative, which I'm satisfied this would not, and is not. Fish+Karate 09:14, 19 April 2018 (UTC)[reply]
37. Support I'd be happier with a solution that prevents an influx of potentially deletion-worthy articles during events, as this does not - e.g., creation as drafts followed by moving into mainspace once vetted by an organizer - but the downsides of that have been correctly pointed out and there's likely insufficient support for the approach. Failing that, this looks like a workable fix. --Elmidae (talk · contribs) 13:00, 19 April 2018 (UTC)[reply]
38. Support I have two slight concerns with the wording. First, does "users who actually participate in an outreach event" mean they have to be physically present? For "virtual" events, I'd rather rely on administrators to add the permission. Second, I think there needs to be some threshold of activity for granting this right. If two editors with a total of 50 edits are organizing an edit-a-thon, there is a risk that the articles created will be far outside the expectations of the Wikipedia community, and I think it's a feature that new editors there would not be auto-confirmed. In practice, I don't see either of these causing problems even with the current wording, and they can be fixed later if they do cause problems. power~enwiki (π, ν) 19:35, 19 April 2018 (UTC)[reply]
39. Support Per all above after heavily weighing both sides. Ssgem 00:20, 20 April 2018 (UTC)[reply]
40. Support per others. Necessary after the implementation of ACPERM. The notions, put forward by some in the other RFC, of relying on the admin corps to add confirmed permissions or requiring potential participants to register an account in advance, showed a lack of understanding of how in-person outreach events work. This proposal is sensible and well-thought-out. — This, that and the other (talk) 12:21, 20 April 2018 (UTC)[reply]
41. Support as Kudpung and Certes have already intimated this is necessary to mitigate against any drawbacks for outreach work arising from ACPERM and achieves a win-win for both NPR/NPP and Outreach. Supervision by an event coordinator should give as much control over these new editors as is needed. Stinglehammer (talk) 15:49, 20 April 2018 (UTC)[reply]
42. Support The evident pluses outweigh the hypothetical minuses. I share the concern voiced above that requiring any potential participants in an event to register accounts well in advance won't work — it misunderstands the dynamics of getting people on board with new-to-them software in a serious way. XOR'easter (talk) 16:32, 20 April 2018 (UTC)[reply]
43. Support - there might be other ways to accomplish the same goal, but I trust GLAMers and others not to abuse this. Smallbones_(smalltalk) 17:24, 20 April 2018 (UTC)[reply]
44. Support to help events run smoothly despite ACPERM. Calliopejen1 (talk) 19:38, 20 April 2018 (UTC)[reply]
45. Support autoconfirmed really is not a big deal and anyone who has a strong desire to abuse Wikipedia can already get round it pretty easily. Smooth running of outreach events outweighs any downsides. Hut 8.5 19:43, 20 April 2018 (UTC)[reply]
46. Support Sensible proposal solving a problem many were concerned about. Johnbod (talk) 12:38, 21 April 2018 (UTC)[reply]
47. Weak support - usually I'm not a fan of making more user groups, but I think there is a clear use case here and I am generally in favour of giving people the tools they need to do their wikijobs. -- Ajraddatz (talk) 02:37, 23 April 2018 (UTC)[reply]
48. Support - As some one who regularly runs outreach events, this would be a valuable tool for streamlining editor expearience. Jason.nlw (talk) 09:42, 23 April 2018 (UTC)[reply]
49. Support L293D (☎ • ✎) 13:22, 23 April 2018 (UTC)[reply]
50. Support I've been involved in a lot of in-person training events for new users. An editor's first experience with Wikipedia can be very formative in helping them decide whether or not this is worth their time and effort. As trainers, we do our best to prepare them, but technical gotchas and restrictions can be frustrating and discouraging, although I totally accept that there have to be restrictions on new users by default. A new user at an event being trained by an experienced Wikipedian is in a far better position from someone pressing the edit button out of curiosity. They will usually have had a long discussion about Wikipedia as a community, its goals and norms, before even touching the computer. The proposed step will help these events be a positive, productive experience and help us grow the volunteer community. MartinPoulter (talk) 08:45, 24 April 2018 (UTC)[reply]
51. Support This would be massively helpful for those people who, like me, run a number of events for new editors. Lirazelf (talk) 12:58, 25 April 2018 (UTC)[reply]
52. Support - yes, this will lead to some blips in poorer articles for New Page Patrol to have to deal with, but the % of unsatisfactory articles would be nothing like the pre ACTRIAL days. In return we can get at least some more new articles that the current set-up wouldn't enable, some more interested new editors. Granted it's easy for the one who doesn't have to handle the downsides to argue this, but wikipedia should come down in favour of enabling editing unless there are overriding negatives to the contrary. I don't believe the overriding negatives sufficiently holds true in the case of edithons. Nosebagbear (talk) 10:38, 24 April 2018 (UTC)[reply]
53. Support very helpful idea which resolves one of the key concerns of the ACTRIAL/ACPERM RfC. Callanecc (talk • contribs • logs) 03:29, 26 April 2018 (UTC)[reply]
54. Support Perfectly reasonable. Will deal with concerns raised by those involved with GLAM. Doc James (talk · contribs · email) 12:26, 26 April 2018 (UTC)[reply]
55. Support. Per Amory, this would be cleaner if folded into accountcreator, but user group creep is not yet a major concern. 14:04, 26 April 2018 (UTC)

    Just responding to you and Amorymeltzer, since it's been made several times now: there are security concerns with the accountcreator that splitting it up like this actually addresses: having it as a separate group and reserving accountcreator for people who are part of ACC is actually a better outcome as it fixes a flaw in the current system (giving people who are essentially randos in many cases access to the override the blacklist and anti-spoof filters) while also fixing a concern that was largely raised by re: creation directly in mainspace. Once this passes, there won't be a need for event coordinators to have accountcreator access in most cases, which is a step in the right direction on that end. TonyBallioni (talk) 21:28, 26 April 2018 (UTC)[reply]

56. Support although I also agree that folding it into accountcreator may be better long-term. Richard⁰⁶¹² 21:13, 26 April 2018 (UTC)[reply]
57. Support It will be more creep and complication but seems necessary to mitigate the disruptive 4-day delay. Andrew D. (talk) 23:28, 26 April 2018 (UTC)[reply]
58. Support: As an event volunteer and event host, it's been clear many a time that this is beyond essential. ɱ (talk) · vbm · coi) 02:46, 27 April 2018 (UTC)[reply]
59. Support per above. As someone who has helped out at editathons, I believe it would be really helpful to be able to provide new users with confirmed access. I have yet to see a vandal show up in-person at a Wikipedia event. Tony Tan · talk 04:34, 27 April 2018 (UTC)[reply]
60. Support as part of the ACPERM package. Cabayi (talk) 13:22, 27 April 2018 (UTC)[reply]
61. Support I've been involved in many many outreach events, and while I share some of the opposers' concerns that too much of Outreach is focused on adding new articles; I've seen what the editing throttle does when an instructor says "all hit save now" and the faff that an academic has to go through because their account is unconfirmed and so if they cite an online source they have to complete a captcha. ϢereSpielChequers 12:35, 29 April 2018 (UTC)[reply]
62. Support per Theredproject's comments. — pythoncoder  (talk | contribs) 22:35, 29 April 2018 (UTC)[reply]
63. Support This is a basic requirement for successfully running events. Not all events should or do involv making new articles, but some do: we should not artificially constrain the sort of events people run, but allow a variety and promote experimentation.The way to prevent abuse is to monitor what happens at events--this should ideally be done by someone connected with organizing the event, but if events are announced, anyone can do this. DGG ( talk ) 22:25, 30 April 2018 (UTC)[reply]
64. A natural move after ACTRIAL's implementation. Esquivalience (talk) 02:55, 1 May 2018 (UTC)[reply]
65. Support I recently ran an event during ACTRIAL and not having this ability made things a lot lot more time consuming and removed some of the sense of accomplishment for the people being trained at the event. John Cummings (talk) 11:51, 1 May 2018 (UTC)[reply]
66. Support It isn't perfect, but it will provide an option for outreach to be carried out in an easier fashion that the rigmarole it can require presently. Such a mass creation right should, imho, be a time-limited right on the individual creating the accounts too, rather than a permanent right they receive in order to prevent abuse by someone "acquiring" their login. --AlisonW (talk) 13:01, 2 May 2018 (UTC)[reply]
67. Gamaliel (talk) 13:49, 2 May 2018 (UTC)[reply]
68. No brainer. Should have been proposed in conjunction with ACTRIAL. OhanaUnited^{Talk page} 14:14, 2 May 2018 (UTC)[reply]
69. Support per the previous discussions on this topic I believe this is required. jcc (tea and biscuits) 19:11, 2 May 2018 (UTC)[reply]
70. Support on behalf of Art+Feminism. Thank you for supporting the needs of event organizers. --Theredproject (talk) 20:01, 2 May 2018 (UTC)[reply]
71. Support - This is a wonderful idea. Swarm ♠ 03:07, 3 May 2018 (UTC)[reply]
72. Support— Removes my concern about ACPERM. Edit-a-thons are good for the encyclopedia and getting new articles from them on mainspace is good for AfC.--Carwil (talk) 20:34, 4 May 2018 (UTC)[reply]
73. Support - As an editor as well as an offline event organizer, this sounds good. A basic, useful way to make it easier for event organizers to get the ball rolling with their participants. I believe the majority of offline events are run well enough to ensure proper guidance, and the time limiting is a nice touch to help prevent inexperience and abuse after an event's end. ~SuperHamster Talk Contribs 06:21, 5 May 2018 (UTC)[reply]
74. Support. The prime purpose of the auto-confirmed requirement on new page creation is to prevent impulsive drive-by vandalism. Anyone who takes the trouble to come to an edit-a-thon in person, sits through the training that is always (in my experience) given as part of the event, and then wants to create an article is rather less likely to be a vandal than someone who makes 10 minor edit over 4 days and nothing more. I don't find any of the issues raised in the oppose section to be realistic concerns, or at least not strong enough ones to outweigh the benefits of this proposal. In my experience the experienced editors at an event are frequently checking the contributions of the new attendees, and offer advice on creating valid articles and otherwise making valid edits. When I attend such an event, I will routinely grant permanent confirmed status to anyone who asks for it or for one of the task for which it is a requirement, and have never found this taken advantage of to do harm. I don't see the need to make the confirmed status temporary. DES ^(talk)_{DESiegel Contribs} 17:01, 5 May 2018 (UTC)[reply]

    DESiegel: I'm just noting that it is the standard now to only grant confirmed temporarily. Autoconfirmed attaches automatically after 4 days, so the permission becomes redundant. I normally grant for a week to a month when requested at PERM (depending on the circumstances). Xaosflux can probably say more about the reasoning why we prefer not to have autoconfirmed users also confirmed than I can. TonyBallioni (talk) 17:05, 5 May 2018 (UTC)[reply]

    I am now aware of that, TonyBallioni (although i wasn't before reading this proposal). I don't see any good reason why it should be, however. "Cluttering the user group" seems like a non-issue to me. Perhaps i am overlooking something. I any case i support the proposal as made, and would also support it if it did not suggest limits on the duration of the confirmed right. DES ^(talk)_{DESiegel Contribs} 17:25, 5 May 2018 (UTC)[reply]

    A longer period (like a month) should also be fine - though I really think that edit-a-thons should actually include some editing (even going through WP:TWA which makes 8-9 edits). We occasionally clean up abandoned accounts left in this group, but rarely. — xaosflux ^Talk 17:19, 5 May 2018 (UTC)[reply]

    I always assumed that the confirmed group would only contain editors temporarily, since the permission would become redundant after 4 days and 10 edits. That would mean that by examining Special:ListUsers/confirmed it would be easy to spot any 'oddities', i.e. editors who have been grated the permission more than a few weeks ago: either they no longer need the permission or they haven't made 10 edits, so it would raise a (small) flag. However, when I actually looked at the list – which has an unexpected 528 members – it seems I was mistaken: there is a member who has been confirmed since 2005 (who has only made 7 edits), and many others who have been in the group for years. I won't worry about it, but maybe the group should be cleaned up if there's going to be any point in granting confirmed temporarily? --RexxS (talk) 19:18, 5 May 2018 (UTC)[reply]

    @RexxS: most of these are from before the time when expiration was even possible, and from when the only real point of confirmation was to prevent drive by/scriptable1 vandalism, basically "yes this account actually is associated with an actual person". Sometimes it was for some other reason like "allow an upload", which is no longer needed - but unless we make a bulk clean up rule going through all those accounts take a long time. Related to event management, these people could have been at event and got an account, but then never used it (most of the very-old, 0 edit ones have been purged already) - or didn't make at least 10 edits. Having attendees complete TWA or some other set of activities should usually be enough to get them to 10 if the event is really about "editing", if it is just about recruiting potential future editors maybe not (and maybe they don't need to skip the autoconfirmation process either...). — xaosflux ^Talk 23:55, 5 May 2018 (UTC)[reply]

    @Xaosflux: I always recommend that the trainer at an event guides the participants through a minimum of three things: (1) create their user page; (2) write and re-edit a sentence or two in their sandbox; (3) add a reference to their sandbox. Even with that minimal experience, they can't fail to have managed 10 edits. They can do the Wikipedia Adventure on their own later of course, but at an event I want to maximise the interaction between trainer and participant because that's how they learn best. Anyway, I had a look at a number of the editors in the confirmed group. There are a number of admin-alts in there, with the permission presumably self-granted. I also spotted a number of 'oddities' like an editor who is also extended-confirmed but has no edits. As well as one editor who requested (and was granted) confirmed last year simply to upload a single image – they haven't edited since. If the group were emptied of everyone from (say) 2017 and earlier, I wonder how many folks would be inconvenienced? The admin-alts could always be re-granted by their main admin account, and the ones who have made 7 edits in 7 years are probably unlikely to notice. What are the downsides of that sort of cleanup? --RexxS (talk) 00:28, 6 May 2018 (UTC)[reply]

    There are prob a fair number of non-admin alts too, if anyone claims an alt and asks at WP:PERM they get the flag - not sure why people bother and never use it though. — xaosflux ^Talk 00:40, 6 May 2018 (UTC)[reply]

75. Strongish support for reasons stated in original post.--SkyGazer 512 ^{What will you say? / What did I do?} 22:58, 6 May 2018 (UTC)[reply]
76. Support My initial inclination was support as I thought this sounded like a no-brainer proposal. Before weighing in, I made a point of reading the opposed statements and I confess a few interesting points were made. However, while that dissuaded me from viewing as a no-brainer, I still feel that the arguments in support of the proposal far outweigh the concerns, so I am here expressing support.--S Philbrick(Talk) 00:54, 7 May 2018 (UTC)[reply]
77. Support long neglected part of the ACTRIAL situation....Sadads (talk) 12:38, 7 May 2018 (UTC)[reply]
78. Support though I'm wary of the part of (3) which allows the right to be granted to users with little editing experience. Why are people coordinating editing events if they're not at least somewhat experienced? Ivanvector (^Talk/_Edits) 13:36, 7 May 2018 (UTC)[reply]
79. Support since this will address one of the downsides of the ACTRIAL since editing events are important to support. --Frmorrison (talk) 15:44, 7 May 2018 (UTC)[reply]
80. Support This is a common sense cleanup of the security risk created by granting accountcreator to outreach coordinators. The eligibility requirement is a little airy, but as with most userright introductions, we are very able to sort this out when a pattern of abuse either appears or doesn't. TheDragonFire (talk) 11:37, 8 May 2018 (UTC)[reply]

1. Oppose. I expressed my initial reaction below, and what I'm reading on this proposal's talk page further raises my concerns. The issue here is, quite simply, that new users brought in from outreach events are no different than new users from any other sources: they don't know how to create articles that will survive in the mainspace, due to being unfamiliar with our policies. My own experience learning policies suggests that simply reading over them isn't necessarily sufficient to grasp the details of their application. Ultimately, there's a reason 80% of new articles are deleted. And while I support both encouraging activity among newcomers and expanding the encyclopedia, I fail to see how being bitten with a deletion accomplishes either of these things. I'm at this point simply not satisfied that outreach events currently have enough supervision to ensure that new creations (which should ideally be done in the draft or user space anyway) are up to our standards. Furthermore, I maintain that if outreach events had this level of supervision, this permission wouldn't be necessary at all: event coordinates could simply move acceptable drafts to the mainspace. —Compassionate727 ^(T·C) 15:31, 18 April 2018 (UTC)[reply]

   Compassionate727, I believe that new users brought in from outreach events are in fact very different from new users from any other sources. As Rhododendrites says: "That's not to say there aren't still plenty of issues with e.g. notability and promotion -- just that someone who has decided to attend an editing event is unlikely to be editing in bad faith, and the help they receive decreases the likelihood of encountering other issues." As an editor who has facilitated a couple of editathons and who does a lot of New Pages Review and the physical deletion of 1,000s of pages, that is certainly the evidence I have encountered. The hard fact is that the reason 80% of new articles are deleted is that not only do they not meet our criteria, but the vast majority of them either have absolutely nothing to do with an encyclopedia, or are pure corporate spam, trolling, hoaxes, and other junk. As a New Page Reviewer yourself since Nov 2016, in front of the daily firehose of bilge water, you are probably keenly aware of this. Kudpung กุดผึ้ง (talk) 16:21, 18 April 2018 (UTC)[reply]

   @Kudpung: You to some extent misunderstood my statement: I only meant that they are the same in the respect that they aren't well-acquainted with policy. And while I would argue that, currently, corporate or autobiographical spam is the single greatest threat to the integrity of the encyclopedia, I find that, per capita, I'm significantly more likely to encounter good faith articles over marginally- or un-notable topics, which is precisely the kind of thing I would expect edit-a-thons to produce. I'm not saying I don't trust the good faith of users attending outreach events. But I will quote my response to these arguments below: "I fail to see how having coordinators move articles that they've clearly pulled up and read to the mainspace is a significant burden on them. The only thing I can see this permission doing is making it easier for participants to move articles to the mainspace without consulting their coordinator, and I'm not convinced that giving them the ability to do that would be a good thing." —Compassionate727 ^(T·C) 16:42, 18 April 2018 (UTC)[reply]

   @Compassionate727:We are not giving them autopatrolled, their work is still going to be reviewed by an new page patroller in any case. I don't see this as an issue given that pretty much all editathon editors will be editing in good faith. ACTRIAL was meant to stop the other kind of new editor so it makes sense for an exemption for editathons and outreach events. — Insertcleverphrasehere ^{(or here)} 17:00, 18 April 2018 (UTC)[reply]

   @Insertcleverphrasehere: I'm inclined to disagree. At least in my view, the prevention of bad faith editors is just one (albeit an important one) of the aspects that ACREQ addresses. Overall, ACREQ is meant to improve the quality of articles in the mainspace. It does so by eliminating the crapflow that we've been dealing with at NPP for years, but is also does so by preventing brand-new editors from creating articles entirely on their own (as these are likely to be deleted), and instead 1) seek guidance from more experienced editors or 2) wait until they have developed more experience. What this proposal aims to do (in effect, if not by intent) is eliminate the need for editors participating in outreach events to seek specific feedback for their articles before placing them in the mainspace, and I don't believe that's the right course of action. This won't help the encyclopedia, which will see an increase in articles arriving in the mainspace before they are ready (and therefore more articles ending up at AfD), and it isn't good for the outreach events, either, because the whole point of going to one of those events is to receive that specific feedback from other editors. —Compassionate727 ^(T·C) 18:49, 18 April 2018 (UTC)[reply]

2. Oppose Per Compassionate727. If I may add, this is one of those ideas that's great on paper, but when applied in the real world, leaves us open for abuse. Think about it, since none of us know each other in person, what's to stop a permbanned user from showing up, getting an account and editing as a sock for a while, with the added benefit of a nolimit on their contributions. I firmly oppose this. ►К Ф Ƽ Ħ◄ 16:08, 18 April 2018 (UTC)[reply]

   What's to stop a permbanned user from signing up for a new account, making 10 edits to their user page, and waiting 10 4 days? Nothing, and it would take less effort that finding an outreach event and physically traveling to it. The temporary 10-day-long confirmed right that would be given by an eventcoordinator is identical to what they would get by being autoconfirmed the traditional way. The (noratelimit) right, which allows for more than 6 accounts to be created from a single IP address in 24 hours, is already given to people claiming to be coordinators of outreach events via the accountcreator group. This proposal doesn't change that, and if anything is more restrictive, since it doesn't let the event coordinators override the username blacklist. --Ahecht (TALK
   PAGE) 16:27, 18 April 2018 (UTC)[reply]

   ^{Forgot to ping KoshVorlon. --Ahecht (TALK
   PAGE) 16:29, 18 April 2018 (UTC)}[reply]

   What's to stop someone from becoming an admin on enwiki and commons, getting blocked indefinitely from both, then getting admin rights again on commons with a sock, and then getting globally locked? GMG^talk 19:13, 18 April 2018 (UTC)[reply]

   Nothing, however, this proposal shortcuts that method and gives autoconfirmed right away . At least with the post limit, we stand a chance of stopping vandals and permablock accounts before too much damage occurs, as they can be seen early on, trying to boost their post rate by taking certain <not shown per WP:BEANS> actions.

   With Wikipedia working correctly, with all working parts (CU's, Admins...etc....) perm -banned and socks can be quickly caught and shutdown. With this procedure, while we would bring in good faith users, to be sure, we would also be rolling out the red carpet for socks, permabanned, etc as well. ►К Ф Ƽ Ħ◄ 14:05, 19 April 2018 (UTC)[reply]

   So, to clarify - what in particular in this procedure makes it easier for such editors to sneak back in than just registering a new account, doing 10 edits and waiting 4 days? (discounting for the moment the thing that makes it a lot harder - actually turning up at an event, instead of staying at home with the TV and the root beer). --Elmidae (talk · contribs) 14:27, 19 April 2018 (UTC)[reply]

   Ban root beer at editathons, problem solved. Cesdeva (talk) 14:38, 19 April 2018 (UTC)[reply]

3. Oppose I don't trust these "event coordinators" who have limited involvement with Wikipedia, and I know a few of them. Wikipedia's stupid emphasis on the number of articles as a unit of analysis works contrary to WP:N. We need editors to improve existing articles, especially considering that many edit-a-thons are RIGHTGREATWRONGS focused. We neither benefit from new users nor the articles they would create. New editors can go through AfC. Chris Troutman (talk) 21:13, 21 April 2018 (UTC)[reply]

   A curious sentiment, perhaps someone finished writing Wikipedia while I wasn't looking. Otherwise it's difficult to fathom such outright hostility to new users. Richard Nevell (talk) 21:55, 21 April 2018 (UTC)[reply]

   I agree that it's completely illogical to measure the worth of the Wikipedia on its number of articles rather than on the quality - but that's the WMF's policy. Like you Chris, I am highly skeptical of those of WiR who have almost 0 edits to the encyclopedia - one wonders where they got their experience - but as they are being paid by the WMF or their institutions, there's little we can do about it. However, many Outreach editathons are organised and delivered by users such as RexxS, Pigsonthewing and other members of chapters whom I trust implicitly to know what they are doing. Perhaps we shouldn't tar them all with the same brush. Kudpung กุดผึ้ง (talk) 05:25, 22 April 2018 (UTC)[reply]

   In fairness to the WMF, they are interested in measuring quality which is why ORES is under development. Richard Nevell (talk) 10:34, 22 April 2018 (UTC)[reply]

   Measuring, yes Richard, but if you follow closely all they have done and said over the years, it will become quite evident that their goal is quantity over quality. That's why they heavily finance WiR, their Education project, and any other actions that increase the number of new articles. ACTRIAL was originally demanded in 2011 by the community in order to address concerns of quality. The WMF refused to implement it for fears in a drop in new creations. This year they have been proven completely wrong but instead of addressing the needs to invest in improvements to software for NPP, they are looking at AfC - again with the intention of saving as many articles as possible and to heck with the quality. They have developed ORES in order to get some feedback from Artificial Intelligence, but they do not appear to have any intention of turning it into a useful tool for those working in maintenance areas. Kudpung กุดผึ้ง (talk) 20:47, 22 April 2018 (UTC)[reply]

   @Kudpung: Having formerly worked for a chapter I know something of what the WMF wants from its affiliates. To cast it simply as quantity reminds me of the story of the blind man and the elephant. Richard Nevell (talk) 23:23, 22 April 2018 (UTC)[reply]

   Precisely Richard, what the WMF wants is quantity, quantity, quantity. They decline to even acknowledge that quality is part of the equation that makes Wikipedia a trusted work of reference. I've spent hours at RL meetings arguing with them about it. Quantity is the elephant in the room (or more accurately: in the NPP feed), and that's exactly why we now have ACREQ. Kudpung กุดผึ้ง (talk) 23:35, 22 April 2018 (UTC)[reply]

   I'm afraid you have misunderstood. In this scenario the WMF is the elephant. They are not solely about quantity. I understand your experience differs, but I'm sure you appreciate it is not the whole story. Richard Nevell (talk) 23:41, 22 April 2018 (UTC)[reply]

   Richard, perhaps you misunderstood - WMUK is a chapter, I have spent several happy hours in their office, it has nothing to do with the way the people in SF think and work. My experience is broad and long - I battled with them for 6 long years to get ACTRAl in several meetings around the planet not to mention hours of video conferences with them and 1000s of bytes here on en.Wiki. If you are focused on quality, well yes, your articles (and GA) are excellent. Kudpung กุดผึ้ง (talk) 23:55, 22 April 2018 (UTC)[reply]

   As I said, I know a bit about what the WMF wants from its affiliates since chapters have to report to the Foundation. That isn't the whole picture of course, but in my experience the WMF isn't solely interested in quantity. It may not be trendy to stick up for the WMF, but I do prefer some balance. I'm not sure this contrarian battlefield attitude you have towards the WMF is particularly helpful. Richard Nevell (talk) 07:25, 23 April 2018 (UTC)[reply]

   @Kudpung: I'm not tarring Rexxs or Pigsonthewing, at all. My comments are specific to organizers with no experience. If our experienced editors want to use this right and ACC, I'm fine with it although I question why Wikipedia needs to buy new-editor participation and the cost of a live mainspace article. I'm opposed to giving this right temporarily to editors who lack the experience to be trusted. I can nominate all those articles for deletion, just the same. Chris Troutman (talk) 19:36, 22 April 2018 (UTC)[reply]

   @Chris troutman:, @Kudpung:.

   This may be a naive suggestion, but could this not be partially solved by having an RfC to clearly define the threshold that someone has to reach before they get granted the event coordinator right? Say 500 mainspace edits and 25 articles created? Point 3 of this RfC proposal is rather vague on what constitutes 'established'. Cesdeva (talk) 08:52, 23 April 2018 (UTC)[reply]

   I don't know details about how exactly WMF tends to implement things like this, but on another, related note, perhaps it would be possible to flag new accounts that are granted confirmed status by coordinators? This way, we could track the quality of content creation back to the associated coordinator(s) and sanction them if they perform unreasonably poorly in terms of article quality and retention. —Compassionate727 ^(T·C) 14:31, 23 April 2018 (UTC)[reply]

   @Cesdeva: Without turning it into a bureaucracy, I think we as a community could come up with a guideline admins can use when considering giving the right. Any user that has ACC is certainly experienced enough to be trusted. @Compassionate727: Adding that sort of accountability would do much to earn my trust. If their edits were flagged we could examine them and sort the editors who get it from those that didn't pay attention during training and remove the right as well as strip the "event coordinator" of their responsibility, too. Chris Troutman (talk) 16:24, 23 April 2018 (UTC)[reply]

4. Oppose I don't understand the purpose for this right because I see nothing wrong with requiring participants in events to create articles in draft space. In fact, I think this is the best course of action, so that they will be reviewed. Natureium (talk) 17:49, 25 April 2018 (UTC)[reply]

   @Natureium, I hope that I can change your mind and put your concerns to rest. These articles will be reviewed anyway as they will go into the NPP feed; confirmed is not autopatrolled. ACTRIAL/ACPERM was meant to put a speedbump in front of drive-by editors that are not here to build an encyclopedia, and there is no reason for this roadblock to be put in front of good faith editors at editing events. The other good reason to confirm editathon participants is to remove the requirement for a CAPTCHA every time they add a link in an edit (whenever they add references). This is annoying and disruptive to new editors adding lots of references or when they are messing with ref formatting (requires a CAPTCHA every time). — Insertcleverphrasehere ^{(or here)} 21:57, 25 April 2018 (UTC)[reply]

5. Oppose making this separate, support making it standard for AccountCreator. ―Justin (koavf)❤T☮C☺M☯ 07:18, 2 May 2018 (UTC)[reply]
6. Oppose - there’s a reason we ask people to gain experience before becoming auto-confirmed and being able to create articles straight into mainspace. That reason has not gone away so this proposal is not going to help the encyclopaedia Amisom (talk) 07:31, 2 May 2018 (UTC)[reply]

   @Amisom: - but surely the reason has gone away - the auto-confirmed (ACTRIAL/ACPERM) bump was to save NPP from the avalanche of vandalism, blanks and otherwise outright failures that were clogging up their assessing and generating the backlogs. Editathon participants are almost always good-faith, as well as getting some training and editing practice. So the vandalism and blank submissions will be few. The entries still have to go through NPP, and no doubt a few won't make it, but the benefits to the participants and hosts wouldn't be outweighed by disruption from failed submissions (plenty of auto-confirmed pages fail too, but obviously not enough to cause problems). Nosebagbear (talk) 15:00, 2 May 2018 (UTC)[reply]

   @Nosebagbear: (a) I'm not sure that the prevention of bad-faith articles is the only reason for the autoconfirmed flag being introduced. I think that the prevention of policy non-compliant articles (BLP violations, WP:N violations...) by inexperienced editors was another purpose. (b) Editathon participants are inded "almost always" good faith, but as has been pointed out, there is no guarantee - and if we exempt them from the restrictions of new accounts that provides an incentive for them not to be/ for those who have bad faith to abuse editathons. But mainly (a). Amisom (talk) 19:04, 2 May 2018 (UTC)[reply]

   @Amisom: You are no doubt correct that reducing policy-breaching articles would have been viewed as a secondary reason for some of the global consensus, and a pleasant side effect for many more. However there are a couple of reasons why that shouldn't be sufficient as to prevent a limited exception. There's the "good outweighs the bad" argument, that giving Editathon participants a chance to take their work all the way through to submit both encourages retention and helps them know what to do when on their own (vs say, copying via a senior editor). Additionally, autoconfirmed is such a low boundary, that the low number of edits (either 10, or whatever the average in 4 days is) would still leave a significant policy breach level vs newcomers. I would have thought (and I don't have evidence for this, but it seems reasonable) that overseeing experienced editors would lead to fewer policy breaches at an Editathon than those newly ACed. Nosebagbear (talk) 19:19, 2 May 2018 (UTC)[reply]

   Well well have to agree to disagree. Amisom (talk) 19:43, 2 May 2018 (UTC)[reply]

   I think you are missing the point that we do not restrict article creation to auto-confirmed accounts, and haven't done since the early days. We temporarily restricted it during ACTRIAL and will restrict it once ACPERM is enacted, which will be taking away the long-standing ability of unconfirmed editors to create articles. This new permission only reinstates the ability for new users at events to create articles, so it's really just returning to the long-term status quo for that very small subset of new editors. Boing! said Zebedee (talk) 15:05, 2 May 2018 (UTC)[reply]

   The community has determined that article creation should be restricted for new accounts. That was my point. Amisom (talk) 19:06, 2 May 2018 (UTC)[reply]

   Yes, and part of that consensus was to find a way to not impact negatively on new users at events. The point of ACTRIAL/ACPERM is to keep out the vandals, idiots and spammers, not editors being guided at coordinated events. Boing! said Zebedee (talk) 11:58, 3 May 2018 (UTC)[reply]

   @Boing! said Zebedee: To say that WP:ACPERM established consensus for this is not justified. While the majority of oppose votes cited this as the reason for their opposition, most support votes did not address this issue. The whole purpose of this RfC is to establish the consensus for this change. —Compassionate727 ^(T·C) 12:14, 3 May 2018 (UTC)[reply]

   Sorry, no, I don't mean to suggest ACPERM provided consensus for this specifically. All I really mean is that there seemed to be a clear desire (from many supporters and opposers) that new editors at events should retain their status quo and be able to create new articles - and that, indeed, is what this RFC is for. From your opening words here, I'd thought that maybe you'd thought that this proposal was extending rights to new editors at events that they had not had before - but I can see that is not the case. Boing! said Zebedee (talk) 12:54, 3 May 2018 (UTC)[reply]

• Question - not opposing, but can you explain how this differs significantly from the previous proposal less than a year ago (here)? In particular, the main reasons for the community rejecting the previous proposal seemed to be it not addressing what was felt was wrong with the draft process, which this proposal would similarly short-circuit, and why new users attending at edit-a-thons etc. should be treated differently from other new users. I'd like to see those points addressed, if possible. Thanks, Fish+Karate 14:39, 18 April 2018 (UTC)[reply]
  • The main difference is that we have created guidelines for how it should be used. The reason I did want to run this as a distinct RfC from WP:ACPERM was because this had been put to the community in two different ways last August, so I thought it best to let the questions be addressed. My thinking now is roughly the same as it was on the original proposal re: allowing account creators to do it: I support people having the tools they need. That was the main line of opposition from the ACPERM RfC, so I think that the community should consider it, which is why it is worth raising even if it did not gain consensus in the past. TonyBallioni (talk) 14:42, 18 April 2018 (UTC)[reply]
    • One other difference is that the previous proposal had quite a few people opposing because it would affect the results of the trial, which isn't an issue now that the trial is finished and permanently implemented. — Insertcleverphrasehere ^{(or here)} 14:54, 18 April 2018 (UTC)[reply]
    • Thanks both, happy with those responses. Fish+Karate 09:15, 19 April 2018 (UTC)[reply]
• Question: Can new users not move pages into the mainspace from the draft or user spaces regardless of whether they are confirmed or not? —Compassionate727 ^(T·C) 14:51, 18 April 2018 (UTC)[reply]
  • ​No. Moving an article to the main space requires the same rights as creating a new one. — Insertcleverphrasehere ^{(or here)} 14:54, 18 April 2018 (UTC)[reply]

Currently I'm leaning towards oppose, but I can certainly be convinced otherwise. My primary concern is that new users being brought in as part of outreach events creating articles in the mainspace will encounter the same problem that most other users encounter: they aren't familiar with the guidelines and policies and therefore cannot create articles that will survive deletion. How do outreach events operate, and are there people within those events that are either making sure the users know what they are doing or are otherwise overseeing the contributions to make sure they aren't problems? (For that matter, is there a page somewhere containing information on these events in general? I couldn't find one.) —Compassionate727 ^(T·C) 15:06, 18 April 2018 (UTC)[reply]

FWIW, I agree. I've been to editathons in the States, and the coordinators have always been very good to tell people to create things in their sandbox or in draft. The positive here even for that method is that giving them confirmed also allows them to move it themselves, which seems to be part of the objection. TonyBallioni (talk) 15:20, 18 April 2018 (UTC)[reply]

Every in-person editing event I've attended (many) has either begun with a group training/information session or has had such training available (sometimes in a dedicated side room). They are also typically attended by at least one experienced editor (there have been exceptions, but in this case we're taking for granted the person gaining and using this user right is an experienced editor). I would support increasing the requirements beyond that which we require of accountcreator, and I would support making it a requirement that the person using this userright be physically present with the users being granted confirmed status. Ultimately, people at these events are not there to vandalize, create attack pages, and almost always have received some basic instruction regarding best practices. They also have one or more experienced editors to help out to avoid other common pitfalls. That's not to say there aren't still plenty of issues with e.g. notability and promotion -- just that someone who has decided to attend an editing event is unlikely to be editing in bad faith, and the help they receive decreases the likelihood of encountering other issues. — Rhododendrites ^talk \\ 15:29, 18 April 2018 (UTC)[reply]

The autoconfirmed requirement, which is a VERY low bar to pass, is set up to prevent drive-by vandalism. It increases the effort required to post the first article, as the editor has to decide if posting it is worth waiting 4 days. However, I would argue that having to physically travel to an outreach event requires just as much, if not more, effort that simply waiting 10 4 days. Might some of the handful of people who are granted "confirmed" status by an "eventcoordinator" submit an inappropriate or even vandalism article? Sure, but so will some of the people who get "autoconfirmed" status the traditional way. The additional impact of this proposal on NPP will be negligible. --Ahecht (TALK
PAGE) 15:40, 18 April 2018 (UTC)[reply]

I'm not so concerned about the impact of outreach events on NPP itself (they aren't common enough to make a significant difference), nor do I expect users attending such events to be editing in bad faith. My concern is what we all seemingly agree to be true: that new users, regardless of their motive, aren't necessarily experienced enough to make acceptable contributions to the main space. And if what I'm reading above about receiving help from event coordinators is true (and I have no reason to believe it's not), then I fail to see how having coordinators move articles that they've clearly pulled up and read to the mainspace is a significant burden on them. The only thing I can see this permission doing is making it easier for participants to move articles to the mainspace without consulting their coordinator, and I'm not convinced that giving them the ability to do that would be a good thing. —Compassionate727 ^(T·C) 15:53, 18 April 2018 (UTC)[reply]

Also, Ahecht, because you've made this error in a couple of places, I should note that the time period requirement for autoconfirmed is 4 days, not 10. :) —Compassionate727 ^(T·C) 19:13, 18 April 2018 (UTC)[reply]

• Question: Is there any proof that participants in edit-a-thons consistently create higher quality articles? — pythoncoder  (talk | contribs) 15:55, 18 April 2018 (UTC)[reply]

• I'm not sure what there's data for, but the point of comparison for the purposes of this proposal should be autoconfirmed users not all new users. In other words, we would be granting confirmed status to a new user; are those confirmed users going to have more, fewer, or the same number of problems as an autoconfirmed user? Anecdotally, I cannot imagine it's more. Fewer seems likely, but regardless of whether it's the same or fewer, there's no reason not to move forward. — Rhododendrites ^talk \\ 16:06, 18 April 2018 (UTC)[reply]

The Wikimedia Foundation funds event presentations but does not fund administration. This means that they do not encourage the Wikimedia community to collect the kind of data which would answer this question. I would very much like to have this data but when time and resources are tight and the funding stream encourages other priorities, that means that this data either does not exist or when it exists hardly anyone is able to process it. The best data set is with the Wiki Education Foundation's classroom reports and related their instance of the dashboard outside their programs. See meta:Programs & Events Dashboard for the data collection tool. Personally I can vouch for using this tool 100+ times and consistently seeing good results in every meetup with totally new users. Many other people report the same. When someone actually comes to a meetup for 2 hours with intent to edit wiki they have an experience which is unlike sitting at home alone in front of a computer without having live conversation. I have no doubt that programs produce higher quality contributions in shorter times than typical online first experiences. Blue Rasberry (talk) 19:03, 18 April 2018 (UTC)[reply]

@Pythoncoder: I don't think there are global statistics about this, but you can make some approximations from the Art+Feminism metrics from March. You can see from our Dashboard metrics page that we created a little over 3000 articles (this does not include WiR's additional ~400, which is tracked on a meetup). You can see on the alerts page that about ~50 articles were flagged for deletion via Speedy, Prod, or AfD. Of those ~50, maybe ~30 were actually deleted. So 30/3000 = 1%. One percent of all new articles were deleted. That is quite different from the 80% deletion rate discussed throughout. I hope that helps put the quality of what goes on in events like ours in context. --Theredproject (talk) 22:19, 29 April 2018 (UTC)[reply]

• Change name to "Programs & Events coordinator"' All events are programs but not all programs are events. Examples of programs include ongoing multi-part classes, campaigns like Art+Feminism which happen as a training series culminating to an in-person event, and other activities which we include but which are not events. See meta:Programs & Events Dashboard for an established and popular "programs and events" tool. Blue Rasberry (talk) 18:58, 18 April 2018 (UTC)[reply]

• I think this gets at one issue with this proposal -- that the use cases are not so clearly defined. If it is indeed for outreach events, then "programs" strikes me as too broad. "Event" connotes some off-wiki engagement (and if it does not, it seems like it should), whereas it seems more difficult to define "program" as easily. If we're going to extend this to be for any "program", then we might as well reframe the user right to simply be a way for engaged, experienced non-admins to grant confirmed status to new editors, regardless of context. In that sense it's more about unbundling tools than something outreach-specific. I would probably support either, but I think it's important to talk about what exactly this is, since I don't think everybody would support the latter. — Rhododendrites ^talk \\ 19:59, 18 April 2018 (UTC)[reply]

• I was using the name Kaldari used in a previous proposal. I get the points you all are making, but I also support a shorter name, and program coordinator sounds like a WMF staff position. In terms of use, I tried to apply broad guidelines (we didn't have any the last time this was proposed, and these were what got consensus on the talk page). My view on any major RfC for a site-wide or policy issue is that the appropriate tweaks can be made in the immediate aftermath of the RfC based on the discussion and common sense for the non-contentious things. This is how most of these discussions end, and I don't think we need to get overly into the weeds here beyond a basic structure, technical limitations, and basic guidelines for admins granting and use, which is what we have here. Things can be tweaked and expanded later. TonyBallioni (talk) 20:04, 18 April 2018 (UTC)[reply]

• Also, seriously, the name isn't the end of the world. patroller means reviewer, reviewer means PC reviewer, and autopatrolled meant autoreviewer but we've cleared that one up except no, we haven't. That's not getting in to the sysop vs admin deal. Event coordinator is lengthy enough, we can afford to be slightly less than accurate here. ~ Amory (u • t • c) 01:54, 19 April 2018 (UTC)[reply]

• Integrate with software development for outreach Every year the Wikimedia Foundation runs a wishlist for the community to vote on software development projects. In 2017 a winning proposal at meta:2017_Community_Wishlist_Survey/Results was developing the meta:Community Tech/Programs and events dashboard. I just mentioned the meta:Programs & Events Dashboard above; actually there is an existing dashboard and the Wikimedia Foundation is considering whether to develop that one, make another one, or do anything else. Regardless, whatever happens, it would be good that if there is any software development to track programs and events, then that software should take into account the other user rights and implications of doing outreach. Anyone who cares about this proposal may also wish to comment on the software development happening right now as documented on the wishlist page at WMF Community Tech. Blue Rasberry (talk) 19:12, 18 April 2018 (UTC)[reply]

The current proposal is for a userright which would allow users who coordinate programs and events to assist new users in publishing their articles. This is a response to the recent adoption of WP:ACTRIAL.

Unrelated to the March 2018 adoption of ACTRIAL, there is also the March 2018 deprecation of the Wikimedia education extension, which was a 2011 software extension and userright set associated with outreach in classrooms and also events. Here is the relevant documentation.

• mw:Extension:Education Program
• discussion at Wikipedia:Education noticeboard
• discussion at Wikipedia:Account creator
• outreach:Education/News/February 2018/The Education Extension is being deprecated
• outreach:Talk:Education/Extension

There are years of discussion about what Wikipedians who do educational outreach should and should not do. The discussion runs the equivalent of 100s of pages of printed paper text. Users who did outreach in this program got userrights titled "campus ambassador", imagined for people who would go in person to schools; "online ambassador", imagined for people who would support programs and events online without appearing in person; and "course coordinator", imagined for users who could grant the other two userrights to any Wikipedia user at their discretion according to some light rules. I was a course coordinator until this month and have done documentation for outreach with the Wikipedia Education Program, Wiki NYC, and lots of other in-person outreach models.

The deprecation of the Education Program software extension was due to very outdated software, the advent of newer better equivalent software in the meta:Programs & Events dashboard, and a social trend to merge outreach practices and new user training regardless of whether it is for classes, one-time events, longer term campaigns, or other training situations.

I am sharing all this as context to a further proposal that I have for the "event coordinator proposal".

Proposal: documentation for outreach which applied to the 2011-2018 education userrights, and which applies to users of the Programs & Events dashboard, should also apply to anyone who gets this userright. This userright is not entirely a new idea, but actually is the convergence of a lot of previously separated ideas. TonyBallioni is on the crest of the wave of the zeitgeist with this proposal. With the need to deprecate software we were at risk of losing some social infrastructure, but if this userright becomes the legacy of outreach userrights, then we can take all the lessons learned, arguments over problems, and documentation developed about previous outreach userrights and apply them here to give a great headstart to this userright. I am not asking for anyone to accept every bit of documentation and policy from the old education program, but the similarities are so great that also I would not want anyone to fail to recognize that there was a previous outreach program with userrights and years of experience and discussion which could demonstrate how and how not to successfully administer this userright and support anyone who receives it. Blue Rasberry (talk) 02:15, 19 April 2018 (UTC)[reply]

• Note, technically there is no relationship to consider here anymore, eduprogram has been deprecated and NOONE has these rights assigned anymore. — xaosflux ^Talk 02:54, 19 April 2018 (UTC)[reply]

Event coordinators would benefit from getting this userright so that new users can publish new articles.

Something else that event coordinators need is the ability to assist new users in registering Wikipedia accounts. There is a restriction on creating more than 6 new Wikipedia accounts in one IP address in 24 hours. Typically events have lots of people in one room with one IP address all trying to register accounts. To get everyone registered, a common strategy is for the event coordinator to have Wikipedia:Account creator userrights, which allows that person in their own account to create Wikimedia accounts for everyone at the event.

I bring this up because probably everyone who gets this "event coordinator" userright will also need the "account creator" userright. In the case of the old education extension, there was a rule that anyone who had an education extension userright could also have the "account creator" userright. That may or may not be appropriate now, but whatever the case, we need a rule about this so that it is not a continual hassle for event coordinators to get all the support they need to host an event. Here are some ways this could happen:

1. "event coordinator" userright comes packaged with "account creator"
2. "event coordinator" userright comes packaged with a variation of "account creator" which permits creating extra accounts but without all the extra powers. "Account creator" has some odd abilities which are security vulnerabilities and which only advanced users use. I think there is consensus to freely let totally new users get a userright to make more accounts. There is no reason for new users to have all the powers of the current "account creator" userright.
3. Getting "event coordinator" means default approval in requests for "account creator", barring an unusual exception
4. Alternatively, maybe getting "account creator" grants "event coordinator" userrights

Somehow these two ideas are related! I have trouble articulating what should happen, but I know that many people who request one userright will want the privileges of the other! Blue Rasberry (talk) 02:26, 19 April 2018 (UTC)[reply]

• I think on the talk page Xaosflux actually suggested it would be better if this right did not have the extra features of account creator. The current proposal already has it to be bundled with no rate limit, which to my understanding allows creation of more accounts, but none of the other permissions intentionally because of feedback on the talk page and the initial RfC that suggested adding the ability to confirm accounts to account creator (pinging Xaosflux because he can explain these things much better than I can.) TonyBallioni (talk) 02:31, 19 April 2018 (UTC)[reply]

(1) Allow members to be able to create accounts in excess of the ratelimit

This can be achieved via the (noratelimit) underlying permission.

It would actually be preferable to replace this in the future with a yet-uncreated permission "noratelimit-account", but this is what we have to use for now. There is a security consideration with "noratelimit" that can affect other things, I don't want to spell them all out - but misuse would be grounds for revocation and blocking for disruption.

(2) be able to add (confirmed) access to other account.

This isn't a "permission", but a "configuration" - can easily be implemented.

Note: there is not currently a readily available technical means to make this only be for "temporary grants", but we certainly can have a "rule" for this.

Someone COULD have the "event coordinator" and the "account creator" access, but they would not need to for many of the use cases. The notable difference: account creators can override all sorts of name near-collisions, during an event it would be better to avoid this and have attendees pick a new userid; account creators can't also confirm users. In the general use case "I'm running an event on Month Day" - the new settings should be all that someone needs, and they should be removed when they don't need them anymore. In my opinion, if someone is running events like every month they should hold on to the access instead of constantly re-requesting until such time as they stop using it continuously. Hope this helps? — xaosflux ^Talk 02:53, 19 April 2018 (UTC)[reply]

Seems resolved Okay, I was mistaken, the original proposal anticipated and addressed this concern. I see no need to request any further consideration. I was mistaken and ignorant in raising this concern, which actually seems resolved. 17:18, 20 April 2018 (UTC)

• Question about the mechanics of (noratelimit) and its relationship to meta:Programs & Events Dashboard. First though: thank you for addressing the concerns of the many event organizers! Ok, the question: The ACC role also has (createaccount) and it is unclear to me (my ignorance) exactly which does what in the account creation process. Ragesoss which of these is the right that is used by the Dashboard to create accounts? This is how the tool is now meant to be used, as it automatically adds them to the dashboard event, and how Art+Feminism used it in our workflow. Initially we were having problems with account creation working, and as Ragesoss debugged the problem I understood that it was an interaction between two factors: 1) all accounts created via dashboard come from the one IP address of the Dashboard's server so 6 per that one IP for *all* events, not just per event for each 2) the account creation permissions are attached to the user when the Oath-enticate. I just want to make sure that the shift to this organizer specific role actually has all the permissions that organizers need. --Theredproject (talk) 22:06, 29 April 2018 (UTC)[reply]

  @Theredproject: created accounts may be impacted by both IP's AND the USER (or lack of user) that is creating the account. In that workflow, is there a credential involved? If so, which credential(s)? — xaosflux ^Talk 22:44, 29 April 2018 (UTC)[reply]

  @Xaosflux: the person who knows the details is Ragesoss aka Sage (Wiki Ed) who develops the Dashboard --Theredproject (talk) 23:01, 29 April 2018 (UTC)[reply]

  @Xaosflux and Theredproject: Programs & Events Dashboard currently utilizes OAuth rights for account creation and high volume editing, which allows users with account creator rights to create accounts through it without hitting the IP limit. All the OAuth actions happen through the dashboard's own IP address. My guess is that this would work without any changes for users who had the ability to create accounts without rate limiting via `event coordinator` rights. However, there's not (yet) as far as I can tell an OAuth grant for changing user rights, which means the dashboard probably won't be able to automatically add `confirmed` to the accounts created for an event (so the event coordinator would need to do that manually for each account created at the event).--Sage (Wiki Ed) (talk) 16:38, 30 April 2018 (UTC)[reply]

  Thanks @Sage (Wiki Ed): - 2 follow ups. (1) To be clear, the accounts are created under the userid of the "coordinator"? (2) Wasn't a configuration exemption created for this IP against rate limiting, affecting meaning the creator didn't need to be rate unlimited? — xaosflux ^Talk 16:59, 30 April 2018 (UTC)[reply]

  @Xaosflux: Accounts are created by the user who clicks 'create these accounts' and has the right to do so; that may be the person running the specific event, or it might be someone else helping out. See Theredproject's logs, as he was regularly monitoring for requested accounts for A+F events that hadn't been created yet. There was a very brief IP exemption at the beginning of A+F 2018 while we were fixing the OAuth configuration; I initially didn't realize that the OAuth consumer needed both 'create accounts' and 'high volume editing' rights in order to avoid the 6-per-day limit. A permanent IP exemption for account creation, without relying on user rights to limit who could use it, would be a security concern.--Sage (Wiki Ed) (talk) 17:22, 30 April 2018 (UTC)[reply]

  Just a note to clarify that, according to WP:User access levels, all users (with the exception of some blocked users) have the createaccount permission. --Ahecht (TALK
  PAGE) 22:17, 30 April 2018 (UTC)[reply]

"We neither benefit from new users nor the articles they would create." Is a strong contender for the single most idiotic thing anyone on Wikipedia has said, ever. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:34, 1 May 2018 (UTC)[reply]

@Pigsonthewing: It's probably polite to ping who you are quoting. Also, try indenting your comment in the right thread. Cesdeva (talk) 18:41, 1 May 2018 (UTC)[reply]

@Cesdeva: It is considered polite in RfCs not to clog up the voting with threaded discussion. Which is why we have a section titled "Discussion". Andy's comment is a fresh thread in the discussion section, and – regardless of the appropriateness of him making it – is actually indented accurately and in the correct place. --RexxS (talk) 21:21, 1 May 2018 (UTC)[reply]

There is no risk of 'clogging up' the oppose voting section in this RfC; it was clear from the ACTRIAL RfC that there would be little opposition to this proposal. Furthermore, this RfC has been almost stale for a while.

There is already a context established in another thread, and that is the most likely place for the quoted editor to notice the response.

Everyone can discern who is being quoted, so why is it not appropriate for the poster to make said editor aware?

Maybe they have by non-public means but it all looks a bit cloak and dagger from here. Which is disappointing.

I actually agree with the sentiment of what Andy Mabbett said. That's all I've got to say on this. Kind regards, Cesdeva (talk) 22:26, 1 May 2018 (UTC)[reply]

It's probably worth being clear about whether it would be better to bundle the ability to grant confirmed into the accountcreator group, rather than have a separate group for event coordinator. The pros of doing that would include not increasing the number of permission groups unbundled from sysop, and perhaps others that haven't occurred to me so far. However, the cons would be that we might sometimes be handing out accountcreator status to event organisers who we may feel are borderline experienced in handling permissions. Unfortunately accountcreator contains other abilities that I probably would want to set a higher bar to granting. Both the 'override-antispoof' flag and the 'tboverride-account' flag are rarely needed by event organisers, but are bundled with accountcreator. In other words, there is a range of editors' wiki-experience where I wouldn't be concerned about granting event coordinator where I would have reservations about granting the same editor accountcreator, principally because of the possibility of accidental misuse.

Now, it may be that I'm worrying about nothing, and that a reasonably high bar will be set to grant event coordinator anyway. If so, my concern disappears. But I suspect that we will want to be more liberal in giving (and taking back) this new right than we traditionally have (or ought to have) been for accountcreator. What do others think? --RexxS (talk) 15:59, 2 May 2018 (UTC)[reply]

I agree. There is no reason that event coordinators should need to have obtained the level of experience and trust required for 'override-antispoof' and 'tboverride-account'. Conversely, while the event coordinator permission would in most cases be granted temporarily for the duration of an event, there is no reason that account creators should have the perminant ability to grant confirmed status. --Ahecht (TALK
PAGE) 17:30, 2 May 2018 (UTC)[reply]

I think the bar for event coordinator may be pretty low, so probably best to keep them separate. I got the impression that there are two types of event coordinators. Those with quite a bit of experience, who should be OK, and those who are without, and whose competence may be open to question. If they muck it up, it would be appropriate to relieve them of the bit until they have shown they can manage it competently, but as I understand it, the permission is likely to be given to some people without much clue, and the less they can break the better. I am in favour of giving people the tools they need. · · · Peter (Southwood) ^(talk): 18:38, 2 May 2018 (UTC)[reply]

• Override-antispoof and tboverride-account are probably not needed by event coordinators, though they are not particularly dangerous permissions to have. I'd say it's more a question of thinking of a use case for the other accountcreator rights in this group (or +- confirmed in the accountcreator group) rather than worrying about whether someone will abuse these innocuous permissions. I do worry about devolving any abilities from admins, since it seems to push the bar for adminship higher and higher by removing "need" for the tools, but I don't think anyone would pass an RfA on the grounds of helping out with editathons so it's a moot point here. -- Ajraddatz (talk) 19:43, 2 May 2018 (UTC)[reply]

  I agree with much of what you say, Ajraddatz, but I'm not convinced that overriding the title blacklist is quite as innocuous as you suggest. Perusing MediaWiki:Titleblacklist shows a lot of potential for screwing up unintentionally. For example, even something as simple as copying a name from a rich-text document can inadvertently introduce undesirable characters – some of them invisible – which might result in an untypeable username. Then there's the possibility of creating a name that is is offensive to a particular group without realising it, or even of accidentally creating a username that looks like a LTA sock (which might result in a very short editing career). Considering the difficulty and unpleasantness of RfA for the past several years, it might be considered a Good Thing™ to continue to unbundle abilities: at least we have editors willing to do the jobs that the unbundling makes possible. --RexxS (talk) 22:46, 2 May 2018 (UTC)[reply]

  There's very little potential for screwing up unintentionally, since you need to check a box to override the title blacklist when making a new account, and any of the problems you list could be fixed within 3 seconds by a global renamer. I know I've said it before, but I always find it odd that on a website where we allow anyone to edit our front end user-facing pages, we obsess over what could happen if someone misclicks one of our administrative buttons. And the answer is that it, like an edit, can be reverted in a couple of clicks. As to unbundling, I still think the answer is to fix RfA instead of giving competent volunteers little pieces of advanced access, but that's just me and I doubt it will ever happen so point taken :P -- Ajraddatz (talk) 23:51, 2 May 2018 (UTC)[reply]