Support overall - would be useful.

In T226797#8013090, @Izno wrote:

In T226797#8013018, @Legoktm wrote:

Can we start sketching out what SUL3 would look like? In my head I currently have an idea that the login link will send you to login.wikimedia.org with ?uselang and original URL preserved, then you log in, including 2FA, it redirects you back to where you came from with an OAuth style handshake. Then on another wiki family, you have to click login, but once you hit login.wikimedia.org it immediately redirects you back and you're now logged in. I'm not sure if there's a way to transparently do the wiki logins without redirecting back and forth...

Take into consideration how this interacts with CheckUser.

In T310947#8026173, @Huji wrote:

One person on the listserv said they had a harder time finding checks done by a user; this is now easily doable (just with more clicks), and that user can also create a similar link using a Gadget or user script. It is just unacceptable that we change software interface broadly in ways that mostly doesn't work or doesn't apply, just for a narrow use case raised by a single user.

Hey, sorry to be the grouch, but reposting what I posted to the CU list here in case there's something that can be done:

It may be worth baring in mind that trying to find loopholes in this way may indicate that the spirit of the resolution may not be being followed.

In T275294#6847014, @Legoktm wrote:

In T275294#6846224, @TonyBallioni wrote:

My general suggestion is not to only look at FOSS, but to look at what would fit our needs best. That could be something that’s open source, but it might be something else, and I don’t think we should limit ourselves.

Just to be clear, this is a non-starter. We don't deploy non-free software. This is covered in https://foundation.wikimedia.org/wiki/Resolution:Wikimedia_Foundation_Guiding_Principles#Freedom_and_open_source and not really worth rehashing IMO.

But that doesn't preclude us from paying for/sponsoring feature development in free software so it fits our needs. Given how valuable OTRS is to the movement, it seems like a worthy investment.

My general suggestion is not to only look at FOSS, but to look at what would fit our needs best. That could be something that’s open source, but it might be something else, and I don’t think we should limit ourselves.

As L235 mentioned, OTRS is not a user-friendly software, is difficult to navigate, and next to impossible to use at all on mobile. I would strongly support moving to something other than OTRS.

Chrome 87.0.4280.77 for iOS.

In T202989#6550271, @Effeietsanders wrote:

Agreed. I also want to add the perspective that it's not just English Wikipedia with plenty of interface admins that we're dealing with here. We're also looking at a vast majority of wiki's where the group of interface admins will be tiny, if even existent.

Thanks for the great work guys. Just want to confirm that this will not be deployed to loginwiki.

Out of curiosity, has there been any movement on this? It is a somewhat significant bug both from a transparency standpoint and from an anti-abuse standpoint.

Great idea. Would be very helpful.

Agreed. If we’re clicking the block button that means we want it blocked with the reason we input. If they’re already blocked it should reblock.

In T247540#6080121, @Reedy wrote:

Increase query speed by having less rows to potentailly look at? Could this be done with better/different indexes, or storing rc_bot into cu_changes too as an extra filtering criteria?

Oppose this change. I’ve never directly checked a bot but there absolutely have been circumstances where CU data from a bot has been extremely helpful when checking a range or IP.

@Urbanecm that hasn't worked since at least August 2019 when I tested it on test wiki, but I also don't think it is something that should be "fixed".

In T218626#5729804, @Niharika wrote:

In T218626#5729595, @DonTrung wrote:

I don't get why the Wikimedia Foundation doesn't just implement this by default, what would we truly lose if partial blocks were implemented? Admins aren’t forced to use them when they don't want to, “giving the community a choice” just means that they (we) could prevent something that's a net benefit to it.

In fact, policies are written around the technical capabilities and limitations of the MediaWiki software, not vice versa. There is literally not a single reason why a piece of software that doesn't limit anything possible today but only expand it should not just be enabled by default, if partial blocks had the potential to damage the workflow of the community I could understand that it would require prior discussion, but this is unnecessary bureaucracy.

We are planning to do that. We're aiming to give the communities one last heads-up (see T240300) before deploying this everywhere.

Just an optics comment: I wouldn't have en.wiki as "up next". A poll hasn't been taken, and it is likely to be substantially more controversial there than other projects. The wording makes it look like it's already been decided. I know that's not the intent, but better wording could be used :)

Mentioned this in the task above, but finding some way to prevent users from getting a rename, whether it be at the request level or at the level where someone renames them really is needed. This is becoming an increasingly larger issue as the Wikimedia movement is becoming more diverse and we don't have a rename team that has enough representation from all projects that requests which should not be approved are slipping through and the only way to raise an issue currently is via the mailing list.

Someone just pointed out to me that this likely is similar to T101615, so may be able to be merged into that.

I agree with @Ajraddatz, this is not nearly as large a concern as the tech people make this out to be and it would likely cause some of the most active CUs to quit if 2FA for using Special:CheckUser were required. I’m not joking when I say this would be a disaster for some large wikis.

This seems like it would be pretty useful.

