@RHo and @Pginer-WMF please find a first draft of the attribution guidelines that apply to Games and reach media experiences in our internal document. You're welcome to share feedback and/or directly make any necessary adjustments. Thank you!

Hey @Pginer-WMF and @RHo 👋🏻 You can find an early draft of the attribution guidelines for Social media contexts in our internal document. You're welcome to share feedback and/or make any necessary adjustments. Please keep in mind that the signal assignment to this scenario also needs confirmation from your side. Thank you!

Hey @Alice.moutinho. It's very nice to meet you! I shared your question with the Design system's steering committee in the #codex-design-system channel in Slack (see original message). The current plan is for Multi-step Dialog to remain a custom pattern instead of becoming a standalone system component. So there's no expectation for this element to be included in the library.
Michael Große, from the Growth team, chimed in to share a recent implementation of the Multi-step Dialog. They used it to present an onboarding quiz: ReviseToneOnboarding.vue. He thought that having access to an additional example could be useful for you.
I'm happy to help with any follow-up questions (Codex or otherwise) that you might have, but please keep in mind that the most effective way to get definitive answers will be to address the Design system's steering committee directly (by using the Slack channel linked above, or posting on Phabricator).

Hey there! I took a quick look at the changes related to this task (I didn't try out all attribute combos alternating selection order, nor tested in different browsers, but...): things look great!

Hey there! I think that the flow described in the ticket is already very good. Sharing some suggestions and alternatives for consideration:

Decision
The WE5.2.1 hypothesis team decided that the redesigned REST API Sandbox/Reference will be hosted on-wiki. Particularly as Special: pages in individual wiki instances.
We agreed to move forward with this as our initial decision for hosting: it may be revisited as part of longer-term documentation unification work.

The discovery phase concluded the past quarter. Linking all relevant deliverables:

I think it might make the most sense to decline this task, so to not add to the backlog unnecessarily. If this becomes a user problem in the future, or something we want to explore in the future, we can reopen the task. Is that okay with you?

Hi Derek! Sorry for the late reply. I brought this topic up during Design review with group C a couple of weeks ago. To summarize the outcome of our discussion: although the team agreed that the lack of distinction between filled and empty error fields is an issue and their first inkling was to think of potential solutions, they also considered that the status quo is acceptable (basically due to the factors that you pointed out: the existence of clarifying messages, and the fact that potential confusion is only temporary, as it dissipates when users focus on the input). All-in-all, looks like the problem remains only as a 'nice to solve'.

This task's parent Epic was resolved coinciding with the conclusion of hypothesis SDS2.4.13 at the end of FY24-25. This pending subtask can be considered foundational/essential work now, and until w decide whether it should be housed under a particular KR.

This task's parent Epic was resolved coinciding with the conclusion of hypothesis SDS2.4.13 at the end of FY24-25. This pending subtask can be considered foundational/essential work now, and until w decide whether it should be housed under a particular KR.

This task's parent Epic was resolved coinciding with the conclusion of hypothesis SDS2.4.13 at the end of FY24-25. This pending subtask can be considered foundational/essential work now, and until w decide whether it should be housed under a particular KR.

This task's parent Epic was resolved coinciding with the conclusion of hypothesis SDS2.4.13 at the end of FY24-25. This pending subtask can be considered foundational/essential work now, and until we may decide whether it should be housed under a particular KR.

This task's parent Epic was resolved coinciding with the conclusion of hypothesis SDS2.4.13 at the end of FY24-25. This pending subtask can be considered foundational/essential work now, and until we may decide whether it should be housed under a particular KR.

The hypothesis SDS2.4.13 had to be closed yesterday, coinciding with the end of FY24-25 (See final report). All pending subtasks (mostly outstanding improvements) can be considered foundational/essential work until we decide whether they should be housed under a particular KR:

In T394527#10958999, @mpopov wrote:

could be helpful to validate that the set-up is working

This would have to be validated in staging (mpic-next), right? If both production and staging refer to the same source of truth for which experiments are registered for analysis, we can just configure some experiments for different conditions.

Thanks so much for your comments, @mpopov ! I really appreciate your review 🙏🏻

Hey there, @Sfaci and @cjming! I'd say this is the most substantial pending task under SDS2.4.13. The hypothesis is off track, and I’m currently trying to assess how much time we’ll need to wrap it up. Could you share your thoughts on the current status and, if possible, provide an estimate of the time required to complete it? Thank you so much!

Are there any news on this task? I'm wondering whether we should exclude this effort from SDS2.4.13's scope. We're at the end of the current FY, and this would block wrapping up that hypothesis in the next few weeks (we're already off-track).

Are there any news on this task? I'm wondering whether we should exclude this effort from SDS2.4.13's scope. We're at the end of the current FY, and this would block wrapping up that hypothesis in the next few weeks (we're already off-track).

Design exploration

Thanks, @Sfaci! T397824: xLab: Improve form validation was updated to include the issue. Let us know if it sounds good, @EChukwukere-WMF! We'd move this task to done with your permission.

In T397510#10948376, @EChukwukere-WMF wrote:

Test status: QA FAIL

When the fields throw validations, without making an entry update ( and before clicking the submit button ) clicking outside the field removes the validation for some fields and in others the validation stays persistent till an entry is made into the field ( This is how it should work) .

Thanks for the thoughtful explanation, @DTorsani-WMF! I see where you're coming from and appreciate the rationale behind prioritizing accessible error messaging over visual differentiation between empty and invalid inputs.

This works well! Thank you, @Sfaci 🙌🏻 No critical issues were found at this time, and this can be considered done from a design perspective 👍🏻

Looking great! Thanks for the last fix, @Sfaci 💯

Thanks once again for the excellent work on this task, @Sfaci! I think we're good to go with this version of the validation implementation. There are a couple of outstanding issues (I documented them in the following task: T397824: xLab: Improve form validation), but their criticality isn't high. I'd say it's fine to go ahead and consider this task done 🤝