In T301884: Add a link: rejection reasons, @nettrom_WMF found that about a quarter of the link rejections came with the reason "wrong link target". This may make us want to revisit this task. I will discuss with @RHo.

In T269648#7759034, @MMiller_WMF wrote:

In T301884: Add a link: rejection reasons, @nettrom_WMF found that about a quarter of the link rejections came with the reason "wrong link target". This may make us want to revisit this task. I will discuss with @RHo.

It seems to me that if the link target is wrong, perhaps the highlighted text doesn't need to be linked at all; when the link target is wrong, how could we know if we are suggesting links for phrases that are not important or useful to link?

@kostajh -- the way I was thinking about it, if the user thought the link should not be made at all, then they would have rejected another one of the rejection reasons, most likely "Almost everyone knows what it is" (which is the most commonly select rejection reason). Do you think about it differently?

Also, maybe something we can do is look at some actual suggestion pairs that got the response to see if the user might really have been able to choose a better link target if they have been given the opportunity. I made that request here: T301884#7767886

While we're talking about this, it would be valuable to get a quick t-shirt size estimate on this work. I am pretty sure it's not trivial because that's why we descoped it from Iteration 1. What do you think?

In T269648#7767890, @MMiller_WMF wrote:

@kostajh -- the way I was thinking about it, if the user thought the link should not be made at all, then they would have rejected another one of the rejection reasons, most likely "Almost everyone knows what it is" (which is the most commonly select rejection reason). Do you think about it differently?

Hmm, right, that makes sense.

Also, maybe something we can do is look at some actual suggestion pairs that got the response to see if the user might really have been able to choose a better link target if they have been given the opportunity. I made that request here: T301884#7767886

That sounds good.

While we're talking about this, it would be valuable to get a quick t-shirt size estimate on this work. I am pretty sure it's not trivial because that's why we descoped it from Iteration 1. What do you think?

It's not trivial; there are a decent number of UI changes and instrumentation to update. I believe we can make use of VE's link changing tool, but if there are issues around that, then it becomes more complicated. (cc @mewoph in case you have thoughts on this question + reusing the VE component).

Instead of having the "Yes" and "No" button, it now has a single new button in the middle: "Revert". The icon for this button is a curvy revert arrow.

Should we consider another word besides "Revert", which has a specific meaning in the context of editing on wiki? Perhaps "Change" or "Undo"?

The ambassadors have completed their qualitative evaluation of the "wrong target" rejection reason, with the results here: T304178#7815289

Here are the notes from that task copied below.

In T304178#7815289, @MMiller_WMF wrote:

The ambassadors have finished their evaluation in the spreadsheet. Here are the most important notes:

• Newcomers giving the "wrong target" response are usually right. In other words, they are generally assessing the rejection reason correctly.
  • arwiki: 42%
  • bnwiki: 77%
  • cswiki: 58%
  • eswiki: 79%
  • frwiki: 70%
• It does not seem like the users actually mean to be giving the "more or fewer words" response instead. They are accurately assessing that the link target is the issue, not the link anchor.
• So in thinking about T269648: Add a link: changing the link target (not for initial release), it seems like this could be a useful improvement. But with a couple of caveats:
  • Without also giving users the ability to change the anchor, it has limited value.
  • We may want to prevent users from linking to disambiguation pages, which do come up in the link menu by default.
  • Perhaps instead of adding flexibility and functionality to the "add a link" task, it's an opportunity to nudge users to the visual editor. Perhaps they select that rejection reason and we say, "Do you want to change the link? Here's how you can in Visual Editor!"
• In doing this evaluation, we noticed that there are a good number of suggestions for which we do not offer an appropriate rejection reason. They are phrases that should not have any link at all. For instance, a phrase like "younger children" may be suggested to link to a movie called "Younger Children". It's not that this is the wrong link suggestion -- it's that the phrase is just occurring in a sentence and shouldn't have a link. Perhaps we should add a rejection reason for this case.

We will talk on the team about what next steps we should do.

In T269648#7815303, @MMiller_WMF wrote:

The ambassadors have completed their qualitative evaluation of the "wrong target" rejection reason, with the results here: T304178#7815289

Here are the notes from that task copied below.

In T304178#7815289, @MMiller_WMF wrote:

The ambassadors have finished their evaluation in the spreadsheet. Here are the most important notes:

• Newcomers giving the "wrong target" response are usually right. In other words, they are generally assessing the rejection reason correctly.
  • arwiki: 42%
  • bnwiki: 77%
  • cswiki: 58%
  • eswiki: 79%
  • frwiki: 70%
• It does not seem like the users actually mean to be giving the "more or fewer words" response instead. They are accurately assessing that the link target is the issue, not the link anchor.
• So in thinking about T269648: Add a link: changing the link target (not for initial release), it seems like this could be a useful improvement. But with a couple of caveats:

• Without also giving users the ability to change the anchor, it has limited value.

This for me is the main reason to *not* move forward with T269648: Add a link: changing the link target (not for initial release) as it is currently stated. One idea might be whether it is possible to enable visual editor on that sentence only to enable changing the link text and target together, but I suspect it would be technically simpler and more in-keeping with promoting progressive learning about editing to offer them to edit in VE after the task is complete.

• • We may want to prevent users from linking to disambiguation pages, which do come up in the link menu by default.
  • Perhaps instead of adding flexibility and functionality to the "add a link" task, it's an opportunity to nudge users to the visual editor. Perhaps they select that rejection reason and we say, "Do you want to change the link? Here's how you can in Visual Editor!"
• In doing this evaluation, we noticed that there are a good number of suggestions for which we do not offer an appropriate rejection reason. They are phrases that should not have any link at all. For instance, a phrase like "younger children" may be suggested to link to a movie called "Younger Children". It's not that this is the wrong link suggestion -- it's that the phrase is just occurring in a sentence and shouldn't have a link. Perhaps we should add a rejection reason for this case.

We will talk on the team about what next steps we should do.