Swept in from the pub

So how did that happen, I though the page was protected from new users? --Traveler100 (talk) 10:35, 12 September 2015 (UTC)Reply

It was restricted to autoconfirmed users (the only other restriction available is to restrict to admins). Somewhere there is a $wgAutoConfirmAge and $wgAutoConfirmCount. It looks like the latter (and possibly both) are still at the default values of 0, which renders the restriction useless. I have temporarily restricted editing to admins. Anyone know how to put some sensible values to those two settings? Nurg (talk) 11:44, 12 September 2015 (UTC)Reply

Looks like it needs to go thru Phabricator. Info about WP's settings are at w:Wikipedia:User access levels#Autoconfirmed users. Shall we go with the same settings, incl the variation for Tor users? Nurg (talk) 12:00, 12 September 2015 (UTC)Reply

Per Wikivoyage:Autoconfirmed users, $wgAutoConfirmAge should be set to 4 days. Don't both the age and edit count criteria have to be met to be autoconfirmed? Or is it either/or? Powers ^(talk) 15:02, 12 September 2015 (UTC)Reply

Thanks, I was rushing and didn't see that page. So it seems we have age set to 4 days and count set to 0. Both criteria have to be met, but any criteria set to 0 is automatically met, so we have only an effective age criteria at present. Any budding vandal who creates a sleeper account and just waits 4 days, will be autoconfirmed. Shall we follow Eng WP and get the edit count set to 10? Nurg (talk) 22:36, 12 September 2015 (UTC)Reply

Full support from me for matching the WP settings for autopatrolled status. -- Ryan • (talk) • 22:41, 12 September 2015 (UTC)Reply

Sure, set the same parameters as Wikipedia. Ikan Kekek (talk) 23:30, 12 September 2015 (UTC)Reply

I would also strongly support this change - otherwise, it's a major liability. --Nick ^talk 22:12, 13 September 2015 (UTC)Reply

I don't care what settings are chosen, so long as they're not zero/zero. There are remarkably few pages, mostly major templates like {{see}}, that are semi-protected, so this decision is really about the point at which a newbie should be able to directly edit listings templates. There are no articles under either semi or full protection. Different Wikipedias have chosen different settings. It's been a long time since I looked at that, but I believe that the typical range runs from four to ten days, and from ten to twenty edits, with a few choosing even looser or even tighter restrictions. Nurg is correct that this is a "both/and" criteria, not an "either/or" thing. WhatamIdoing (talk) 17:31, 14 September 2015 (UTC)Reply

We have a particular user who isn't a vandal as such, called Turbo8000. Please see Wikivoyage:User ban nominations

Their edits are of very poor quality, combined with a personal sense of infallibility even when consistently proven wrong. Every single edit they make requires checking.

Can we possibly exempt this user from becoming an Autoconfirmed user? This would highlight every edit they make as well as preventing them from moving pages where they obviously don't know what they are doing.

We could always remove this exception later if their behavior changes and their edits become trustworthy. --Andrewssi2 (talk) 23:18, 19 January 2016 (UTC)Reply

This is quite a creative idea! It could be a good way of allowing Turbo8000 to edit and (hopefully) become more sensible, without giving him too much power to just do what he wants all the time.

