Page MenuHomePhabricator

Scale: align welcome message mentor to homepage mentor
Closed, ResolvedPublic

Description

The newcomer homepage provides a mentor to any mentee based on a specially formatted page on wiki. Meanwhile, many wikis already do some kind of automated mentor-like outreach to newcomers based on existing lists of mentors. For instance, Arabic Wikipedia automatically posts a welcome message on every new account's talk page, signed by a random name from a list. Right now, these two lists are not unified -- a newcomer may receive a welcome message from one user, and then their mentor on their homepage may be a different user. (NB: through an experiment being done by CAT Lab, we will learn how valuable automated welcome messages are for newcomer activation and retention.)

Current state

The Growth team features automatically assign a mentor to everyone, and stores it in newbie's user preferences. That means the assignment is private by default. The only exception to that is when the mentee is claimed via Special:ClaimMentee, which publishes both the new and the previous mentor (see logs at ar.wikipedia as an example). That means that we are already publishing the mentee-mentor relationship in some corner cases, and thus, this can implicate it's less of an issue to make it public for everyone.

Possible use cases

On some wikis, this interaction between mentor and mentee can or could go further than only on the homepage:

  • display the mentor's name on a message left to the mentee's user talk page, like a welcome message (Hello, I'm [[user:Mentor|Mentor]] and I welcome you) or some guidance (please ask [[user:Mentor|your mentor]])
  • display the mentor's name on a sandbox template (sub-page of mentee's user page) to have a reminder about who they should contact
  • create user boxes: "My mentor is Mentor".

One open question is whether users who sign up to be welcome message signers will also want to be mentors and vice versa. Perhaps the unified sign-up page should allow users to indicate which of the mentorship programs they want to participate in. On the other hand, maybe we should not allow users to only participate partially -- because we think that there should be a connection between the homepage mentor and welcome message signer.

Magic word approach

