Subsequent edits by @Thryduulf while I was filing this seem to have resolved the immediate problem on that page, but the underlying problem remains.

Are the documentation updates needed to capture the previous behavior for older versions of MediaWiki?

Can we get a comment by someone on the MediaWiki-Documentation team? When this is resolved, it seems to me some mw pages will need updates. Some are linked in the OP.

In T432190#12175812, @Etonkovidova wrote:

I keep this task open for now, waiting for your feedback.

Thanks very much for Andrybak's detailed report.

Adding myself, and @Andrybak .

The problem is that an editor has to spot it and know what to do so it's not a realistic way to fix most instances of this bug.,

Growth team, do you already have all the data you need on this? For example, see this thread at mw:Talk:Growth for another case just listed. This one may be useful as it has an interesting wrinkle: the mentor receiving questions at en-wiki is site-banned there.

@DMburugu, just wanted to give you an update that I won't be able to complete this right away. I was unfamiliar with Beta, but successfully created an account there. However, after copying over my en-wiki user page to my beta user page and saving it, I was given a site-wide block for having an external link on the page. I assume that can be dealt with in due course (after I figure out where to ask).

Nothing new to add that you don't already know, just a kind of anecdotal 'user impact statement' to add to Jonesey's comment:

With exposed class names, editors interested can setup colors and even icons with custom CSS and JS themselves.

That's how infoboxes work; see Template:Infobox. I think you would have a steep hill to climb to do it another way. That said, numerous templates have been converted to Lua for various reasons, and you could raise it at Template talk:Infobox and maybe you would get some traction. (Otoh, it would be a pretty major change, as it has 3.4M transclusions.) Also, template params are very easily parseable, either within or outside Wikipedia.

I don't think the renamed task title (and your changes to the task description) reflect what's requested by volunteers from different wikis: We want a simple way to remove an account from mentoring without assigning them to another mentor.

Thanks for adding the criteria. Regarding this one:

That user appears to be a newly registered cross-project abuser. Can someone lock/block him from Phab? Thanks.

Investmentbenefit closed this task as Declined.

With the closure of T430252, two issues:

The deployment table lists 15 entries, but Wikidata lists 41. from what you were saying it sounds like the difference is due to the difference between the definitions of deployed and active, and relating those terms to wikis where new users are assigned mentors and where they are not.

