Change Details

DST wants to connect with WMF teams who do work on the front end to understand when and how they could adopt Codex. ## Adoption spectrum We see teams being somewhere on the following spectrum of Codex adoption: 1. **Information phase**. Teams in this phase have not started using Codex (or possibly Vue.js) and need information about what we're doing, when we're doing it, and how they could get onboarded to Codex. They may not know exactly what's blocking their adoption of Codex or when they would prioritize doing so. 2. **Adoption phase**. Teams in this phase have started using Codex or want to do so very soon. They likely know some of the things blocking them and have specific needs. 3. **Collaboration phase**. Teams in this phase have not only started using Codex, they're also contributing to it. They have a deep understanding of Codex and are actively supporting its development. In order to serve all teams and eventually level them up to the collaboration phase, we should develop different processes to support the three phases. --- ## Process (to do. here are some notes...) - Consider how to provide info that will enable teams to identify blockers - Ask what teams need in terms of support: trainings, sample projects, docs... - Who to contact for each team: PM, tech lead, and designer? - Clarify what DST can/can't do, and that adoption will likely necessitate contribution at some point - Make a list of teams to contact (not just product)

DST wants to connect with WMF teams who do work on the front end to understand when and how they could adopt Codex. ## Adoption spectrum We see teams as being somewhere on the following spectrum of Codex adoption: 1. **Information phase**. Teams in this phase have not started using Codex (or possibly Vue.js) and need information about what we're doing, when we're doing it, and how they could get onboarded to Codex. They may not know exactly what's blocking their adoption of Codex or when they would prioritize doing so. 2. **Adoption phase**. Teams in this phase have started using Codex or have a general plan for doing so in the future. They likely know some of the things blocking them and have specific needs. 3. **Collaboration phase**. Teams in this phase have not only started using Codex, they're also contributing to it. They have a deep understanding of Codex and are actively supporting its development. In order to serve all teams and eventually level them up to the collaboration phase, we should develop different processes to support the three phases. --- ## Process ### 1. Introduce Codex + Vue.js via the roadshow For teams in the information phase (and potentially in the adoption phase), we need to start by introducing our work to enable these teams to understand how they can use the design system and what it would mean to start using Vue.js. Once the teams are informed of the basics, they will be better equipped to tell us what they need to adopt Codex. This step will be completed via the DST roadshow (see T317360). That task will cover both synchronous and asynchronous methods for providing teams with the information they need to start thinking about onboarding with Codex. Once teams complete this step, they will move into the adoption phase. ### 2. Meet with each team to discuss Codex adoption For teams in the adoption phase, we will hold a synchronous meeting to discuss general plans for adopting Codex and anything blocking the team from doing so. This will enable the DST to provide support and prioritize work that will ease adoption. We should meet with all product teams and relevant tech teams (see Desiree's [[ https://phabricator.wikimedia.org/T323337#8409869 | comment ]] for a list of tech teams). Draft list of teams to meet with: - Anti-harassment tools - Campaigns - Community tech - Editing (?) - Fundraising tech (?) - Inuka - Structured data - Trust and safety tools - Web (?) - WMDE (?) - API platform - Analytics platform - Technical engagement (toolhub) #### Process - **Schedule meeting.** - Rep from DST schedules a 30 minute meeting with the Product Manager (or similar), Designer, and Tech Lead - At time of scheduling, DST rep includes a meeting description with a list of links to resources and some topics for the team to think about beforehand if possible - **Hold meeting.** Goals: - Help the team understand what to expect when starting to use Codex, including: - New processes/tools for design (resources: ??) - Onboarding to Vue.js (resources: Vue 3 docs, access to Vue Mastery trainings) - Starting to use Codex Vue components, design tokens, and icons (resources: Codex docs, docs on using Codex in MediaWiki, sample projects) - Evaluating performance concerns (when to load Vue.js, supporting no-JS and slower connections) - Ask the team what they view as blockers to Codex adoption - Record responses so we can aggregate them across teams - Ask about what specific resources the team wants - Ask the team if they have a general plan for Codex adoption - E.g. a timeline or specific project - If they don't, ask them to consider this and get back to DST rep asynchronously - Inform the team of DST's role in providing support - Explain prioritization and general timeline of in-progress and future design, Codex, and infrastructure work - Explain hybrid model and that contributions to Codex may be necessary (and are welcomed) - Provide info on how the team can contact the DST for various needs ### 3. Evaluate feedback from meetings After the meetings are held, we will aggregate information about blockers to Codex adoption and review it as a team so we can prioritize work that will unblock adoption. --- ## To do [] Review the process with the DST, update, and finalize [] Track team meetings and evaluating feedback in Phabricator