Just for the sake of playing devil's advocate, mightn't that set something of a precedence for new users to be nannied by admins? Of if you decide to make Turbo8000 a case all by himself, might that not make him act out further? While I do want to believe he is a genuine user who wants to help, my instincts tell me he likes the attention generated around him from being a nuisance. In paying special attention to his edits (which I've been guilty of too, these last couple of days), that just feeds into it. --ThunderingTyphoons! (talk) 23:45, 19 January 2016 (UTC)Reply

I like the sound of this procedure. It's worth trying. The more options of damage control, the better, I think. Let's go for it. Ibaman (talk) 00:00, 20 January 2016 (UTC)Reply

I would say all new users shouldn't be nannied by admins. As far as I can tell this isn't required in over 95% of new users and ideally only be done in exceptional circumstances when we are trying to avoid a ban situation (i.e. giving certain articles a minimal protection rather than an admin-only projection).

Also I'm not speculating on Turbo8000's motivation, just trying to take steps to limit the issues that they are causing. --Andrewssi2 (talk) 00:50, 20 January 2016 (UTC)Reply

I like this, but I think this should be exceptional, requiring individualized action, and that the default for autoconfirmation should remain as it is. Ikan Kekek (talk) 01:30, 20 January 2016 (UTC)Reply

OK then. I'm on board. --ThunderingTyphoons! (talk) 11:02, 20 January 2016 (UTC)Reply

Does anyone have a suggestion how to actually do this? The ability to removed from the confirmed users group is limited to Bureaucrats Andrewssi2 (talk) 20:02, 20 January 2016 (UTC)Reply

Swept in from the pub

I asked a question on Wikivoyage_talk:Autoconfirmed_users about revoking the confirmed status of users who have been editing for more than 4 days, but are consistently making incorrect and poor edits. I'm not sure about the technical feasibility, process or potential drawbacks for doing this. Can anyone comment? --Andrewssi2 (talk) 22:33, 21 January 2016 (UTC)Reply

It's not possible (from a technical perspective). You can change the settings (e.g., six days and 20 edits) or you could perhaps use PendingChanges to do something like this. WhatamIdoing (talk) 19:16, 23 January 2016 (UTC)Reply

Thanks WhatamIdoing . I notice the Abuse Filter can automatically revoke an auto-confirmed status, although I really don't want to use the Abuse Filter for this kind of user management. Andrewssi2 (talk) 20:39, 23 January 2016 (UTC)Reply

Swept in from the pub

Contributions by User:Air fans appear in Recent Changes with a ! even though they are an autoconfirmed user. Air fans is a reliable contributor whose contributions do not need to be patrolled. Does anyone know how to fix this? Ground Zero (talk) 22:19, 16 April 2021 (UTC)Reply

That is the difference between auroconfirmed users and autopatrollers. AlasdairW (talk) 22:28, 16 April 2021 (UTC)Reply

I guess I don't understand the difference, but I guess I can fix the problem by making them an autopatroller. Ground Zero (talk) 22:42, 16 April 2021 (UTC)Reply

Wikivoyage:Autoconfirmed users vs. Wikivoyage:Autopatrollers Nelson Ricardo (talk) 23:11, 16 April 2021 (UTC)Reply

I made Air fans an autopatroller earlier this afternoon. Ikan Kekek (talk) 23:23, 16 April 2021 (UTC)Reply

Thank you both. Ground Zero (talk) 13:59, 17 April 2021 (UTC)Reply

Continuing the discussion we had on Wikivoyage:Travellers' pub#Vandalism on Template:See also, there seems to be broad support that the current criteria, 4 days and 0 edits, is not sufficient enough. This is largely due to how easy it is to get a sleeper account to become autoconfirmed.

I propose making the criteria 4 days and 5 edits. 5 edits is enough to know whether a user is a good-faith user or if their true intentions are to vandalise/spam. This is the same criteria also used on Meta-Wiki, which has worked very well. I'd like to adopt the same here.

--SHB2000 (t | c | m) 10:39, 10 July 2024 (UTC)Reply

I don't think you can identify vandals based on those edits (discussion better held away from the public), but they require some manual work for every one, which is enough to keep the number of sleeper accounts down. –LPfi (talk) 13:10, 10 July 2024 (UTC)Reply

The other aspect is what is lost with the change. Autoconfirmed users can edit pages locked for those not confirmed. The change should raise the bar for that kind of locking, which may have a drawback.

On the other hand, a good-faith editor who bothers to create an account and comes back after five days probably already reached the five-edit threshold. We probably have some good-faith editors who create a throw-away account for a single edit (believing you need to register), but those who remember their password probably make several edits.

–LPfi (talk) 13:18, 10 July 2024 (UTC)Reply

In any case, we can always manually confirm good-faith users need it be. --SHB2000 (t | c | m) 14:04, 10 July 2024 (UTC)Reply

The problem is with those whom we don't know about. If they have less than five edits, we probably don't know them (other than those from other projects doing advanced work). The problem is a user who tries to do an edit but is stopped by a locked page. They may simply leave. –LPfi (talk) 14:30, 10 July 2024 (UTC)Reply

I think the solution to that would be to make a venue where non-autoconfirmed users can request changes and providing more helpful guidance on MediaWiki:Semiprotectedpagewarning than what we have right now. --SHB2000 (t | c | m) 23:35, 10 July 2024 (UTC)Reply

What do you think about requiring 4 days + 1 edit? That will stop anyone whose goal is just vandalism, especially since most don't know what autoconfirmed means, or that the levels can be different. WhatamIdoing (talk) 16:34, 10 July 2024 (UTC)Reply

I was thinking that. Autoconfirmed with 0 edits just seems wrong, but 5 edits is an arbitrary number. Ikan Kekek (talk) 17:05, 10 July 2024 (UTC)Reply

I support 4 days and 5 edits. 1 edit doesn't tell you anything. OhanaUnited^{Talk page} 22:03, 10 July 2024 (UTC)Reply

I think 1 edit doesn't tell you much. While vandals probably don't know what it means to be "autoconfirmed", long-term abusers probably do know (and will probably make 1 innocuous edit to their userspace to evade this). 5 is enough edits to tell whether they're here to stay or not. --SHB2000 (t | c | m) 23:33, 10 July 2024 (UTC)Reply

But why 5 in particular? Would it be any different for the number of edits to be 4, 3 or whatever? Ikan Kekek (talk) 04:38, 11 July 2024 (UTC)Reply

I think I'm just slightly opinionated that it's worked fine on Meta (a lot of the disruption over there comes from IPs who are globally blocked anyway, which isn't a problem on any other wiki). --SHB2000 (t | c | m) 04:45, 11 July 2024 (UTC)Reply

to be clear, I'm fine with 3 or 4, just anything is better than 0–2 (and even 1 or 2 is better than 0 edits). --SHB2000 (t | c | m) 04:46, 11 July 2024 (UTC)Reply

Sleeper accounts are about long-term vandals, and most of them probably know how things work. For those it is about the work needed to create an autoconfirmed sleeper account. One edit is easy, but one edit for each of ten accounts is not negligible. For the number, the critical thing is how many edits a new long-time good-faith user will do with their account in the first 3–5 (or whatever) days. I suppose that they'd do more than 1, probably at least 3 – but I have no statistics. We should have as high a threshold as we can, as long as it doesn't keep those good-faith new accounts unconfirmed. –LPfi (talk) 05:42, 11 July 2024 (UTC)Reply

2 edits is the 50% point at the English Wikipedia. Half of contributors make 1 or 2 edits (ever, but mostly on the first day), and half make 2+ edits (ever, but the accounts that stop after a small number of edits generally only edit on one or two days). I don't remember the equivalent numbers here, but it's probably not very different. WhatamIdoing (talk) 23:07, 11 July 2024 (UTC)Reply

Do you think we can go with three, then? --SHB2000 (t | c | m) 23:11, 11 July 2024 (UTC)Reply

I've found the local numbers. Our median editor makes 3 edits. About 30% of Wikivoyage contributors make 5+ edits.

As a general rule, accounts that make an edit will usually do so on the day they created the account, and those with very few edits only edit for one or two days. (Some of this is obvious; if you only make 3 edits total, then you can't make edits on 4+ different days.)

SHB, I think we can go with any number that we want. The question is: what percentage of editors do you want to exclude? WhatamIdoing (talk) 23:13, 11 July 2024 (UTC)Reply

That's true. I'm with LPfi on "We should have as high a threshold as we can, as long as it doesn't keep those good-faith new accounts unconfirmed.", which to me, 1 or 2 edits sounds like a bit too low. --SHB2000 (t | c | m) 00:53, 12 July 2024 (UTC)Reply

Just to clarify, what problem are we trying to solve here? As far as I can tell (correct me if I'm wrong), this discussion came about because of recent vandalism on Template:Seealso, which was done by a user who apparently wasn't autoconfirmed even under the current criteria. Is there actually a need to increase the autoconfirmed threshold? In my opinion, a change that makes it harder for users to edit should only be made if there's a good reason. —Granger (talk · contribs) 01:29, 12 July 2024 (UTC)Reply

The discussion regarding the vandalism on {{seealso}} incited it, but it has been a known problem for a while. I have had sleeper LTA accounts vandalise my talk page (even though you wouldn't typically be able to do so).

Making it easy for long-term abusers is one very good way to make this wiki a target for long-term abusers that do know it means to be autoconfirmed. Special:Protectedpages lists only 57 out of 32,595 pages protected (and this number is higher than usual due to the New Jersey LTA, and this includes pages like the main page, dotm pages, certain redirect pages), so in theory, the chances of a non-autoconfirmed user actually landing on such a page is about 0.17 per cent (or 0.0017 out of 1).

If you exclude those, that brings the number down to 45 out of 32,595, about 0.14 per cent (or 0.0014 out of 1). The chances of a new user actually being affected by a protected page is so slim that it's nearing a non-issue, and even then, this can be easily mitigated by providing a good venue and providing good guidance – every other large wiki has done this for years without issue, there's no reason why we have to put it in the too hard basket. --SHB2000 (t | c | m) 02:05, 12 July 2024 (UTC)Reply

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ You draw too strong conclusions. A new editor is quite a bit more likely to edit Israel than to edit Petäjävesi. High-profile pages are more likely to be edited by new users as well as vandals. Anyway, if those who are going to edit the fifth day are likely to already have made three edits, then requiring three edits for autoconfirmed is no big deal. For vandals, the effort for two edits is double that for one edit, while the difference between four and five is small. I'd settle for three. Mechanisms for edit requests or applying for autoconfirmed are no alternative for direct editing: few will use those. –LPfi (talk) 05:29, 12 July 2024 (UTC)Reply

The autoconfirmed status does have some importance, behind the scenes. –LPfi (talk) 05:35, 12 July 2024 (UTC)Reply

So the problem we're trying to solve is LTAs vandalizing SHB2000's user talk page? If so, I think this is misguided. User talk pages shouldn't be protected except in exceptional circumstances, since they're the usual way for new users to ask questions or find out why an edit was reverted. Vandalism on a user talk page is annoying but fairly harmless – it's easily reverted and doesn't affect readers the way vandalism to a content page does. —Granger (talk · contribs) 17:05, 12 July 2024 (UTC)Reply

It may be very cruel to the user though (which may cause us losing high-profile editors). But LTAs using multiple accounts to vandalise destination pages is not uncommon. I am uneasy to have this track of the discussion in public, but I think that we should try to deter the creation of sleeper accounts to the degree we can without causing any significant collateral damage. I am certain that page locks and filters have much bigger probability of losing a user on their first edit than that same user on their fifth-day third edit. –LPfi (talk) 17:47, 12 July 2024 (UTC)Reply

No, that's not a problem, at least on this wiki or cross-wiki anymore, but it was merely an example I brought up on why 0 edits is a bad idea for autoconfirmed. --SHB2000 (t | c | m) 22:08, 12 July 2024 (UTC)Reply

and for the record, this wasn't achieved through page protection – I won't say how this is now achieved in public (and don't feel comfortable sharing with non-admins). --SHB2000 (t | c | m) 22:18, 12 July 2024 (UTC)Reply

If everyone here is okay with 3, shall we opt for that then? --SHB2000 (t | c | m) 09:48, 17 July 2024 (UTC)Reply

Yeah, I'd say since no-one is really objecting, just wait 24 hours and then make the change. Ikan Kekek (talk) 17:36, 17 July 2024 (UTC)Reply

Sure: I'll file the Phabricator report by the end of tomorrow (since we can't make the changes ourselves). SHB2000 (t | c | m) 22:33, 17 July 2024 (UTC)Reply

I kinda forgot about this, but filed at phab:T371186. --SHB2000 (t | c | m) 03:29, 28 July 2024 (UTC)Reply

...and it's been marked as resolved now. I'll go ahead and change it. --SHB2000 (t | c | m) 06:45, 5 August 2024 (UTC)Reply

A user could make three userpage edits to get autoconfirmed. 82.212.77.242 19:19, 17 January 2025 (UTC)Reply

Yes. So? –LPfi (talk) 09:28, 18 January 2025 (UTC)Reply

If I am not mistaken, this is a RichardHornsby sock. SHB (t | c | m) 11:03, 18 January 2025 (UTC)Reply

Swept in from the pub

The title, basically. The need for any non-autoconfirmed user to edit a module is next-to-zero, but the impacts of a non-autoconfirmed user breaking a module is far too high and often leads to a domino effect of several pages broken. Just earlier today, all of our template documentation pages were broken due to a single instance of vandalism. While we can utilise page protections, it isn't an effective long-term solution; there's only so much we can do compared to not giving anonymous users + new accounts the ability to edit modules at all. Very little is lost and much is to be gained. //shb (t | c | m) 23:49, 3 February 2025 (UTC)Reply

I suppose to give a similar analogy, it's very much like how anyone who isn't an interface admin cannot edit .css/.js pages, or how non-autoconfirmed users cannot create userpages for other users on enwiki. Somewhat along the lines where the system restricts the ability to edit Module pages for autoconfirmed users only. //shb (t | c | m) 23:58, 3 February 2025 (UTC)Reply

The problem is that we don't have many users confident in editing the module code – we often want external help. I much prefer an expert editing code instead of asking me to insert it. Also, autoconfirmed is a very low level of protection for code that should be edited by experts only. With abuse filters it is possible to take into account some aspects of experience from other projects, which I think you cannot with page protection. Should we just add an abuse filter to protect modules? Some of our non-admin regulars often do this kind of work. Do we need less seasoned users to edit the modules? –LPfi (talk) 07:25, 4 February 2025 (UTC)Reply

Any bureaucrat can manually flag a user with +confirmed if needed. Leaderboard (talk) 07:49, 4 February 2025 (UTC)Reply

Yes, but bureaucrats are not necessarily available, and even if they are, the editor may not know how to ask for the action (or even that they are expected to ask for it). Regardless, I think (auto)confirmed is too low a requirement. –LPfi (talk) 07:54, 4 February 2025 (UTC)Reply

@LPfi: Maybe template editor? Template editors roles can be assigned by any sysop at any time without a nomination – if we want external help we could easily assign that role. --shb (t | c | m) 11:28, 4 February 2025 (UTC)Reply

My main concern with leaving the status quo and relying on page protections is that new modules are created not too uncommonly and it's very easy to forget to add page protection – and as we saw earlier with Special:Diff/5015601 – one edit by an IP that broke all of our documentation templates. I wanted autoconfirmed to be the default and then further protecting the very high-risk modules (that aren't .css or .js pages) to template editor, but I suppose if we make the minimum template editor, then it could easily be given out by a sysop on request. //shb (t | c | m) 11:33, 4 February 2025 (UTC)Reply

My suggestion was to add an abuse filter instead. It could be public, if we want public criteria and not more complicated rules often found in the filters. Global edit count can be used, and e.g. 5,000 would be much more than autoconfirmed, but probably satisfied for anybody whom we'd want to edit modules. The filters can be set per namespace, so such a restriction for modules is possible.

Template editor would be logical, and any admin being able to assign it lessens the problem with users from sister project, but there is still the frustrating feeling when you see a problem, do some research and experimenting and then, when you think that you have solved the problem, the system says that you don't have the rights. If asking for the permissions isn't a common solution across projects, the user may never think about it, and there is no trace of the actions that would cause an admin to assign the right and tell the user about it.

–LPfi (talk) 14:02, 4 February 2025 (UTC)Reply

A few hundred edits is usually plenty, especially if you can also check for account age (I'd suggest a few months). You don't want to unnecessarily exclude MediaWiki devs, whose contributions don't get counted as "edits". WhatamIdoing (talk) 17:25, 4 February 2025 (UTC)Reply

I believe asking for perms is quite common place across bigger wikis (where most of our technically skilled people come from), so it wouldn't be entirely out of the ordinary. My issue with an abuse filter is that it wouldn't give a whole lot of room to exceptions as opposed to a blanket default protection. //shb (t | c | m) 22:51, 4 February 2025 (UTC)Reply

In practice, asking for permissions means the site stays broken longer. We only have three buros here. Two of you are in the same part of the world, and the third isn't active most days.

• You and Ikan usually stop editing for the day around 12:00 UTC. TT's off wiki.
• The site breaks at 12:15 UTC.
• A volunteer dev shows up to fix it at 12:30 UTC.
• The volunteer dev asks for the user right at 12:45 UTC, but nobody who can grant the perm is around.
• The site stays broken until you or Ikan wake up in the morning.

WhatamIdoing (talk) 18:46, 5 February 2025 (UTC)Reply

Do you figure we need another bureaucrat? Ikan Kekek (talk) 19:05, 5 February 2025 (UTC)Reply

If we are going to make timely technical repairs conditional on having a bureaucrat around, then we probably need several more bureaucrats, with an emphasis on people who are usually online in the hours after the deployment train runs on Wednesdays (evening/night in Europe, afternoon/evening in the Americas). WhatamIdoing (talk) 19:48, 5 February 2025 (UTC)Reply

Solution is much simpler, allow sysops to also grant the confirmed right manually (I also say this after an awkward waiting period for a case we had on enwikibooks last year). Saves a whole heap of time as we generally have sysops active for most hours of the day (except between 23:00–03:00 UTC). //shb (t | c | m) 21:29, 5 February 2025 (UTC)Reply

Which means semi-protection (your original proposal) instead of template editor (your later proposal).

I thought that admins were already able to grant confirmed. WhatamIdoing (talk) 19:15, 6 February 2025 (UTC)Reply

Well I simply mentioned that due to you mentioning bureaucrats being needed to be involved – I still prefer template editor which can be assigned by any sysop, but if autoconfirmed is decided on as the bar, I'm also up for allowing sysops to grant it (which we don't, oddly enough). //shb (t | c | m) 22:31, 6 February 2025 (UTC)Reply

I thought TE required a buro. WhatamIdoing (talk) 22:20, 7 February 2025 (UTC)Reply

I believe sysops can grant autopatroller (if the user in question doesn't have GR), patroller, template editor and IPBE. Buros can assign that plus confirmed, sysop, int admin, bot, account creator and buro itself. //shb (t | c | m) 11:05, 8 February 2025 (UTC)Reply

Could a regular admin check whether they can assign "confirmed" and "template editor"? WhatamIdoing (talk) 18:22, 8 February 2025 (UTC)Reply

Would be good for a regular admin to check, but for the record, I very well remember not being able to assign confirmed when I wasn't a bureaucrat and I have assigned template editor to a few users before. //shb (t | c | m) 21:58, 9 February 2025 (UTC)Reply

The groups I can change are:

• IP block exempt
• autopatroller
• patroller
• template editor

I cannot change confirmed user. I checked what groups I can add to myself, removing groups can be different. I am an admin.

–LPfi (talk) 06:10, 10 February 2025 (UTC)Reply

Sweet, it does line up with what Special:ListGroupRights#sysop has to say (and it is expected that you cannot change confirmed user because that's under Special:ListGroupRights#bureaucrat). Cheers LPfi :). //shb (t | c | m) 08:02, 10 February 2025 (UTC)Reply

Have started a proposal at Wikivoyage talk:Confirmed users. //shb (t | c | m) 05:25, 10 February 2025 (UTC)Reply

Now that sysops can also grant confirmed at any point, what do we think about this proposal now? //shb (t | c | m) 06:05, 25 February 2025 (UTC)Reply

I think that restricting modules to auto/confirmed users is a good idea. Anyone who doesn't have the right, but needs it, should be able to get it quickly now. WhatamIdoing (talk) 19:14, 25 February 2025 (UTC)Reply

If there aren't any objections, I'll open a phabricator task tomorrow. //shb (t | c | m) 07:12, 3 March 2025 (UTC)Reply

A tad late, but see phab:T388301. //shb (t | c | m) 11:15, 8 March 2025 (UTC)Reply

Thanks for that. DreamRimmer has already claimed the task and submitted the code. This could happen as early as next week. WhatamIdoing (talk) 19:58, 8 March 2025 (UTC)Reply

Now marked as resolved. //shb (t | c | m) 22:12, 10 March 2025 (UTC)Reply