Hmm. Seems to be an issue with blank pages. I was checking to see if I could edit it for Amory, and it displayed the following message. URL is:https://phabricator.wikimedia.org/T206642

Just as a note since there’s been some confusion: this doesn’t appear to be affecting en.wp

Just noting that one of the larger issues with this is the attribution error for licensing purposes. In some cases history merges are needed to fix it, which is a pain.

@Framawiki: @revi was responding to my comment above about making sure there was confirmation for the intent to vanish using this method. I think a dedicated page or some sort of confirmation to the decision to vanish would be important, otherwise I'm pretty sure we will be getting emails/talk page posts about accidental vanishings.

Thanks @Trijnstel for adding my comment from the list. Yes. I think requiring two clicks to confirm they actually want to vanish is important. Even if only an edge case, we would get people who claimed to misclick and submit. This would eliminate that problem.

In terms of global account creation this is a limited version of the account creator user group and has less functionality in that regard as it can’t globally override the blacklist or anti-spoof measures.

@Andrew_Davidson : this is already the standard practice at PERM for confirmed status. You just set an expiry time (usually a week) in Special:User rights management when granting the flag. Autoconfirmed attaches within the time frame once they've made 10 edits, so the right is superfluous.

@mobrovac: the reason there is only one stuck currently is likely because we have stopped doing renames until this is fixed because having users locked out of their account isn't ideal.

I've emailed @Tnegrin, @DannyH, and @kaldari asking them to comment on this.

@Aklapper: I emailed Danny Horn about it in the final week of the RfC to make sure he was aware that the close was likely to be positive. He responded saying if it passed the 3 May date would be fine. Toby Negrin, Ryan Kaldari, and Marshall Miller from the foundation were copied on his response.

@Urbanecm: given that this is a request from a 200 person plus RfC to restore one of the most significant changes to the flagship project, within a week and a half, and I’ve been told by a WMF staffer that 3 May is an acceptable date, yes, it is that simple.

There are currently complaints on the English Wikipedia that mentions/pings are also not sending emails, not just not giving on-site notifications.

@Chris_troutman: is this still an issue? Page curation should create log entries not on a user subpage but as logs. You can check "deletion tag log" to see the ones you have placed.

In T50552#3648453, @Liuxinyu970226 wrote:

@JEumerus

• A notification on the talk page of the user who made the article

Not always, nominating deletions of Wikidata items do not require such notify.

---

Also, for several months I'm wondering why Collaboration team is "maintaining" PageTriage related tasks, and are members of that really doing maintains? If there's benefit that this work must be continued, how about moving those tasks to another team?

I'm normally on team "give the WMF a bunch of room to improve stuff". This is really confusing though. I was recently at https://en.wikipedia.org/wiki/Maxwell_House_Haggadah and received a question as to whether I would expect to find this as a search result for "schools and prisons" (or it might have been prisons and schools).

In T175225#3609252, @jmatazzoni wrote:

Thanks @TonyBallioni. Sounds good. If we're adding a new filter, I suggest the following: Since the filters discussed above work identically to the "experience-level" filters defined for the New Filters for Edit Review (moving out of beta on RC page soon), we should conform their names with the New Filters names, so we have a consistent filtering experience. (Otherwise we'd have two sets of filters that do the same things but are named differently). So:

• The existing "New users" filter becomes "Newcomers"
• And the new filter we create will be named "Learners (autoconfirmed)"

I added the parenthetical "autoconfirmed" as a way to define this while staying consistent, as I say. You can read about the experience level filters in the New Filters documentation.

If that sounds good, I'll write it up as a spec in the Description above.

For step 2, the original URL this was encountered on was: https://en.wikipedia.org/w/index.php?title=Church_of_England&oldid=800337495

After reading the above, I concur with @Rentier . If ACTRIAL is made permanent we can deal with removing the old feature then. Adding a new filter will be useful for ACTRIAL both during and after regardless of the outcome.

Question regarding this: it has been marked as blocked on development. Does this mean it is not moving forward? I am asking because of the potential impact it might have on gathering statistics during ACTRIAL if it is implemented in the middle of the trial.

Just to note another example that I found today in case it is helpful: https://en.wikipedia.org/wiki/Action_of_22_August_1917 was a page referenced using {{sfn}}/Harvard style references that also showed up as no citations in the feed.

Putting this in here, but @MrX has requested that "please make it easy to use, with a slider or at least a calendar widget. It shouldn't require keyboard input and or multiple mouse actions." as a suggestion regarding this feature.

Thanks MusikAnimal, for getting these statistics. While I think a larger sample would be great too, it does give us an idea of what the survival rate is after all the pages have gone through NPP, which is helpful.

@kaldari the request was mainly put that way for a manageable timeframe after the creation of an article and past when the new user backlog tends to fall off.

I also created this as Task T157067 without seeing this had already been created. Feel free to merge the two.

Just as an FYI, its getting more reports are coming in on the page curation talk page. I'm sure its the same bug, but just putting it here as an FYI: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3APage_Curation&type=revision&diff=761417151&oldid=761182075