This Cirrus query returns User Talk pages with Mentee questions posed in June 2026 prior to June 21 and unanswered as of now (meaning at least 3 days old as of right now. (It does not say how many unanswered queries there might be, nor does it necessarily return all such pages; still working on that.) But it could be a starting point to discover relevant pages to inform testing.

Is the situation of this user marked 'away' in 2025 by @Pppery, and who continues to receive mentee questions also covered by this ticket? Or do we need to create a related task, "Mentors still having mentees after having been marked away by a third party"?

I don't understand. The main issue for me, I think, is what you meant by "re-enter mentorship"—what does that mean? Wouldn't it simply mean responding to some user's question? And if that is what it means, they they are available, because they responded, so there seems to be a self-contradiction, and I don't really follow. Or does "re-entry" (I would probably say 'resumption of...' or 'resume...' membership) mean something else?

@Polygnotus had run some informal tests on an older machine that did not suffer excessive slowness, iirc, and may be able to provide those stats, or something similar if they feel like commenting.

Adding some subscribers from T424820 – 'Unexplainable .* behavior in intitle regex search' who might be interested in this: @Anomie @Certes @Novem_Linguae @Ponor @EBernhardson.

In T423809#11837449, @Robertsky wrote:

. . . I think updating https://en.wikipedia.org/wiki/Wikipedia:Moving_a_page for when editors encountering a similar issue to file an admin request at RM/TR to facilitate the move might be better.

In T321509#11882195, @KStoller-WMF wrote:

. . .
This task aims to reduce this ongoing manual oversight by automatically removing mentors who are inactive. It is important to note that this type of automation can address inactivity, but it cannot reliably identify or remove mentors who are ineffective, as that would be much harder (and likely problematic) to attempt to address programmatically.

In T321509#8367133, @Tkarcher wrote:

3. Add a column in Special:ManageMentors indicating whether this mentor is currently flagged as absent or not.

In T424586#11873442, @Hearvox wrote:

Ideally, we'd want to machine-harvest RSP wikitext (or JSON) that we could convert into a data structure ...

Iiuc, the current Infobox source reliability template, if modified per @Supergrey1's suggested enhancement, would be adequate for the parsing tools, and it doesn't significantly complicate the existing template. The upgraded template would be far simpler than many Infoboxes currently in common use (e.g., Template:Infobox officeholder @273,000 pages).

@Supergrey1 added this comment at WT:RSP#Facilitating parsing for partners about using Template:Infobox source reliability for this, and that sounds like a good solution to me. @Audiodude do you see any problems with this approach with respect to the expansion procedure?

Oops, sorry; re-add subscribers @WhatamIdoing @Supergrey1 @Jenny8lee @WebRunner95 @Audiodude @SuperHamster @Mathglot

Inspired by @Anomie's WP:VPT#Cirrus search query.

In T414760#11837226, @WhatamIdoing wrote:

I believe these bits of the design have been settled:

Please note related Feature request T424586, "Facilitate parsing of RSP source subpages for partners". (As a feature request, it is not listed as a subordinate bug task, and does not block this task.)

Hit on an easier approach than the xxxxx-2 renaming being contemplated for renaming the sandboxed templates currently being used in the restructuring runs. Since the legacy (table row-supporting) templates are all in Wikipedia space, all we have to do is move the sandbox to Template space under the
of the commonly used redirect name (modulo user friendly embedded space and letter case.

Maybe we could have a new categorized tag akin to a CSD tag but targeted at moves (or other operations); e.g., {{db-m1 |1=FromPage |2=ToPage|3=ByUser }} where 1 defaults to page it is on, and 3 to {{subst:REVISIONUSER}}. Could get picked up by bot, or manually if someone wanted to.

I do not think of YT as a source; it is a self-publishing platform. There is no way to have an RSP page about YT per se, anymore than there is for Amazon publish-on-demand, or for that matter, Simon & Schuster or Knopf. If they publish a reliable, peer-reviewed expert, then that it is one thing, and if they publish conspiracy dreck, then it is something else.

The page currently has 23,941 watchers. Very likely many are long-inactive (or blocked). I wonder if it is worth raising this at WP:VPT, to see if writing a bot to prune old, inactive users and indeffed/banned ones would alleviate the problem? Alternatively, what about having an alternative Move-page process that might be scheduled as a batch process to run at low-peak time with a much higher txn time limit, or something like that?

First of all, thank you for resolving this.

Thought I'd try it again, and attempted a round-robin move which failed on the first step, which was moving the new redirect out of the way. The failed attempt was:

Easier: just enclose it in a <div class="rsp-debug-N"> (the 'N' is for uniqueness, if you want separate control over different groups of debug info; drop if not needed) and turn it off in styles.css when you are done. They can then be physically removed at one's leisure all at once by a single edit to styles.css. (or left there and restored as needed for downline debugging)

Good idea; makes verification during a transition period much easier. The whole copied table row (section header included) should be within the scope of a div with a class named on it (e.g., rsp-row-copy), and mentioned in styles.css as display:inline-block (or nothing). Then, when we think it is verified, we can just set display:none in styles.css, and they will disappear in all 500 source subpages. Actually removing the wikicode can then take place at our leisure.

It's a manual process post conversion, but yes, grouping as per CNET was in the air. In the end, it can be up to consensus what people thinks works best in each case. But I would default to "together", as it is easy to break them up later. (Probably just as easy to merge them, so little risk, no matter what we do.)

The more experience a user has, the more they should shift away from using the Impact module and toward the Toolforge Edit counter tool, which contains all of the Impact stats (except for 'streak', which is probably the least valuable of them, especially when one is no longer a newbie).

I got an error trying title_asc, and the message suggested title_natural_asc, which worked. Can someone explain the reason for the label change? What's wrong with "title_asc", and can that be aliased to the new value, as it is a guessable label while the actual one is not? (Ditto title_natural_desc.) Thanks.

Thanks for this! Are the two ids above the only ones that were added? What about the Suggested Edits module?

I would modify the story from:

Adding @EEng .

I created redirect Wikipedia:Reliable sources/Perennial sources/9 ⟶ */X, so no need to special code that part.

I will create a redirect from ...9 to ...X so it picks it up. That should be sufficient, as long as we skip the Z.* rows, place there strictly as a copy-paste model. If I place <noinclude>...</noinclude> around those rows, would that work for you? I.e., skip converting anything within noinclude tags. If not, we'll find another solution.