Meta:Babel/Archives/2019-06

From Meta, a Wikimedia project coordination wiki

Is it time to revise our Autoconfirm requirements

The last round of discussion put Autoconfirm requirements at 4/5. I remember seeing a statement that if it doesn't work / there are people slipping through we can try to up to 4/10. With this and a copuple more, I am seeing more and more people able to gain autoconfirm using various manner. I will then propose we increase edit count to 10 to prevent such issues from happening. Thoughts?--Cohaf (talk) 09:33, 21 June 2019 (UTC)

It's only been 6 months, do you have some specific patterns of bad edits that this may solve you can share? — xaosflux Talk 11:46, 21 June 2019 (UTC)
@Xaosflux:This is another sample. --Cohaf (talk) 12:05, 21 June 2019 (UTC)
Actually, the vandal mentioned above did not even know the requirement is only 5 edits... Only after ten edits did they begin harassment on others' talk pages. For rapid reverts, I think we can introduce this filter from enWP. --94rain Talk 11:51, 21 June 2019 (UTC)
Meh. Meta is a secondary project that exists to support other projects. We should do our best to make it easier for people who work on the projects meta exists to serve to contribute here. 10 edits is remarkably easy to game and as 94rain hints at, they likely thought the requirement was 10 edits anyway so they were trying to game it... Upping the autoconfirmed requirement here would put an undo burden on legitimate contributors on the projects that meta exists because of. Dealing with a vandal or two in the process isn't a big deal. TonyBallioni (talk) 16:59, 21 June 2019 (UTC)
concur. One person getting through autoconfirmed is not a reason to change the base process.  — billinghurst sDrewth 10:21, 28 June 2019 (UTC)
+1 on billinghurst. (Even N persons is not enough. You need to consider all "new" users and whether a majority of them would be best served by the new rule.) Nemo 12:38, 28 June 2019 (UTC)
  • @Xaosflux, 94rain, Nemo bis, TonyBallioni, and Billinghurst: Sorry I had forgotten this. I am caught up various stuffs (IRL, onwiki). Sorry this had inadvertently spilled the BEANS to some people who don't know the limit and they now know and it's counterproductive in some sense. The filter is worth implementing IMO as it will help in many of the undo kind of vandals. As per Tony point about meta being a supportive project, yes, I fully agree. I was once here trying to tag an userpage for spam but was prevented as I was not autopatrolled, it's frustrating. I admit this is premature and lack of complete consideration. Thanks for all the feedbacks and with this I will withdraw this. --Cohaf (talk) 18:20, 28 June 2019 (UTC)
This section was archived on a request by: Vogone (talk) 22:16, 28 June 2019 (UTC)

Log in problems

Hi, sorry to clutter this page. I've returned to Meta to make input into the Wikijournal proposal, after many years' absence. How do I tick the box that says keep me logged in? It just won't let me. Tony (talk) 08:48, 19 June 2019 (UTC)

Works for me. Browser-related?  — billinghurst sDrewth 10:54, 19 June 2019 (UTC)
Me too. Clear the cache or use another CPU / browser? --Cohaf (talk) 14:00, 19 June 2019 (UTC)
If it's the issue TonyBallioni mentioned below, yes, I had for several times. Log in into 1 wiki is okay, but going across wikis the connection seems to be broken. --Cohaf (talk) 18:33, 19 June 2019 (UTC)
SUL has been having some issues recently. If what you're referring to is being logged in to en.wiki and not being logged in here or something like that, that's been going on for a few months and I know of at least one case where an en.wiki admin had to get logged out edits suppressed when they were coming over here. TonyBallioni (talk) 15:49, 19 June 2019 (UTC)
With regard to sequential login where the SUL is not recognised between wikis (and different from the tick box), then try a different browser and see if you can replicate, look to any add-ons or blockers that you have set. I have previously had a problem (4-5 years ago) where my SUL login didn't propagate and it was browser profile-related and cookie-related, and clearing cookies and resetting cookies alone did not resolve it, nor did uninstalls nor upgrades. I morphed the profile over with a tool to retain most of the important settings though had to live with resetting others. I know it was profile related as it was only happening on my main computer.  — billinghurst sDrewth 21:38, 19 June 2019 (UTC)
Thanks for responses. I use Safari for Mac, and yes, I'm longer-term logged into en.WP. I'd really like not to switch to Chrome, even though my tech friends urge me to. I'll need to wait for a while so I'm no longer logged in, and then try Chrome for Meta access. Tony (talk) 05:01, 20 June 2019 (UTC)
I am using Chrome and the propagation issue billinghurst mentioned happens to me just yesterday. However, I am on a Windows so maybe is worth trying to switch on Mac. --Cohaf (talk) 11:15, 20 June 2019 (UTC)
Chrome on my Mac, I have just discovered, does indeed allow you to tick the "keep me logged in" box. Why can't the WMF fix it for Safari??? Tony (talk) 13:02, 21 June 2019 (UTC)
Are you on the current (12.1.1) version of Safari? — xaosflux Talk 13:06, 21 June 2019 (UTC)
It's Version 12.1.1 (13607.2.6.1.2). Brion Vibber at the Facebook page is also interested in this issue. Tony (talk) 04:03, 28 June 2019 (UTC)
I've filed a task on phabricator to make sure we track this, since I didn't see a Safari-specific recent report in there. Not sure if this is related to known problems or if it's something fun and Safari-specific... --brion (talk) 04:43, 28 June 2019 (UTC)

I've also had (new) login problems for a few months now. Login often doesn't work across all domains and never works across browser sessions, although it does on other websites. I have not even tried reporting them because in this period at least two important things happened: 1) I enabled 2FA (which shouldn't have an effect on cookies, but who knows), 2) Firefox 67+ or whatever introduced some restrictions on cookies which may or may not work well with my settings (cookies disabled by default and whitelisted on a per-domain basis + uMatrix with cookies whitelisted for all Wikimedia domains from all Wikimedia domains). It would be a pain to make the bug reproducible for a bug report, in my experience with SUL bugs. Nemo 12:41, 28 June 2019 (UTC)