Wikipedia talk:User access levels

Request for Comment: Edit Count as a Requirement

During a joke edit war that occurred on April Fools’ Day, I earned the extended confirmed right for reaching 500 edits. This edit war was over the title of a section of Wikipedia:April Fools/April Fools' Day 2019, and resulted in over 100 edits being made by those who participated. This has made me want to ask: Should edits be counted towards Autoconfirmed and/or Extended Confirmed if said edits are made to the same section of an article within a given timeframe? InvalidOStalk 16:55, 7 April 2019 (UTC)

This is not a RfC matter, it is a technical question that properly belongs at WP:VPT. Anyway, the MediaWiki software has no way of distinguishing different types of edit, it does a simple count. --Redrose64 🌹 (talk) 23:06, 7 April 2019 (UTC)

Users who have automatically earned rights by “gaming the system”, making edits whose only apparent purpose was to ‘level them up’, can have those rights manually revoked.—Odysseus1479 00:04, 8 April 2019 (UTC)

@Odysseus1479: What is to prevent the software from automatically re-granting the right? --Redrose64 🌹 (talk) 19:28, 8 April 2019 (UTC)

That's a very interesting question right there. I know it basically isn't possible to revoke autoconfirmed status, anagement interface appears to make it possible to revoke EC. We need a test case: any volunteers, perhaps the OP? Beeblebrox (talk) 19:37, 8 April 2019 (UTC)

@Beeblebrox: feel free to revoke mine for a few hours (or days) if you want --DannyS712 (talk) 20:16, 8 April 2019 (UTC)

(edit conflict) @Redrose64: good question; I might be quite wrong about the above. I had thought the system only checked when an edit-count crossed the threshold, but now that I think about it, I’ve seen former admins getting automatically extended-confirmed on their first edit after the sysop flag was removed, and of course thousands of users were already over 30/500 when the feature was first rolled out. So I probably misunderstood something I heard.—Odysseus1479 19:56, 8 April 2019 (UTC)

@Odysseus1479 and Redrose64: see mw:manual:user_former_groups table --DannyS712 (talk) 20:17, 8 April 2019 (UTC)

With the current configuration: Automatic promotion to extended confirmed will only happen once. MediaWiki checks that the granting requirements (500 edits, 30 days old, not sysop, and not bot) are met when the user makes an edit. — JJMC89 (T·C) 04:40, 9 April 2019 (UTC)

• To answer some of the questions above. Automatic assignment of extendedconfirmed will only ever happen once per account, it is configured in the settings as wmgAutopromoteOnceonEdit, so if it is ever revoked it needs to be manually re-added. Our current configuration with the way we use pending changes doesn't make it easy to make this harder to game - there are other projects that use a more complicated multi-variable promotion system but it would be hard to scale that here. So that's about it for the technical aspects. Those that game the counter can have it revoked and would need to reapply and be evaluated by an admin, in practice that is only going to happen if someone complains about an editor, generally because they are 'using' their new extenedconfirmed gamed access to also do something disruptive or against arbcom topic controls. If you just edit normally and stay away from issues it likely will just be left alone. If you really want your access removed drop me a talk note and I'll do it for you (you will need to reapply in the future at WP:PERM though). — xaosflux ^Talk 14:51, 12 April 2019 (UTC)

Request for comment: Require that users be autocofirmed before they can create pages in the Portal: space

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I was shocked when I found that User:NAMDAR56 (contributions) was able to create a (now deleted) portal a mere 3 days after setting up an account. This seems to me an enormous BLP/Vandalism/sockpuppet/other problems risk. Users should have to be autocofirmed before they can create pages in the Portal: space. (Previously opened and then closed at WP:AN; pinging @Legacypac:, @GiantSnowman:, @Kusma:, @Thryduulf:, @Robert McClenon:, @173.228.123.166:, @CorbieVreccan:, who !voted over there). UnitedStatesian (talk) 14:06, 11 April 2019 (UTC)

