Wikipedia:Requests for comment/Event coordinator proposal

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Requests for comment

This is an old revision of this page, as edited by KoshVorlon (talk | contribs) at 14:05, 19 April 2018 (→‎Oppose). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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]


Support

  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 (TALKCONT) 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]

Oppose

  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? GMGtalk 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]

Neutral

Discussion

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

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 a week and a half. 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]
  • 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]

Relationship with education extension userrights

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.

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]

Relationship with account creator rights

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]

Hi @TonyBallioni: and @Bluerasberry: from a quick re-read of above, the goals of creating this new user access group are to:

(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]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/Event_coordinator_proposal&oldid=837224393"