Almost deployed. Just need to do the data migration and will try to deploy again today.

We can separate PRDs for WDQS and WCQS.

Reviewing user requirements and problem statements with Lydia and Shari

As per https://phabricator.wikimedia.org/T313565 we will refine the scope of this ticket to reflect next steps for TDMP process and scope.

August 16, 2022

• Notes:
  • Reviewed the one pager: https://docs.google.com/document/d/1yfhI2pgqdPAfp8XVyfVEfkq-uGx2Ovqu7TOTeMvmSYM/edit#
  • Are there existing precedents for SSR?
    • Yes, wikidata implemented this and it was mostly done by front-end teams. Will dig deeper into this.
      • If we implement within WMF, we'd likely need a matrixed team with a variety of skill sets. We could perhaps relate this to containerization work in Kubernetes as well
      • We would need to define when and how to use SSR. For example don't use for skins or minimal interactivity interfaces. Do use for high interactivity use cases
  • Figuring out what alternatives to SSR will take several months so important to begin having conversations now so when we need to action we can. This means we will NOT focus on implementation but instead focus on getting through TDMP to explore problem, drivers, and alternatives.
• Identifying what drives this work should also be important. Are we doing for equity of experience (ex: non-js users) or for performance reasons?

product sign-off completed

Adding as a future scoping ticket that we may want to look at in 2 months or so. Linked to https://phabricator.wikimedia.org/T314082

We have started with this work as of August 5, 2022.

As a note scoping tickets should not be actioned directly

Design signed off. Looks like we need QTE sign-off?

Product sign-off complete

Product sign-off complete

Approving for access

August 4, 2022 Update

• created miro board for user story mapping
• did initial review with working group
• Next Steps:
  • team to asynchronously add missing user stories
  • team to asynchronously comment on user stories with thoughts, suggestions, insights, etc.
  • meet with working group to start mapping user stories to document types, followed by outlining specific document needs and existing content

Planning next steps

All good. Product sign-off complete.

All good. Product sign-off complete.

All good. Product sign-off complete.

@AnneT the scope of this ticket would include documenting the steps, workflows, and processes in relation to anyone trying to extend or contribute to components. In addition to code review there are a few other areas that could be added to this scope.

• Risk Assessments:
  • As a system meant to be widely used by everyone, are certain types of contributions more risky than others? If so, do we handle in different ways?
  • Are there clear criteria to evaluate risk against from the code perspective?
  • What is the risk escalation process (aka notify tech lead, EM, DST, etc)
  • Do we ever lock-down particular components because of the risk level?
• Code Review:
  • who performs reviews & when? Should a DST engineer always review or is it okay to have others code review?
  • how do we capture outcomes from reviews? How would we prioritize or resolve conflicts?
  • role of DST vs other product feature teams
  • how do we use gerrit rating system
• How to contribute to the Design System without using codex:
  • Tips on how to leverage existing components in codex, without actually using codex
  • Tips on how to align non-codex components with the Design System as much as possible

August 3, 2022

• status is traffic team not yet done with experiment to see feasibility of ESI solution
• originally hoping to do in Q4, still need to complete
• Next step: engage with FR-tech on more real-world experiment

@AnneT Some additional thoughts:

• For Document the various pathways to code contribution section:
  • Perhaps we add these notes to https://phabricator.wikimedia.org/T313940. I think this is probably deserving of its own task and we can either refine the requirements there or spin out additional sub-tasks as needed.
    • Could we also outline what we already have from these recommendations on that ticket?

Thanks @AnneT for the update. It seems like we could prioritize Removing demo requirements", since we've already started to action some of this work via maybe try to close out some of the demo site related work "Removing demo requirements" via https://phabricator.wikimedia.org/T311243. Would the only remaining task to add be that we need to spin out a sub-task related to updated demo requirements documentation?

This work has been completed by the API Platform team. See sub-task for more information.

Working on prioritization for API Platform stream.

Start with a small brainstorming session that includes historical context:

• Anne, Volker, Sarai
• workshop activity

Can we please update with the status of this task and next steps?

We will likely need to look at this through the lens of different use cases and audiences. For example

• Front-End development - engineers
• Design - designers
• General info - community + anyone interested

I'm also noticing a bunch of 404 error codes on certain component pages. The only components I don't get 404 codes on are for Button and Card.

Looks great! Before I sign off quick question: does it make sense to simply replace the Codex doc section with a link to Figma and simply add a description of the token?

Can we please have an update on this task status please? Is it still "in progress" or "in development"?

Prioritizing for upcoming sprint

Adding this to backlog to be picked up after we complete token work outlined in https://phabricator.wikimedia.org/T295991

Another inconsistency in the components section is that we don't include an "Overview" section of what the components. Just as we have this for "design tokens" it would be great to add this in the components section.

In T313917#8110417, @Catrope wrote:

For existing components, we have the documentation pages on the Codex docs site, which are partially automatically generated from documentation comments in the code, and partially hand-written with examples. See https://doc.wikimedia.org/codex/main/components/message.html and the other entries in the navigation sidebar under "Components".