• Support as proposer. UnitedStatesian (talk) 14:06, 11 April 2019 (UTC)
• Support as per at AN. GiantSnowman 14:10, 11 April 2019 (UTC)
• Support - At this time, with portals being contentious, new accounts who create portals recklessly are likely to be suckpoppets. Robert McClenon (talk) 15:43, 11 April 2019 (UTC)
  • @Robert McClenon: I think you meant sockpuppets.... — Arthur Rubin (talk) 01:51, 17 April 2019 (UTC)
    • User:Arthur Rubin - Yes, both. They are puppets made from footwear, and they suck poppets, whatever poppets are. I think the nominally incorrect form does a good job of conveying my disgust about them. Robert McClenon (talk) 02:45, 17 April 2019 (UTC)
• Support I read in one of the portal newsletters how the portal spammers made more portals in 9 days then everyone in a year for many years. Yes, anyone "new" making a portal now is likely to be a sock. I don't know if it is worth coding into the software or nust watching for new creations and nuking them as housekeeping based on a prohibition. Also portals built properly require skill. Could we consider protecting the space to extended confirmed 500/30 days? Legacypac (talk) 15:50, 11 April 2019 (UTC)
• Support As per discussions at AN. Also want them tied in to Wikiprojects. Not a fan of the shape some of these portals are in. Keep finding ones I didn't even know existed. This is the bare minimum we need to do to fix these. - CorbieV ^☊ ☼ 16:52, 11 April 2019 (UTC)
• Support per obvious. Leviv ich 05:19, 12 April 2019 (UTC)
• Oppose, rarely a problem, no obvious need for further general restrictions. We might not trust new editors to create new portals, but why shouldn't they be allowed to contribute to portal maintenance? That requires being able to create new subpages. The unclear BLP/vandalism risks rather suggest to fully protect all articles instead of disallowing page creation in a namespace rarely visited by the public. —Kusma (t·c) 06:08, 12 April 2019 (UTC)

  @Kusma: depending on the mechanism that is used to enforce this if approved, this could be used to only prevent creation of "base" portal pages. (We could use the editfilter to prevent these instead of a backend namespace restriction). — xaosflux ^Talk 14:18, 12 April 2019 (UTC)

  @UnitedStatesian: would preventing pages along the lines of Portal:Pppppppp be sufficient, or is there an actual problem with editors creating Portal:Pppppppp/Subpages as well? — xaosflux ^Talk 14:22, 12 April 2019 (UTC)

  I think preventing both makes sense, and in fact preventing the subpages may be more important because 1) there are many more subpage than top page creations, making them much harder as a group to monitor for the odd problematic creation, and 2) portal code is undocumented and very opaque as to how a given subpage is made visible its parent portal. UnitedStatesian (talk) 14:28, 12 April 2019 (UTC)

  UnitedStatesian, why is creating portal subpages more "dangerous" than editing existing portal subpages? —Kusma (t·c) 14:42, 12 April 2019 (UTC)

  Because undoing a bad edit can be done by any editor, but undoing a page creation requires action by an administrator (often only after an MfD has concluded). But I think you knew that already. Neither I nor anyone else used the word "dangerous"; why is it in quotes? UnitedStatesian (talk) 14:46, 12 April 2019 (UTC)

  UnitedStatesian, that means it is more work to undo, but it is in no way more "dangerous". —Kusma (t·c) 17:00, 12 April 2019 (UTC)

• Support would be good for BLP as well as preventing portalspam. —pythoncoder (talk | contribs) 13:18, 12 April 2019 (UTC)
•  Administrator note @UnitedStatesian:, I've created an edit filter to log these so you can see the impact (and also monitor any pages created), to access the log use this link. — xaosflux ^Talk 14:43, 12 April 2019 (UTC)

  Thank you, very helpful, but I would prefer to spend my time on other tasks confident that I did not have to worry about these page and subpage creations. UnitedStatesian (talk) 14:48, 12 April 2019 (UTC)

  @UnitedStatesian: that is really just for the benefit of getting stats while your RfC is open - should it be approved that filter could be changed from 'log' to 'disallow' (hopefully with an accompanying friendly template explaining what is going on to the editor). — xaosflux ^Talk 14:52, 12 April 2019 (UTC)

  Ah, understood, thanks again. UnitedStatesian (talk) 15:29, 12 April 2019 (UTC)

