That sounds like a limitation in Echo

@Trizek-WMF I added a suggestion for what an initial test could look like. We'll never find a perfect way to screen for users "who have empathy for newcomers", but I also imagine self-selection will help here, and users who don't have empathy for newcomers won't be interested in devoting time to being a Mentor.

In T322446#8708860, @Urbanecm_WMF wrote:

Hi @KStoller-WMF, I just got to the community configuration bit of this task, and I have a couple of questions/suggestions, which you can find below (inlined in the specification quoted from the description).

Personalized praise:
Should the Mentor dashboard include a module to surface mentees who are editing successfully?

• Enabled

I don't think this needs to be (community) configurable. It feels very unlikely a community would want to prohibit mentors to make talk page posts via this feature. Theoretically, a community might consider Personalized praise notifications as annoying and therefore want to disable the notifications (at least by default), which is possible below, but I find it hard to imagine a case when someone would want the whole module gone. To keep the config page of a reasonable length, I suggest removing this configuration option.

Declining task due to findings that suggest the initial data might not have been conclusive:
https://phabricator.wikimedia.org/T330614#8689243

@Jdlrobson & @NRodriguez - pinging you in case you are interested in following this task.

Thank you, @Etonkovidova ! I've logged a follow up task for engineers based on the work you completed for this task: https://phabricator.wikimedia.org/T332428

Maybe we should think about whether there's any cheap-to-implement fallback content we could add that's at least mildly useful.

Thanks for the update! It looks like the designs didn't take into account the notification character limits. I'll consider this as I finalize copy.

@Urbanecm_WMF - sorry for the delay on this one! I've added the instrumentation rules from the Measurement Specification doc. I notice that @nettrom_WMF still has a few open questions in the notes section, so please just let us know if there is anything further you need to know here.

My plan is to remove the mentee from the list of praiseworthy mentees when the mentor clicks the "Send appreciation" button on the module (regardless of whether they actually saved the message). This is not ideal, as mentors might click that button and then not actually post anything, but IMO it works well enough for the MVP. If it turns out to not work at all, we can improve it.

@Esanders Yes, thanks for the reminder! I've moved to to Growth QA.

@CBogen - Just FYI, this task has been put on hold a few times due to higher priorities (Newcomer Pilot Experiment analysis, Positive Reinforcement analysis, etc.) but please let me know if there is a deadline (or specific data needed) for SDAW reporting reasons. Thanks!

In T322435#8699363, @kostajh wrote:
Sounds good. I also changed the icon to the edit pencil, I assume that is preferred?

Thanks for testing, Elena!

@Urbanecm_WMF - After a Mentor leaves a mentee a talk page message via the personalized praise call to action on the Mentor Dashboard, ideally that mentee is removed from the list of praiseworthy mentees.
Is that going to be feasible for the MVP?

! In T322435#8697837, @kostajh wrote:
Then should we change the secondary link label to be "Make a suggested edit", or "Try suggested edits"? And to clarify, should the target for the URL be Special:Homepage or should it be the mediawiki.org help page? (IMO it would make sense for it to be Special:Homepage)

In T322435#8695089, @Tgr wrote:

It's only omitted for emails (where the primary link is a blue button and the secondary links are "quiet" backgroundless grey links, as can be seen e.g. at https://phabricator.wikimedia.org/T135574). This is how the two notifications look now on web (where the primary link is the entire notification area and the secondary links are "quiet" buttons at the bottom):

We completed the initial discussion with pilot wikis, so I will consider this resolved.
I have just added one follow up task, which we should revisit in May: T332089: Community discussion about "add a link" with Arabic Wikipedia

In T322435#8694080, @Tgr wrote:

For T328288: Leveling up: "Keep going" notification we use a secondary link that points to the same place as a the primary (for easier discoverability I imagine); we could do that here as well, for consistency. Or remove it there as well.

In T322435#8690373, @Tgr wrote:

Linking to another wiki seems confusing to me. The user will have to figure out that they are on a different wiki (especially on mobile not that easy to notice), the user interface will be in English, the user might not be logged in anymore (because cross-wiki authentication is unreliable) which would further the confusion, and the brand recognition for mediawiki.org is approximately zero. Once we roll this feature out to many wikis, the chances of the page being translated to the user's language will be pretty low. And I wonder if users will even notice there is a main clickable area (IMO this is a design flaw of Echo).

As we've already completed two rounds of collecting feedback for this project, and we are now incredibly close to actual release, so I think further community feedback is no longer necessary. We'll soon hopefully start to get feedback (or at least data) from actual feature use.

It would be great to A/B test what works best on new wikis, but I assume the sample would be too small to run a small experiment and come back with significant findings. Perhaps we could consider a few user tests with newcomers on new wikis?

Thank you for the clear breakdown of our options and the effort involved!

I added a screenshot of the design that includes that text.

@KMorgan-WMF
I presume we should be linking to this page:
https://www.mediawiki.org/wiki/Help:Growth/Tools/Suggested_edits