Hello @KStoller-WMF @JFernandez-WMF @Trizek-WMF! Would you be able to take a look at the problem and the various solutions suggested in the past, and make a recommendation on how to address the issue (one that is apparently a painpoint for several wikis)? Thanks!

Page protection is not supposed to be permanent. It is important to keep it as a temporary option. Mentors who have constant issues due to patrolling should consider not being mentors (or, perhaps, reconsider how patrolling is performed).

I'm in favor of T244258: Homepage: Treat mentors with protected talk pages as unavailable, as it looks like the easiest path: it doesn't change permissions or interface, and it already provides a replacement for the mentor.

Regarding the other options:

• T264766: Allow mentor talk pages to be protected from non-mentees is tricky to make as Martin explained.
• T322763: Provide a separate talk page for mentors, for questions coming from their assigned newcomers will be tricky to implement and monitor, particularly when mentors are away. And mentors will be more likely to only use that extra talk page.
• T267027: Notify mentees that their mentor's talk page is protected is a nice message to provide, but taking a step backward, I see it as a potentially dead-end for newcomers who could freeze seeing an unexpected message (similar to what we see in the video description).

I'm in agreement, that T244258: Homepage: Treat mentors with protected talk pages as unavailable seems like a reasonable solution that doesn't introduce other potential abuse opportunities.

One downside is that it doesn't resolve the scenario where a mentee wants to follow-up about a previously asked question. Are there other downsides I'm overlooking?

In T368861#9950288, @KStoller-WMF wrote:

One downside is that it doesn't resolve the scenario where a mentee wants to follow-up about a previously asked question. Are there other downsides I'm overlooking?

There's a possibility of exhausting the set of mentors. Even though a wiki has on-paper 10 mentors, we might end up with only one answering all of the questions, which doesn't scale. There is also a question of what do we do when all mentors have their talk page protected (might be unlikely, but the mentorship module would need to do something in that case). We can turn mentorship off temporarily (would that be an okay-surprise for the mentee?), or we can leave their primary mentor there, accepting the subpar user experience in that edge case. Do you have any opinion here?

In T368861#9951940, @Urbanecm_WMF wrote:

There's a possibility of exhausting the set of mentors. Even though a wiki has on-paper 10 mentors, we might end up with only one answering all of the questions, which doesn't scale. There is also a question of what do we do when all mentors have their talk page protected (might be unlikely, but the mentorship module would need to do something in that case). We can turn mentorship off temporarily (would that be an okay-surprise for the mentee?), or we can leave their primary mentor there, accepting the subpar user experience in that edge case. Do you have any opinion here?

I think in that case we can leave their primary mentor listed. Solving T244258 fixes the more common issue, and I think it's OK that there are rare edge cases that aren't handled as gracefully.

@KStoller-WMF Sounds good then, thanks! Should we move to Triaged, or is this more of a Backlog topic now? I'm not sure how far the potential mentorship-themed sprint we previously discussed would be.

Let's move to Triaged for now. We will have a planning session to help determine which Mentorship tasks to prioritize before the mentorship-themed sprint and can move those tasks into Backlog or Up Next at that point.