• Support. no reason why it should be more accessible than mainspace. · · · Peter Southwood ^(talk): 06:40, 13 April 2019 (UTC)
• Support per pretty much all of the above. Portals are a form of site structure and navigation, something that requires some experience to do well. WP is "the encyclopedia anyone can edit" (i.e., work on the encyclopedic content). It is not "the website anyone can reconfigure".  — SMcCandlish ☏ ¢ 😼  01:00, 14 April 2019 (UTC)
• Support I admit my first reaction was that this isn't that big of a problem, but it does have the potential to be one so why not close the loophole. Beeblebrox (talk) 01:11, 14 April 2019 (UTC)
• Support While at first it came off as a solution in search of a problem, it makes sense that editors who cannot create new pages should not create portals either. The creation of portals is a relatively complex thing, and autoconfirmation is a low bar. Others have made the point that new users/IPs could use portalspace as a vehicle for spam and vandalism. PrussianOwl (talk) 15:27, 16 April 2019 (UTC)
• Support - Pretty much per SMcCandlish. I also think Xaosflux edit filter is the way to go. - FlightTime (open channel) 15:42, 16 April 2019 (UTC)
• Comment. Not opposed in principle but this seems a bit of a solution in search of a problem; all the vandalism I can recall encountering in portal space has been IP mediated, but I've never seen an IP attempt to create a new subpage, let alone a new portal. Is there any evidence this goes beyond the single editor noted? Or that it can't be handled by blocking unproductive editors? Would the proposed solution create a burden with the underlying system? To be honest, I had not realised portal space was different from mainspace in this regard. It makes sense to allow very new users to create user pages and all forms of talk pages, but perhaps not others -- what's the situation with Wikipedia, Template & Category? New templates are probably needed for DYK. New categories seem more of a common problem. Espresso Addict (talk) 18:01, 16 April 2019 (UTC)

  @Espresso Addict: in general we're the free encyclopedia that anyone can edit - and this extends to creating most pages (notably not 'article pages'). These creations appear to be quite rare. — xaosflux ^Talk 18:32, 16 April 2019 (UTC)

  I don't think that search works right, but since 12APR there have been none. — xaosflux ^Talk 18:33, 16 April 2019 (UTC)

  I believe I've seen that tagline once or twice, Xaosflux. My point is there appears no obvious reason to treat portal space differently from other non-article space entities. I've seen abundant evidence over the years of disruptive AfDs & duplicative/disruptive categories being created by newbies, but before this single example, none of disruptive portal-space page creation. Espresso Addict (talk) 18:43, 16 April 2019 (UTC)

