Thanks for filing this. I suspect we will be fixing this behavior as part of T269638: Add a link: Suggestions mode (cc'ing @mewoph as the one who's working on that)

Not entirely since the current way it works is that the tag is added for any edit while the page is being tracked (ie. the user clicked on the corresponding task card some time in the last seven days). That's how tracking works for other task types, and we use the same logic.

If it's not considered too important, I would align the specification to the current behavior to cut scope. Otherwise, we'll have to add some kind of flag to the API request VisualEditor makes to save the edit (no idea how hard that is), or add the tag from AddLinkSubmissionHandler (easy but it means the tag won't be part of the initial edit event - not sure if that makes analytics more complicated).

In T277518#6916940, @Tgr wrote:

Not entirely since the current way it works is that the tag is added for any edit while the page is being tracked (ie. the user clicked on the corresponding task card some time in the last seven days). That's how tracking works for other task types, and we use the same logic.

If it's not considered too important, I would align the specification to the current behavior to cut scope. Otherwise, we'll have to add some kind of flag to the API request VisualEditor makes to save the edit (no idea how hard that is), or add the tag from AddLinkSubmissionHandler (easy but it means the tag won't be part of the initial edit event - not sure if that makes analytics more complicated).

I'm inclined to agree. The behavior for the 'Suggested: add links' tag is consisted with the Newcomer tag. However, if the specificity for 'Suggested: add links' is really important - maybe they are worth evaluating?

Another question - should it be allowed to switch to the source editor in the context of Add links work?

Thank you for noticing this, @Etonkovidova. I thought it through and I agree with @Tgr. We can align the specifications to the current behavior, and allow the tag to be applied for any edit originating from the "add a link" task. But I only think that's a good idea if we'll be able to audit later on what percent of the edits are actually not link edits, and are instead VE or source edits. @Tgr, will that be easy to do via the logs table or something else?

In T277518#6927511, @MMiller_WMF wrote:

@Tgr, will that be easy to do via the logs table or something else?

I don't think there's an easy way to do that. The logs are linked to the page but not the specific revision, so you'd have to correlate revisions of the page with log entries with a very close timestamp, which seems cumbersome. It should be easy to add that extra information to the logs, though.

On second thought, the growthexperiments_link_submissions table does contain revision IDs, so we can just use that instead of the log. Still, associating the revision with the log entry seems like a nice thing to do.

Change 674436 had a related patch set uploaded (by Gergő Tisza; owner: Gergő Tisza):
[mediawiki/extensions/GrowthExperiments@master] Associate revision IDs with link recommendation logs

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

Change 674436 merged by jenkins-bot:
[mediawiki/extensions/GrowthExperiments@master] Associate revision IDs with link recommendation logs

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

Structured edits can now be filtered via SELECT ... FROM revision JOIN log_search ON ls_field = 'associated_rev_id' AND revision_id = ls_value JOIN logging ON ls_log_id = log_id WHERE log_type = 'growthexperiments' AND log_action = 'addlink'.

@Tgr
I did some add link edits on cswiki betalabs and checked

SELECT ... FROM revision JOIN log_search ON ls_field = 'associated_rev_id' AND rev_id = ls_value JOIN logging ON ls_log_id = log_id WHERE log_type = 'growthexperiments' AND log_action = 'addlink'

and GrowthExperiments log - /wiki/Special:Log?type=growthexperiments&user=&page=&wpdate=&tagfilter=&subtype=addlink.
No addlink action was recorded and there are no addlink in logging:

[cswiki]> select distinct(log_action) from logging where log_type='growthexperiments';
+--------------------------------+
| log_action                     |
+--------------------------------+
| claimmentee                    |
| claimmentee-no-previous-mentor |
+--------------------------------+
2 rows in set (0.00 sec)

Sorry @Etonkovidova, I didn't think my previous comment through. Logging is implemented in the backend but the frontend call is still missing. So this is only fixed in the sense that it will work once the frontend logic (T269657: Add a link: edit summary and publish) is in place.

@Tgr -- I just want to review to make sure we covered the original issue here:

Thank you for noticing this, @Etonkovidova. I thought it through and I agree with @Tgr. We can align the specifications to the current behavior, and allow the tag to be applied for any edit originating from the "add a link" task. But I only think that's a good idea if we'll be able to audit later on what percent of the edits are actually not link edits, and are instead VE or source edits. @Tgr, will that be easy to do via the logs table or something else?

With your change, we will be able to do that?

In T277518#6959253, @MMiller_WMF wrote:

With your change, we will be able to do that?

Yeah, the query in T277518#6943010 should work once link recommendations are fully implemented.

Since, the option for choosing the source editor was removed, I re-checked and there are several scenarios when Suggested:add links tag is added for a normal edits (outside of Add link surface).

Steps to make an VE/source editor edit on suggested Add link article to have Suggested: add linkstag:

• a user gets to an article with suggested add link via SE module
• a user does not perform any actions - not clicking 'Yes'/"No', not reloading the page etc.
• then, a user navigates away and searches for the article's title and starts editing in a normal VE mode. The edits would have Suggested: add links tag.

Additionally, when an edit with Suggested: add links tag is undone, the undone revision will also have Suggested: add links tag. (it's, probably, ok).

The Suggested: add links tag is not added (CORRECT behavior)

• if a user gets to an article with suggested links by searching for a title or via RC/Watchlist links
• if all link suggestions are skipped

In T277518#7068264, @Etonkovidova wrote:

Since, the option for choosing the source editor was removed, I re-checked and there are several scenarios when Suggested:add links tag is added for a normal edits (outside of Add link surface).

Steps to make an VE/source editor edit on suggested Add link article to have Suggested: add linkstag:

• a user gets to an article with suggested add link via SE module
• a user does not perform any actions - not clicking 'Yes'/"No', not reloading the page etc.
• then, a user navigates away and searches for the article's title and starts editing in a normal VE mode. The edits would have Suggested: add links tag.

The same thing happens for other tasks (e.g. copyedit), if I recall.

That said, now that we have the postSave hook from VisualEditor, we could untrack the page ID in includes/NewcomerTasks/Tracker/Tracker.php, so subsequent edits to that page wouldn't show up with add-links.

Change 686433 had a related patch set uploaded (by Kosta Harlan; author: Kosta Harlan):

[mediawiki/extensions/GrowthExperiments@master] Tracker: Untrack pages after link recommendation edit

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

Change 686433 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Tracker: Untrack pages after link recommendation edit

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