The easiest way I can see to implement this would be to have a magic word/parser function, something like {{#mentor:Newbie}}, which would return Newbie's mentor. That can be used by communities to feed welcoming bots as well.

@Tgr mentions in T233250#5957602 that the magic words are evaluated real time, which is correct. This could cause change of mentor's username almost in real time in cases when it is wanted, but sadly also in cases where the name is meant to stay stable, such as in signatures. That can be workarounded via substituting the parser function: something like {{subst:#mentor:Newbie}}. This can be even used in templates, something like {{su<includeonly />bst:#mentor:Newbie}} should work fine in a template.

This approach:

  • Enables a bot to easily place a template on wiki with the Growth mentor's name.

This approach does not:

  • Enable he situation where the bot constructs the text itself, instead of a through a template, because it can't run a magic word itself -- it has to be pasted somewhere.
  • Enable mentors to be assigned by topic.
  • Enable mentors to opt-out of either being the homepage mentor or the talk page mentor. In other words, this is not an abstracted mentor list that can be used for arbitrary purposes -- it is more that this approach allows other functionality to draw on the Growt mentor.
  • Change how mentorship is stored in the database.

For the thing that this approach does not enable, future ideas include storing mentors in their own table in the database, along with other mentor metadata (like topics of interest), and allowing mentorship signup to happen on a more structured Special page.

How will this work?

The magic word will be used like this (wikitext):

Martin Urbanec's mentor is {{#mentor:Martin Urbanec}}

This will print something like:

Martin Urbanec's mentor is (username of whoever is my mentor)

That way, communities will be able to update their welcome messages to simply use {{#mentor:<newbie's username>}} to display the mentor's name.

In case there is no assigned mentor, the function will simply output nothing (in other words, it will not automatically assign a mentor, just return the current state of mentee/mentor relationship). For newcomers, this shouldn't be an issue – and it is possible to wrap it in an #if statement, signing it with a default account as a fallback.

Event Timeline

@Trizek-WMF: Assuming this task is about GrowthExperiments, hence adding project tag so others can find this task when searching for tasks under that project or looking at that project workboard.

8:48 PM is not my best time to be efficient, @Aklapper! 😝

MMiller_WMF renamed this task from Have a way to display on any user page or user talk page the name of the mentor assigned to a mentee to Homepage: align welcome message mentor to homepage mentor.Mar 4 2020, 7:31 PM
MMiller_WMF updated the task description. (Show Details)

This is easy to do but some things to consider:

  • It will make user-mentor relationships public (even if the magic word is not used on one's page, it can be checked via edit preview).
  • Magic words are evaluated real-time so when the mentor changes the page would change. This might be a good thing in some cases (e.g. in a help template), probably not wanted in other cases (e.g. a signature). Could be substed, but that requires some changes to the bot and the general UX of the welcome (if it's not substed already).
  • For non-substed usage, there's some possibility of abuse now since any (GrowthExperiments) mentor can claim a user, but users cannot change their mentors.

At the moment, we have two ways to create mentors lists based on existing lists:

At the moment, these pages are listing the following items:

  • username (signature lists only have this)
  • short description (only on Growth-shaped lists)
  • interests (long description)
  • interest (topics, like on SuggestedEdits)
  • last activity (also on the homepage)
  • action like/button to contact the user on wiki

I listed the most common ones, because I've also seen cases where admins and non-admins are listed, or sometimes the location of the mentor.

One example of the most current case: https://nl.wikipedia.org/wiki/Wikipedia:Coachingsprogramma

Should we take the opportunity to unify these lists?

Provide unified, filterable lists would help communities to shape their mentoring efforts. Communities could rely on this page to have names, descriptions and points of contact for newcomers. It would also help the Growth team by being sure that mentors are creating the list for the mentorship module the right way.

Ideally this new page should be a page where mentors just have to add their username and description, which would lead to a nice looking page for people visiting it.

Maybe have it as a special page (Special:Mentoring?), available on all wikis by default?

MMiller_WMF renamed this task from Homepage: align welcome message mentor to homepage mentor to Scale: align welcome message mentor to homepage mentor.Apr 3 2020, 10:18 PM

In thinking about the various scaling tasks, I consider this task not to be strictly required before we scale, but I think it could be a pretty big help. The reason it's not strictly required is that the homepage has been deployed on Arabic Wikipedia for months with users receiving different mentors on the homepage than the users who sign their welcome messages. That said, the reason it could be a pretty big help is that if we can use a wiki's existing list of mentors to also be the help panel mentors, then a wiki won't have to go through as much process to collect and list mentors.

This was discussed in my check-in meeting. I feel that the magic word approach would be more useful for wikis like cswiki, who don't have a dedicated list of welcome message signers, yet the welcome message could be altered to also introduce the mentor.

Would it be possible to simply return a user's current mentor?
https://fr.wikipedia.org/wiki/Sp%C3%A9cial:Journal/growthexperiments indicates the previous mentor when assigning only one. The bot trainers for the welcome messages can then take care of the rest.

It seems that Russian Wikipedia wishes to have this feature. (ping @Iniquity)

Oh, thanks! Means, that not only I think about it.

We have two bots that send a template (https://ru.wikipedia.org/wiki/Template:Hello) with the following signatures (https://ru.wikipedia.org/wiki/Проект:Помощь_начинающим/Приветствующие). The list is almost the same with mentor's list (https://ru.wikipedia.org/wiki/Проект:Помощь_начинающим/Наставники), but some users of this list refused to become mentors because of too much workload.

I'm not sure about combining the lists, it needs to be discussed. This can cut off a number of participants.

Considering that bots do this, I think we just need an API with mentor's nickname and the bots will take the desired nickname.

French Wikipedia has two pages, one for the welcome message, and one for mentors on the Homepage. The first one is a mirror of the previous one, used only by the welcome message bot. It seems that the fusion of these two lists went well: people who agreed to sign the welcome message overall agreed on becoming mentors.

Czech Wikipedia had a different need that may be interesting for your case. They have on-wiki mentors and at-workshops mentors. Some of the latter don't want to be auto-assigned to newcomers they don't know on wiki, but they wish to have a way to claim the mentees they worked with at the workshop. As a consequence, it is now possible to have a separated list for mentors who can claim mentees, but who won't be automatically assigned to newcomers. Check on https://www.mediawiki.org/wiki/Growth/Communities/How_to_introduce_yourself_as_a_mentor#separate-list to know more about this feature.

Maybe have it as a special page (Special:Mentoring?), available on all wikis by default?

In T274031: Provide custom editing interface for GrowthExperiments on-wiki configuration we're talking about creating a Special Page with a form input + validation for NewcomerTasks.json, maybe the same idea would be useful for managing the mentor lists, either using a JSON content page like MediaWiki:GrowthExperimentsMentorship.json, or, maybe it's worthwhile to graduate this from using a wiki page to a custom schema in database table(s). That could also potentially result in migrating the mentorship assignments from user preferences to a DB table.

Storing mentor-mentee relations in a table would be nice. The list of mentors, I'm less sure - a wiki page (especially with magic words instead of the current somewhat hacky list syntax) is intuitive, observable and revertable, and allows mentors to introduce themselves in a flexible format (although the way Growth mentorship works now, there isn't really any need for introductions).

Storing mentor-mentee relations in a table would be nice. The list of mentors, I'm less sure - a wiki page (especially with magic words instead of the current somewhat hacky list syntax) is intuitive, observable and revertable, and allows mentors to introduce themselves in a flexible format (although the way Growth mentorship works now, there isn't really any need for introductions).

ftr, I personally think that storing mentors in a table would be useful, too. It would make it easy to expand the definition of mentor with further properties, like topics (if we ever decide to do that), and would also allow us to query by topic easily if we ever want to. AFAIK user_properties can't search by up_value really well (as it's unindexed).

Mentors are not stored in user_properties; they are parsed from the mentor page on the fly. That works fine for searching, and with some cache layer it would be reasonably scalable. (Although if some large wiki decides to have a huge amount of mentors, the wiki page as a UI doesn't scale as well.)

Mentors are not stored in user_properties; they are parsed from the mentor page on the fly. That works fine for searching, and with some cache layer it would be reasonably scalable. (Although if some large wiki decides to have a huge amount of mentors, the wiki page as a UI doesn't scale as well.)

Ah, right. That would make storing topics difficult (would we append a JSON blob after it? or make it full JSON?) through. A JSON with a custom UI might work, through I'm unsure whether some extension does that already.

I'd just use a parserfunction ({{#mentor|Tgr|description=Hello world!|topics=foo,bar,baz|...}}), collect those parameters into an array, stash the array into parser output extension data, and retrieve it from there when needed. That is a single DB read, plus potentially a parse if the page hasn't been parsed recently, but retrieving this data is not that time sensitive (...I think? or maybe we do it on registration? we'd have to wrap it in memcached then). It lets communities wrap it into templates for fancy display / usability / backwards compatbility with previous systems of mentorship, break it into multiple pages etc.

Change 663895 had a related patch set uploaded (by Urbanecm; owner: Urbanecm):
[mediawiki/extensions/GrowthExperiments@master] Add magic word {{#mentor:username}}, allowing users to get someone's mentor

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

Thanks @Trizek-WMF for the reminder I should write a description here :).

The magic word will be used like this (wikitext):

Martin Urbanec's mentor is {{#mentor:Martin Urbanec}}

This will print something like:

Martin Urbanec's mentor is (username of whoever is my mentor)

That way, communities will be able to update their welcome messages to simply use {{#mentor:<newbie's username>}} to display the mentor's name.

In case there is no assigned mentor, the function will simply output nothing (in other words, it will not automatically assign a mentor, just return the current state of mentee/mentor relationship). For newcomers, this shouldn't be an issue – and it is possible to wrap it in an #if statement, signing it with a default account as a fallback.

Does this work, @Trizek-WMF?

I'll happily help you wih some announcement to the communities if you wish me to.

I think it makes sense. I've been confused by the fact that you are mentoring yourself!

When will it be available for communities?

Hi, tell me plz, will the mentor pinged in this case? :) I just don't remember how the Notifications extension reacts to this syntax.

{{#mentor:Someone}}, hi! How are you? ~~~~

I think it makes sense. I've been confused by the fact that you are mentoring yourself!

Oh, sorry :-). Yeah, I claimed myself so I can test mentorship features without switching identities :).

When will it be available for communities?

The patch is still under code review, and I'll need to react to tgr's feedback first (hopefully will do tomorrow).

Sadly, I can't predict when it will get deployed after it gets merged. Unfortunately, train has been blocked for full three weeks now, blocking all deployment of all new features or non-urgent fixes. I hope it will get unblocked this week, but...due to the unfavorable train status, it's hard to predirct the date for sure.

Hi, tell me plz, will the mentor pinged in this case? :) I just don't remember how the Notifications extension reacts to this syntax.

{{#mentor:Someone}}, hi! How are you? ~~~~

This syntax will definitely not ping the mentor directly, because the #mentor function provides the raw username, not a link. Something like [[User:{{#mentor:Someone}}]], hi! How are you? ~~~~ might work, but I'm not familiar with Notifications code enough to know for certain. @Tgr Do you happen to know?

Change 663895 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Add magic word {{#mentor:username}}, allowing users to get someone's mentor

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

Hi, tell me plz, will the mentor pinged in this case? :) I just don't remember how the Notifications extension reacts to this syntax.

{{#mentor:Someone}}, hi! How are you? ~~~~

This syntax will definitely not ping the mentor directly, because the #mentor function provides the raw username, not a link. Something like [[User:{{#mentor:Someone}}]], hi! How are you? ~~~~ might work, but I'm not familiar with Notifications code enough to know for certain. @Tgr Do you happen to know?

Notifications look for a a link to a userpage, inserted in a message signed by someone, in a proper section. If the conditions are there, a ping is sent. So I think [[User:{{#mentor:Someone}}]], hi! How are you? ~~~~ won't work since there is no proper username. Maybe [[User:{{subst:{{#mentor:Someone}}}}]], hi! How are you? ~~~~ would work.

I see a lot of cases where pings and #mentor can be combined. It would be useful to be sure that it would work.

@Trizek-WMF is right. [[User:{{subst:#mentor:Martin Urbanec}}|{{subst:#mentor:Martin Urbanec}}]] Hey, this is a test. --~~~~ successfully triggered a ping in beta enwiki for me.

@Trizek-WMF is right. [[User:{{subst:#mentor:Martin Urbanec}}|{{subst:#mentor:Martin Urbanec}}]] Hey, this is a test. --~~~~ successfully triggered a ping in beta enwiki for me.

Great, thanks :)

[...]
When will it be available for communities?

@Trizek-WMF Assuming everything goes as planned, it will be deployed on February 26 via the train.

Is [[User:{{subst:#mentor:Martin Urbanec}}|{{subst:#mentor:Martin Urbanec}}]] Hey, this is a test. --~~~~ a simple enough syntax? I understand that the option you choose allow to add parameters, ut this would be for an extended case.

Can't we have {{MENTOR}} as an alternative for simple writings, without any parameter? [[User:{{subst:{{MENTOR}}}}|{{subst:{{MENTOR}}}}]] Hey, this is a test. --~~~~ seems to be a bit more simpler.

Before announcing the release, we need to properly document it, and also provide a few examples (ping, userbox, welcome message).

@Trizek-WMF Hmm, how would {{MENTOR}} know which mentee are we talking about?

I was thinking about cases like when you use Special:MyPage to create links that always go to the reader's user page.

Anyway, let's document the existing and deploy. Feedback will arrive after a few usages.

I was thinking about cases like when you use Special:MyPage to create links that always go to the reader's user page.

I still can't understand how it would work. Special:MyPage is a redirect. We could have a Special:MyMentor that would redirect to a mentor's user (talk) page, but that would be hard(er) to incorporate with other mentorship features, as it wouldn't allow a way for templates (wikitext in general) to get the mentor's name.

Anyway, let's document the existing and deploy. Feedback will arrive after a few usages.

Drafted something at https://www.mediawiki.org/wiki/Help:Growth/Mentorship. Notes and suggestions are welcomed.

@Trizek-WMF Hmm, how would {{MENTOR}} know which mentee are we talking about?

It could use the current page. Not sure how useful that is in practice though, I'd find {{#mentor:{{PAGENAME}}}} less confusing.

@Trizek-WMF Hmm, how would {{MENTOR}} know which mentee are we talking about?

It could use the current page. Not sure how useful that is in practice though, I'd find {{#mentor:{{PAGENAME}}}} less confusing.

What if I'm talking with a mentee on my talk page, and I want to direct them to their own mentor for some reason? This could easily cause confusion. Communities can wrap their own templates (and/or lua modules) around this if they want to. If some feature is wanted by more projects, we can re-visit and implement some of them.

The example given by Tgr works on the mentee's talk page; typical case for a welcome message.

{{#mentor:{{BASEPAGENAME}}}} could then be used on mentee's subpage, like on their draft page.

I added these examples to the documentation page.

I documented some limitations on the documentation page: https://www.mediawiki.org/wiki/Help:Growth/Mentorship/Integrating_mentorship. TL;DR:

  • only people who created an account after the Growth deployment get a mentor
  • 100% of people get a mentor, but they don't all get access to the Homepage (because of the control group)

Moving to @MMiller_WMF - FYI.

The magic word is working as expected.
[[User:{{subst:#mentor:Mentee}}|{{subst:#mentor:Mentee}}]] still requires a signature.

@Urbanecm_WMF Hey! Please tell me what the magic word will return if it does not find a mentor? :)

It should return an empty string :).

It should return an empty string :).

thanks :)