Page MenuHomePhabricator

Homepage: Treat mentors with protected talk pages as unavailable
Open, Needs TriagePublic

Description

Behave similar to what an away mentor looks like, but with a message saying "mentor is unavailable" instead of "away".

Event Timeline

Change 570099 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/GrowthExperiments@master] Mentorship module: Show mentors with protected talk page as unavailable

https://gerrit.wikimedia.org/r/570099

Urbanecm removed a project: User-Urbanecm.
Urbanecm edited subscribers, added: Urbanecm_WMF; removed: Urbanecm.
Etonkovidova claimed this task.
Urbanecm_WMF removed Etonkovidova as the assignee of this task.
Urbanecm_WMF added a subscriber: Etonkovidova.

@Etonkovidova Reopening. To the best of my knowledge, this was never actually finished :-).

@Etonkovidova Reopening. To the best of my knowledge, this was never actually finished :-).

Yes, you're right: it's not finished in terms of having the away message. The current behavior for a mentor protected page - the mentorship module would be removed from a user's Homepage (somehow I thought that it was the solution for the case).

I moved the task to the same project that https://phabricator.wikimedia.org/T227876 (which is the parent task).

Change 570099 abandoned by Urbanecm:

[mediawiki/extensions/GrowthExperiments@master] Mentorship module: Show mentors with protected talk page as unavailable

Reason:

archive-level code, not worth keeping opened

https://gerrit.wikimedia.org/r/570099

Urbanecm_WMF raised the priority of this task from Low to Needs Triage.Oct 25 2022, 10:14 PM
Urbanecm_WMF moved this task from Inbox to Upcoming Work on the Growth-Team board.

Following up from the enwiki discussion...

@Urbanecm_WMF I assume this would be fairly similar logic to T318819 , so would this be a relatively easy task to complete? Or is the trigger (a talk page getting protected) not able to trigger a secondary action to mentor status?

One thing we might also want to consider is that mentors might not remember to set themselves as Available once their talk page is restored: should we consider automating that too?

Hi @KStoller-WMF,

Completing this would be relatively easy to do, as long as we're fine that:

  • the status is always "Unavailable" for mentors with a protected talk page (in other words, if mentors can't decide to be Active while having a protected talk page)
  • the status reverts back automatically once the protection expires/is removed

AFAICS, it looks like both of those things aren't a problem (and for the revert back to the previous status, even desired).

I'm, however, not sure if this task is a correct solution for the underlying problem. By resolving this task, we'd be effectively puting mentors with a protected talk page out of mentorship temporarily.

Maybe we should instead consider providing another way newcomers can contact such mentor? At least at English Wikipedias, users with a protected talk page tend to have an unprotected subpage for anonymous/new users. As an example, see User talk:AmandaNP and User talk:AmandaNP/IP.

If mentors have the ability to specify their secondary unprotected talk page, we can use it if available when asking a question, and resort to redirecting the mentor's question only if the secondary talk page is unavailable (not specified, not existing or *also* protected).

Allowing mentors to provide a secondary talk page would make this more complex, but I think it'd be a better solution, as it'd help us to have more active mentors.

What do you think Kirsten?

AFAICS, it looks like both of those things aren't a problem (and for the revert back to the previous status, even desired).

Agreed!

Allowing mentors to provide a secondary talk page would make this more complex, but I think it'd be a better solution, as it'd help us to have more active mentors.

I agree that we should aim to keep as many mentors active as possible... but I'm not convinced that this is an issue often enough to justify that level of complexity. It not only makes this task more work and the code more complex, but it would make the mentor side of settings more complex. But as always, I'm open to being persuaded otherwise by you or the community. :)

@Trizek-WMF Thoughts? Should we ask ambassadors and/or mentors about this?

A long time ago, back when mentoring first appeared, several mentors in ruwiki wanted a separate page for newcomers questions. I was against it as it seems important to me that a newcomers sees other discussions on the talk page. But I could be wrong and adding an extra page for questions might be a helpful solution. I don't remember if I told @Trizek-WMF about it.

@Iniquity you did, and we agreed. :)

@KStoller-WMF I added this topic as one item for the next Ambassadors meeting.

My thoughts so far:

  • Mark the mentor as away?
    • Seems to be the easiest option. Most talk pages protections I'm aware of are short-time harassement from an angry user. Long-term protections are a few, and even if we look for mentors, maybe we should not include these few volunteers.
  • Allow mentors to have a second talk page for newcomers’ questions?
    • It would just displace the problem. In the example @Urbanecm_WMF gives, AmandaNP/IP's talk page history shows reverted edits from vandals, harassers, socks... It also means two talk pages to watch for others mentors/users to watch, and a new page where an angry user can post on. And sometimes this angry user is a mentee.

Allowing mentors to provide a secondary talk page would make this more complex, but I think it'd be a better solution, as it'd help us to have more active mentors.

I agree that we should aim to keep as many mentors active as possible... but I'm not convinced that this is an issue often enough to justify that level of complexity. It not only makes this task more work and the code more complex, but it would make the mentor side of settings more complex. But as always, I'm open to being persuaded otherwise by you or the community. :)

To be sure, I'm not really sure about this myself -- it's a brainstorming-level idea, not a well-thought proposal (sorry if that wasn't clear).

[...]
It would just displace the problem.

Not necessarily. In my experience, the most annoying thing on user talk page vandalism are notifications. By moving the vandalism to a different page solves that problem (although in a less-than-optimal way, silencing notifications would probably be better).

[...]
It would just displace the problem.

Not necessarily. In my experience, the most annoying thing on user talk page vandalism are notifications. By moving the vandalism to a different page solves that problem (although in a less-than-optimal way, silencing notifications would probably be better).

We could have the case of mentors who ignore that second talk page, as they aren't notified of new messages. I already observe mentors who don't reply to mentees messages even at their main talk page. What would happen with a secondary one?

[...]
It would just displace the problem.

Not necessarily. In my experience, the most annoying thing on user talk page vandalism are notifications. By moving the vandalism to a different page solves that problem (although in a less-than-optimal way, silencing notifications would probably be better).

We could have the case of mentors who ignore that second talk page, as they aren't notified of new messages. I already observe mentors who don't reply to mentees messages even at their main talk page. What would happen with a secondary one?

Fair point.

This task was discussed with Growth Ambassadors, and I also reviewed community feedback here, this wiki conversation, and feature requests from Spanish mentors. Based on all of that input, I think the best path forward is to limit this task to just the current description (treating Mentors with blocked talk pages as Away / Unavailable) and then also consider working on this task in the future:
T322763: Provide a separate talk page for mentors, for questions coming from their assigned newcomers.

Providing a separate talk page for mentee conversations is a feature that some mentors would appreciate in other scenarios, so it should be designed and developed in a way that makes sense for a more general use-case, not just for Mentors with blocked talk pages.