In T380824#10363217, @Kgraessle wrote:

My suspicion is that the jobs are attempting to fire at the same time or a competing job has already rolled back the page thus changing the latest version before the job is complete (resulting in an edit conflict).

For example:
Editor 1 makes an edit, then this edit is queued for deletion
Editor 2 makes an edit to the same page before editor 1's rollback is complete
Editor 2's edit is rolled back before editor 1's rollback is complete
Editor 1's edit is not rolled back (edit conflict/already rolled)

Katy and I had a quick chat about this earlier and made the following notes/conclusions:

• Nuke tends to delete pages on the order of a few minutes. So in thinking about synchronous vs asynchronous feedback, we think synchronous (e.g. a loading bar or visual list of pages being deleted) makes more sense than a notification some time later that the deletions succeeded or failed.

Send a talk page message when a page has failed to delete (to the deleter) that way they have some visibility into what happened. (Similar to AutoModerator).

In T376379#10330985, @Samwalton9-WMF wrote:

In T376379#10330373, @Samwalton9-WMF wrote:

In T376379#10329561, @Chlod wrote:

n.b. The no-JavaScript experience for this kind of sucks. The user will get a multiline text box, and will have to enter namespace IDs per line. It's possible to accept namespace names (e.g. "Talk", "Project", "Help") here, but it will add some complexity to processing the list of requested namespaces since we have to process that on our own. I have that patchset ready, in case it's something we'd like to retain support for.

Accepting namespace names sounds like a localisation nightmare, so numbers seems the better approach. I've asked internally if there's any way for us to pull data on how many users even use Nuke with JS disabled.

With thanks to @mpopov on Slack, the following links should be helpful:

• https://www.mediawiki.org/wiki/No-JavaScript_notes#Metrics
• T240697: Measure % of edits coming from users without JS

I can test it on enwiki early next week.

In T364225#10362719, @Scardenasmolinar wrote:

@Chlod, we have QA'ed your patch on test wiki and we have noticed that the user actions do not show up whenever we mass delete pages where we leave the user/IP field blank. Here is a screenshot for reference.

I think the Link Events table, perhaps joined with Collections/Organisations so that the link is clearer?

This seems to be working, so I'm marking this as resolved. Will file followup tasks for increasing the time limit.

Looking at the page it seems like Automoderator is complaining about not being able to revert an edit that Automoderator already reverted - https://tr.wikipedia.org/w/index.php?title=Pusula&action=history

In T379624#10354950, @OTichonova wrote:

Hi @Samwalton9-WMF, after speaking with Bárbara. The message could show up in a warning message above the list after someone has clicked on 'List pages' with an additional 'Visit all pages' link to see all the pages.

@OTichonova This might be a fairly simple one but would appreciate your thoughts on how to tackle it. In the new page flow I guess we could put a small information box between the filter box and the list of pages?

We should wait until $wgNukeMaxAge has been increased before prioritising this - it's not so useful when there's only a 30-day window to filter within.

This has been happening for days at varying rates after T377229.

In T376597#10347117, @Rooiratel wrote:

@Kgraessle thank you so much. I have enabled and configured the bot on our wiki.

How many have an associated talk page?

With thanks to Jennifer Wang, we got a ballpark figure of 2/3rds for this.

In T370795#10345511, @Kgraessle wrote:

@Bonaditya This feature is ready if you would like to enable it.

See configuration here.

For future reference, Discord discussion started here, in the General Technical Discussion thread.

@OTichonova putting this in the backlog for us to explore. Could it make sense to use a dialog here, or is it OK to just put an Apply button inside this dropdown?

In T163429#10299148, @Samwalton9-WMF wrote:

In T163429#3569162, @TheDJ wrote:

@SBisson wikipage.content is however intended for content of wiki pages, not special pages.... I guess that could work, but... not really what the original intent of that hook was (You might be triggering other scripts that will now encounter content that they are not expecting).

This sounds like something that should be discussed by Front-end-Standards-Group or something.

My team is looking at making some improvements to Recent Changes over the coming months, so I wanted to check if it still seems to be the case that the FESG should discuss this before any attempt is made to implement the feature described above?

In T377264#10285107, @YLiou_WMF wrote:

@Samwalton9-WMF: yes, absolutely can share this early next week!

Lift Wing API for this - https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_articletopic_outlink_prediction

I guess we could be doing the same for pages not listed due to the page limit too.

This layout makes it a little more obvious how we can achieve T376378 - we allow access to Special:Nuke but don't display the Continue button unless you're an admin.

In T378486#10330995, @Samwalton9-WMF wrote:

In T378486#10330799, @Chlod wrote:

Development wise, yeah, that would take a little more effort but it shouldn't be much more unreasonably difficult. For administrators though, it'd be another page on the flow (4 total: prompt, prompt with list, list with additional pages, and result), which might be an annoyance for some.

I think it's the same number of clicks though, because the confirmation page (list with additional pages) could replace the browser dialog box popup that happens at the moment.

Should I try out implementing that two-page design to check out what it looks like?

Yes, but not yet, we're still figuring out what the flow should be, so I wouldn't want you to waste your time!

If we moved to a one-page system with a 'Continue' button to go ahead with actually deleting, this would be easier to implement, I think, because we can just not show the Continue button (or grey it out or somesuch).

@Scardenasmolinar Were you able to learn anything about what to do with the hook?