My apologies, the wiki is back online.

In T111847#1617700, @Legoktm wrote:

Is this T93214: Back-fill log entries from GlobalRenameQueue renames that promoted to a global account?

The behavior of this bug is quite odd. I noticed this a week or so ago when I was working on my stats tool but hadn't got around to properly reporting it.

Sigyn is now present again on #wikimedia.
For future reference, please direct similar queries to #wikimedia-ops as phab is not a good way to reach us.

The matter was originally discussed on T34048 it seems. The original requested is already cc'ed on this bug.

I likewise have to express serious doubts about the propriety and wisdom of granting such sensitive userrights, especially on a wiki with such little supervision. While of course well meaning, I feel this request raises some of the problems previously encountered on hiwiki and on other wikis.

Definitively agree on the hold feature request.

I wonder if this is a case of T89051

Administrator is not a prized title held by users who are above others, it is a permission granted to those who need it and whom are held in high trust by the community. Editing mediawiki namespace is by far the most sensitive and trust-requiring part of the administrative toolset as the potential for abuse is immense. Is there a specific reason why cawikibooks thinks a particular user is trustworthy enough to do so but not competent enough to be trusted with the other parts of the administrative toolset?

Courcelles, would you be able to test whether the problem is still occurring?

Users shouldn't be blocked without an edit summary honestly, so the workaround (reblocking with a non suppressed rational) should actually be the best practice. What I think needs to be fixed is disabling the ability for oversighters to suppress the currently applied block so that they have no choice but to reblock with a new rationale before suppressing the block log entry.

I've re-opened the task, as I am told the mailing list is still in active use. We need to figure out if the problem still exists tho.

I am no longer an enwiki oversighter, and no longer have access to the list, but I believe the list is still in active use.

That would make a lot of sense imo.

The settings on that page, as detailed in this bug, only control part of the date. The "D, M j" part (as in, Mon, Nov 24) are hardcoded and the customizable part gets appended to those. In effect, they only regulate time rather than date.