DST wants to connect with WMF teams who do work on the front end to understand when and how they could adopt Codex. ## Adoption spectrum We see teams as being somewhere on the following spectrum of Codex adoption: 1. **Information phase**. Teams in this phase have not started using Codex (or possibly Vue.js) and need information about what we're doing, when we're doing it, and how they could get onboarded to Codex. They may not know exactly what's blocking their adoption of Codex or when they would prioritize doing so. 2. **Adoption phase**. Teams in this phase have started using Codex or want to do so very soonhave a general plan for doing so in the future. They likely know some of the things blocking them and have specific needs. 3. **Collaboration phase**. Teams in this phase have not only started using Codex, they're also contributing to it. They have a deep understanding of Codex and are actively supporting its development. In order to serve all teams and eventually level them up to the collaboration phase, we should develop different processes to support the three phases. --- ## Process (to do### 1. Introduce Codex + Vue.js via the roadshow For teams in the information phase (and potentially in the adoption phase), we need to start by introducing our work to enable these teams to understand how they can use the design system and what it would mean to start using Vue.js. Once the teams are informed of the basics, they will be better equipped to tell us what they need to adopt Codex. This step will be completed via the DST roadshow (see T317360). That task will cover both synchronous and asynchronous methods for providing teams with the information they need to start thinking about onboarding with Codex. Once teams complete this step, they will move into the adoption phase. ### 2. Meet with each team to discuss Codex adoption For teams in the adoption phase, we will hold a synchronous meeting to discuss general plans for adopting Codex and anything blocking the team from doing so. This will enable the DST to provide support and prioritize work that will ease adoption. here are some notes...We should meet with all product teams and relevant tech teams (see Desiree's [[ https://phabricator.wikimedia.org/T323337#8409869 | comment ]] for a list of tech teams). Draft list of teams to meet with: - Anti-harassment tools - Campaigns - Community tech - Editing (?) - Fundraising tech (?) - Inuka - Structured data - Trust and safety tools - Web (?) - WMDE (?) - API platform - Analytics platform - Technical engagement (toolhub) #### Process - **Schedule meeting.** - Consider how to provide info that will enable teams to identify blockers - Rep from DST schedules a 30 minute meeting with the Product Manager (or similar), Designer, and Tech Lead - Ask what teams need in terms - At time of support: trainings, sample projectscheduling, docs...DST rep includes a meeting description with a list of links to resources and some topics for the team to think about beforehand if possible - Who to contact for each team: PM**Hold meeting.** Goals: - Help the team understand what to expect when starting to use Codex, including: - New processes/tools for design (resources: ??) - Onboarding to Vue.js (resources: Vue 3 docs, access to Vue Mastery trainings) - Starting to use Codex Vue components, design tokens, and icons (resources: Codex docs, docs on using Codex in MediaWiki, sample projects) - Evaluating performance concerns (when to load Vue.js, supporting no-JS and slower connections) - Ask the team what they view as blockers to Codex adoption - Record responses so we can aggregate them across teams - Ask about what specific resources the team wants - Ask the team if they have a general plan for Codex adoption - E.g. a timeline or specific project - If they don't, ask them to consider this and get back to DST rep asynchronously - Inform the team of DST's role in providing support - Explain prioritization and general timeline of in-progress and future design, Codex, and infrastructure work - Explain hybrid model and that contributions to Codex may be necessary (and are welcomed) - Provide info on how the team can contact the DST for various needs ### 3. Evaluate feedback from meetings After the meetings are held, we will aggregate information about blockers to Codex adoption and review it as a team so we can prioritize work that will unblock adoption. --- ## To do [] Review the process with the DST, tech leadupdate, and designer?finalize - Clarify what DST can/can't do,[] Track team meetings and that adoption will likely necessitate contribution at some pointevaluating feedback in Phabricator - Make a list of teams to contact (not just product)