This has resulted in merge log entries at the destination showing "redirect=no" on the wrong link (T395075). For example, https://en.wikipedia.org/w/index.php?title=Special:Log&logid=169948608 should have "redirect=no" on the link to Draft:Percilla Bejano rather than the link to Percilla Bejano.

Thanks for fixing this, @daniel !

Well-done, @Ladsgroup and @bd808! Congratulations and thanks for all your great effort in making the Wikitech SUL dream come true! Now, it's time to celebrate the new SUL reality! Goodbye Wikitech account = Developer account and hello Wikitech account = SUL account!

See T387067 for the possible regression regarding null edits not being flagged as minor edits.

This has the side effect that "null edits" from moves and imports are no longer flagged as minor edits (e.g. https://en.wikipedia.org/w/index.php?title=Template:Roman_numeral&diff=prev&oldid=1277105738 and https://en.wikipedia.org/w/index.php?title=Stop_motion&diff=prev&oldid=1277071068), although those from protections still are (e.g. https://en.wikipedia.org/w/index.php?title=Siahkal_County&diff=prev&oldid=1277109023).

Fixed by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1099368.

It appears that Phase 2 did not actually happen on November 30 as planned. In particular, the Wikitech accounts with mismatching SUL usernames did not get automatically renamed.

In T379168#10299916, @Samwalton9-WMF wrote:

We noticed that we made this tag code tag-Nuke when it should have been tag-nuke. As part of this ticket we should update that too.

We could also create a script to run back and update the old tags, but there are relatively few so far so this may not be a high priority. I'll file a separate task.

And now Quarry is working again.

In T375988#10186586, @rook wrote:

Quarry is working again. Though I didn't have time to investigate what is happening so this may happen again. Opening T375997 to investigate the underlying issue.

Per the comments at https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1077048.

Instead, your Wikitech account will become "married" to your SUL account (along with other wiki accounts, so this is actually "polygamy"). Then, your SUL account would become a "stepparent" to any "children" of your Wikitech and LDAP accounts (i.e., Gerrit changes and Wikitech edits).

Should we re-enable account creation on Wikitech or not? Account creation was disabled in https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/952209 following T345226.

In T375330#10165867, @Soda wrote:

Don't we already highlight articles that are 60 minutes old?

I am not sure about the case of "last edited". It would mean that if a reviewer has already tagged an article but then they realized that another tag needs to be added, then they would have to wait 60 minutes before tagging again. What we could do instead is to add a "60-minute timer timestamp" column to the database that is initially set to 60 minutes after the timestamp of each article's last edit. Then, for pages that have been edited after the 60-minute timer expires, reviewers should then be allowed to restart the 60-minute timer if needed. If a page has been edited before the 60-minute timer expires, then the 60-minute timer will automatically restart itself.

@C1K98V Love, Sitara has been re-draftified by Bastun, and then moved to mainspace again by autopatrolled admin @Hey_man_im_josh. But it is still not marked as autopatrolled. Also, the behavior is inconsistent, as SLGT (another page moved to mainspace by Hey man im josh) was correctly marked as autopatrolled.

In T369126#10074666, @matmarex wrote:

The green dots are added by a gadget on English Wikipedia called "Display green collapsible arrows and green bullets for changed pages in your watchlist, page history and recent changes (unavailable with the improved Watchlist user interface)". Please report the issue there.

(Without the gadget, the unread changes are marked with bold text instead, which doesn't suffer from this issue.)

In T372354#10060512, @Aklapper wrote:

For users with multiple new messages who want to see each one of them.

I don't understand - why can you currently not see all your new messages?

Only "(less than 1 hour ago)" is shown with parentheses in the "Since" column. Other durations (e.g., 2 hours) are shown without parentheses.

If one is pessimistic, then the enwiki.analytics.db.svc.wikimedia.cloud replag will continue to increase for all eternity. This would mean that the replag would increase to 9,000 hours on August 13, 2025, if this task is still not completed by then. Otherwise, if one is optimistic, then the replag will eventually go back to zero.

This is not a regression, as there was never a time when articles converted into redirects were added to the PageTriage queue, as far as I could tell.

If this never gets fixed, then enwiki.analytics.db.svc.wikimedia.cloud (but not enwiki.web.db.svc.wikimedia.cloud) will be on replag for all eternity. Let's hope that it won't be on eternal replag.

But the enwiki replag is still 5 days.

The enwiki database is the last remaining database that is still on replag. The commonswiki and testcommonswiki databases are not replagged anymore.

In T370778#10007273, @Aklapper wrote:

No, it should not. (This ticket also lacks reasoning - please use the feature request template for requesting features. Thanks.)

Merging Wikitech accounts is not technically possible.

Per the note at the top of https://wikitech.wikimedia.org/wiki/SRE/LDAP/Renaming_users, we no longer rename LDAP accounts.

Per the note at the top of https://wikitech.wikimedia.org/wiki/SRE/LDAP/Renaming_users, we no longer rename LDAP accounts.

When I null edit https://en.wikipedia.org/wiki/Draft:Kourage_beatz_nsi, for example, the "There is already an article named Kourage beatz nsi in the mainspace." notice disappears, but then it reappears as soon as I revisit the page.

In T365374#9890676, @Liz wrote:

I'm not getting that message any more but some queries are just running endlessly and never finishing. I had one that ran for more than 3 hours before I finally cancelled it. Does this warrant a new case to be opened?

Bug appears to have been fixed.