Update - I have added the final approved text for the warning message following our internal review. This ticket is no longer blocked, cc @OBenhmida & @cmelo

This will not currently be worked on by the Connection team, but a version of this may be worked on in Q2 or a later quarter of the 26/27 fiscal year. So, @JFernandez-WMF will document designs and work so far, so that it can be later considered for a future project.

This is wrapped up, as we are now working on the MVP. All open questions will be resolved in epic tasks.

This can be closed, as the team is now working on collaborative tracking against a worklist and all open questions will be resolved within epic tasks.

This work is now complete, as Julieta shared some of her ideas in team meetings and the offsite. Next steps are focused on more specific project ideas within separate tasks.

This looks good to me. Only suggestion is to maybe change the commas to periods before the 2 sentences that have "found," so:

@cmelo, can you add some technical details to the task for how we set this up? Thank you!

@Daimona, yup, it would be a personal worklist, so not associated with an event. But, if we made it private via the ReadingLists extension, I assume we could still input whatever data/features we have in the public version (such as showing a quality score, suggested tasks, or the ability to mark progress as upcoming/in progress/done)? Anyway, I guess this is best discussed separately outside this ticket :)

@Daimona, thanks for the clarification. From my understanding, at the Contributors Offsite, we talked about a way that we can allow privacy (at a worklist or article level) for personal worklists, correct?

We discussed this in a team meeting, and @JFernandez-WMF will create a basic design to show the placement of the message in the post-edit dialog.

Notes from June 1 team meeting:

• Message text has been updated in AC
• People should be able to see worklist even if they are logged out because the worklist can help people decide if they want to join an event. Maybe in the future we will allow editors to hide the worklist for certain cases, but this is not required for the MVP. This is also the same behavior that we have for the Contributions tab.

It is so great to read up on these learnings so far, @MNeisler! In particular, it is great to see the breakdown of edit rate by experience level. I'll share the findings that we have so far with the team, and I look forward to the next steps!

Yes, @JVanderhoop-WMF, thanks for the clarification and link to documentation. Not an experiment, but running Test Kitchen. Much appreciated!

@JVanderhoop-WMF: Hey there! Yes, we're interested in click-through-rates and health outcomes, rather than running an A/B test. We have a few reasons why, but the main reason that we don't want to do an A/B test for this work, most likely, is that we just don't think we would learn very much from it (for this particular set of features). We are already pretty confident that any control group would *not* be able to find the events we promote. So, it would be extra set-up for minimal learning benefits.

Yup, sounds good. Thanks! Great ticket for the small items backlog.

@Daimona, I agree that the workaround makes sense. In terms of placement, it would be replace "Search keyword" in Special:AllEvents and "Search" in Special:MyEvents? If yes, then perhaps:

@Daimona, yes, it means that the article does not exist on the wiki. I think it makes sense to use the same messages/language we have from invitation lists. In that case, is it best to update the AC to say to just use the invitation list messaging for nonexistent articles?

Note: This ticket is lower priority than our worklist + event discovery work, so I am recommending that we pause for now & then return after the worklist + event discovery work is complete.

Note: This ticket is lower priority than our worklist + event discovery work, so I am recommending that we pause for now & then return after the worklist + event discovery work is complete.

@JFernandez-WMF, thanks for adding the design updates! I agree that 'Article name' is more clear. Let's use it. Thank you!

Thank you so much for your feedback and for offering alternatives, @KStoller-WMF & @bmartinezcalvo!

Note: @JFernandez-WMF will update this ticket with a design change to show article name rather than URL.