We have agreed to a Monday, November 25th 2024 release, and I have updated the enwiki community here.

Given that we have completed: T380161: Verify Add Link's readiness for partial deployment, and we have Community support at enwiki for a 2% release, we should now finalize a release date.

I'd say the impact is probably minor enough for it being ok for this to roll out with the next train, but Product (@KStoller-WMF) should maybe have the final call on that.

Thanks! Given this is a fairly small change, I'm moving into Up Next / Medium priority.

Initial designs shared here: https://www.figma.com/design/e4XsAxsKRtZjwqIA7rE985/Surfacing-structured-tasks?node-id=979-37&node-type=canvas&t=zDpNhUbLPPazJ0Do-0

In T380329#10342518, @Urbanecm_WMF wrote:

The limit was introduced in rRMWA576253f35f70: Allow excluding sections from link generation when the excluded sections features was implemented in T279519: Add a link: algorithm improvements: Avoid recommending links in sections that usually don't have links. AFAICS, the limit was not requested on the task itself. I see it got introduced in PS3 of the patch, but this was before any code reviews were noted on the patch. Unfortunately, the commit message only mentions the cap exists, but not why it was introduced.

It looks good to me, and I've been looking at the data at least once a week. Thanks for the work on this Cyndy and Marcel!

Open question: if we only surface one task, how do we handle the other link recommendations? (Is that recommendation removed?)

Thanks for the quick testing and notes @Etonkovidova !

I'll let @Etonkovidova complete a more thorough QA, but from my limited testing this is looking good. :)
👍 The highlight loads immediately; I'm not noticing any awkward delay.
👍 I reviewed several articles and the highlighting matches the designs and works as expected.
👍 The popup is pointing to the link suggestion.
👍 The popup is easily dismissible as expected (dismissed if I click No, x, click outside of the pop-up, or scroll away).

@Michael & @Sgs - Some recent design feedback came in that we shouldn't emphasize the "Yes" option if we don't know the suggestion is correct. Making both options neutral also better matches the UI within the VE pop-up.

Interesting, I'm unsure if there was a reason why the filters were set in that way originally, but I agree showing "in progress" tasks makes sense!
I believe I have updated the default view for everyone:

You caught me, I totally spaced that we limited this to mobile. I'll switch to mobile and try again.

In T376680#10333045, @Michael wrote:

This should be testable on beta-enwiki. Reminder that the feature is only enabled for new accounts with 0 edits.

@JFernandez-WMF - FYI, @Sgs and I discussed this a little more, and agreed that we should use this task more as a QA umbrella task for this issue, and that he would take an initial pass at reviewing associated tasks.

• Share summary of the Measurement Plan on MediaWiki: https://www.mediawiki.org/wiki/Growth/Constructive_activation_experimentation#Measurement_and_Results

This task came up when I was reviewing "Stalled tasks" in our current sprint. The Acceptance Criteria is met, although community discussions are now ongoing. Given that Growth team Ambassadors are handling the actual community discussions, should I resolve this task?

Thanks, @Urbanecm_WMF, for explaining our various verification options!
I double-checked with @Sgs as well, and we both agree that #3 makes sense.

I'm marking this as high priority because ideally we should decide on this ASAP, however, I don't think this needs to be an alpha release blocker since the alpha test will be a small, targeted, and temporary test.

@Etonkovidova - feel free to adjust the description if you have more to add here. Thanks for bringing up this issue!

Moved out of Current Sprint, in favor of this task: T379124: Suggested Edits: Newcomer Tasks count QA. (Which is looking at the issue more holistically and considering if a design change is needed).

I'm moving this into the current sprint in an attempt to reach consensus on next steps for the task count issue.

Reviewing old tasks, and I think this one can be considered resolved as the main acceptance criteria was met.

In T379474#10307752, @Pppery wrote:

Trivial suggestion: delete the first sentence and say just "The maximum number of days a mentor can be away for is 365 (one year)."

Interesting, thanks! With confirmation by @KStoller-WMF, I can create a task to not just remove that config but the entire associated custom-text-input feature.

In T379671#10314205, @Pppery wrote:

I would think it should still be documented until the extension is fully undeployed and archived.

Blockers removed, but we are moving to Backlog for now, with the hope to release in January 2025.

@Michael brought up the point that we should likely also respect the task type opt-out from the homepage. For example, the "Add links..." task is selected by default, but if I unselect it, then we should respect that preference. Do you agree?