Dupe of bug 42139 (specifically bug 42139 comment 1)?

Re-purposing this to flesh out bug 42139 comment 1.

@Esanders would resolving this task enable us to extend T232601 to edit summaries?

I'm not suggesting we prioritize this, but the use case below occurred to me today and thought I'd ask.

Context

Use case: newcomer seeking review from mentor

1. Newcomer receives guidance from an experienced editor, be it via the Growth team's mentorship module or some other means [i]
2. Newcomer makes an edit per mentor's instructions
3. Newcomer wants to get the attention of their mentor, to ensure they made their edit correctly before someone comes along and reverts said edit
4. Newcomer types their edit summary and @-mentions their mentor in said summary

😀 Benefits

• Mentor gets a notification linking them to the precise edit they are being asked to review
• Newcomer avoids their edit being reverted by someone else
• Mentor and newcomer now have a more contextual way of communicating about the process of editing through the edits themselves.

😬 Risks

• Easier to notify people = more noise
• People writing edit summaries could begin to tailor their summaries to individuals rather than "other editors as a whole" leading them to become more difficult to understand.

i. https://nl.wikipedia.org/wiki/Overleg_gebruiker:Jessevermeulen18

@MMiller_WMF cc'ing you for your awareness.

@ppelberg -- thanks for thinking about this. We have the idea for "notify your mentor" as part of the longer term of suggested edits. Here's a mockup, and shown below.

Our thinking here was that the user would not be pinging the mentor in an actual edit summary, but rather writing them a separate notification via a dedicated workflow that would automatically ping the mentor, after having already posted a normal edit summary.

But maybe it would make sense to combine that into one step, which would reduce how many "posts" happen after an edit is completed, and streamline the workflow for the user.

It is currently possible to ping users in edit summaries, but only by using the traditional user page link syntax, e.g. [[User:Cloud atlas]]. It sounds like you're saying that it would be better if they could use the @ symbol and autocomplete with usernames. Perhaps that would be useful beyond just newcomers.

But all this said, I think that if we're going to ecourage newcomers to ping their mentors in the edit summary (or elsewhere), we wouldn't have them type out their mentor's name, even with autocomplete. The system would know their mentors name and take care of that part for them. Although, the argument I see for having the newcomer type their mentor's name is that they would learn how to ping in edit summaries. What do you think?

FYI @RHo

In T54174#6178473, @MMiller_WMF wrote:

@ppelberg -- thanks for thinking about this. We have the idea for "notify your mentor" as part of the longer term of suggested edits. Here's a mockup, and shown below.

Assuming people are "feeling good" after having successfully completed an edit, it seems like a good idea to provide them with an opportunity to "shop" for more edits to make so they can keep that flow going.

But maybe it would make sense to combine that into one step, which would reduce how many "posts" happen after an edit is completed, and streamline the workflow for the user.

This is what I had in mind. Additionally, I wonder if guiding the mentee to notify their mentor by way of edit summaries could have the following effects:

• Other experienced editors will act more conscientiously towards newcomers, and their edits, if newcomers' intentions are more legible them.
  • Here, I'm assuming the interaction the "Notify mentor" workflow would facilitate would be less visible to experienced contributors than if the communication happened through edit summaries.
• Mentors will appreciate newcomers interacting with them via the tools/workflows they're used to
• Newcomers will learn a skill that is likely to benefit outside the context of Newcomer tasks.

I also wonder whether it's more consistent with how other, more experienced editors behave, to introduce this piece of communication (read: Edit summaries) as being a part of the edit process as opposed to something that happens after the fact. This is a thought I'd like to develop more.

It sounds like you're saying that it would be better if they could use the @ symbol and autocomplete with usernames. Perhaps that would be useful beyond just newcomers.

Exactly (to both points).

But all this said, I think that if we're going to encourage newcomers to ping their mentors in the edit summary (or elsewhere), we wouldn't have them type out their mentor's name, even with autocomplete. The system would know their mentors name and take care of that part for them. Although, the argument I see for having the newcomer type their mentor's name is that they would learn how to ping in edit summaries. What do you think?

I think it would be fine to automatically insert the mentor's handle into the newcomers' edit summary so long as newcomers can see the ping and have it appears as such: @Marshall.

Reason:

• I think newcomers will intuitively understand/recognize the presence of @USERNAME to mean: [i]
  • A) @username is going to get a notification
  • B) To notify someone next time, I bet I can just type @ and the rest will work like it does on other platforms.

i. The above is informed, in part, by the latest round of user tests we ran where we found most test participants intuitively understood typing @ to tag/ping/mention someone else. See "@-mentioning a user not in the conversation" in T246190#6186156

another potential use-case: linking to policies that are violated when reverting an edit. many editors do this in an ad-hoc way but providing a bit more structure for this would be great

Great idea, @Isaac! Thank you for this suggestion. I will add it as a use case to the ticket.

inserting links, and formatting text

Note that formatting isn't supported: https://www.mediawiki.org/wiki/Help:Edit_summary#Key_features

All that's allowed are internal or interwiki links and special sections link using /* comment syntax */