• Support if technically feasible, creating new portals isn't something new editors should be experimenting with. Hut 8.5 18:46, 16 April 2019 (UTC)
• Support per above. -FASTILY 19:49, 16 April 2019 (UTC)
• This seems a bit specific. New users, before they even become autoconfirmed, sometimes create a template. For example: {{Brexit Party}} and {{Latest stable software release/Cốc Cốc}}. NinjaRobotPirate (talk) 05:21, 17 April 2019 (UTC)
• (Summoned by bot) Support Would make less clutter at MfD. SemiHypercube 10:53, 17 April 2019 (UTC)
• Support as it should be in harmony with the requirements to create a new article in mainspace. Desertborn (talk) 13:08, 17 April 2019 (UTC)
• Support should really apply to any namespace that isn't User, Draft, or Foobar Talk, really. Perhaps with exceptions made for subpages of pages that already exist. Headbomb {t · c · p · b} 15:22, 17 April 2019 (UTC)
• Oppose per WP:CREEP. No evidence presented that this is a widespread problem. feminist (talk) 18:13, 17 April 2019 (UTC)
• Support, due to the portal problem still being overblown. Probably should be temporary to avoid WP:CREEP until the portal problem is resolved, though. Kirbanzo ^{(userpage - talk - contribs)} 17:13, 18 April 2019 (UTC)
• Support: portals are by and large a waste of time and new users shouldn't be pulled into thinking that it's productive. They should be shown or find for themselves a more useful area of Wikipedia to lend their talents to. — Bilorv (he/him) _(talk) 19:55, 18 April 2019 (UTC)
• Weak oppose per feminist. I understand the arguments about parity with mainspace, but given that this hasn't really been a problem, I don't see how taking preventative action would be a net positive. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 22:48, 18 April 2019 (UTC)
• Support but I wouldn't class the risk as "enormous". Currently the main risk is that good portals will get scrubbed along with pointless portals in the current frenzy of portal deletion. Bermicourt (talk) 21:08, 19 April 2019 (UTC)
• support per users Legacypac, PrussianOwl, McCandlish, and Zaphod. —usernamekiran(talk) 05:25, 20 April 2019 (UTC)
• support: The restrction of creating pages should really apply to any namespace that isn't User, Draft or all talk pages per Headbomb. (Usernamekiran I fixed typo, not Legacypack but Legacypac. Hope you would not mind. ) --94rain ^Talk 04:28, 21 April 2019 (UTC)

  @94rain: Hi. Thank you for fixing the typo I do not want to be rude, but kindly read WP:TPO. See you around :) —usernamekiran(talk) 05:03, 21 April 2019 (UTC)

• Support per above.Pharaoh of the Wizards (talk) 21:21, 21 April 2019 (UTC)
• Support. An obvious loophole that needs closing.

I agree entirely with @Bilorv's observation that portals are by and large a waste of time. All except the 8 portals which are advertised in prime position at the top right of the main page attract risible viewing figures compared with their head articles, with the ratio of readers preferring the head article being overwhelmingly in the range of 100:1 to 2,000:1.

So I'd support restricting portal creation to editors who appear in person at exactly 11:59 on the first Tuesday of July at the South Pole with at least 5 great-great-grandparents and a lawyer for each, all of whom must sign an affidavit that they genuinely want to do this folly. --BrownHairedGirl (talk) • (contribs) 22:31, 21 April 2019 (UTC)

• Support per all. Even without all the recent Portal drama mainspace pages require autoconfirmation and there's no reason portals should be any different. John M Wolfson (talk) 02:44, 23 April 2019 (UTC)
• Support - Ideally everyone should be prohibited from creating portals since they are completely useless (now that we have navboxes plastered everywhere), but this seems like a good start. Kaldari (talk) 05:37, 23 April 2019 (UTC)
• Support Whilst slightly concerned about WP:CREEP, in this instance the proposal simply aligns portal creation with article creation (trialled at ACTRIAL) and voted overwhelmingly to permanently extend to autoconfirmed users here. We must remember that the community voted at an RfC in favour of portal retention. These recent piecemeal proposals to restrict portal creation should not be seen as giving the 'anti-portalists' a 'second bite at the cherry' to delete them all again, albeit this time by stealth, but must only be common sense measures to ensure portals are able to work effectively for those Wikipedia users who do choose to visit them as a shop window and an alternative route in to finding articles that interest them. Just as with articles themselves, the numbers of people who visit them should never be a factor in their retention or deletion. They have to work for those who do use them, and, of course, too many shop windows popping up just leads to a confusion on the high street. Restricting their creation to autoconfirmed users seems both logical and proportionate, yet is probably never ever likely to be a serious issue to get het up about, unlike instant article creation by myriads of brand new users. Nick Moyes (talk) 00:04, 24 April 2019 (UTC)
• Support. Surprised to find it isn't already the case. WaggersTALK 13:20, 25 April 2019 (UTC)
• Support. No reason for this level of functionality to be so accessible. Britishfinance (talk) 10:17, 26 April 2019 (UTC)
• Support per other support recommendations above. --Metropolitan90 (talk) 01:42, 27 April 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.