Change Details

### Overview We need a documented process to follow when migrating Wikimedia Foundation projects to Vue. We should list out the necessary aspects of the migration plan, including potential pitfalls and contingencies, discuss them all here, then document the process on-wiki, where it can be viewed by all and maintained/updated as we get into the migration phase. Parts of the process will be universal, while others will vary based on the project and the product team. ### Details #### What potential pitfalls, delays, or exceptions might arise? This list is meant to capture as many potential problems as we can identify, so the risk they introduce can be mitigated in the plan if possible. - Introduction of production bugs/regressions - Introduction of performance issues, or lack of performance metrics altogether - Deployment is more complicated than anticipated, or risky - Delays: original estimate of work was wrong, urgent bugs in other projects arise, train delays, vacations... - For some projects, a 1:1 migration may not be ideal (e.g. older projects that are in dire need of improvements, or that were held back by technological limitations at the time of their development), and a full rebuild may be better or necessary. This would take longer and more heavily involve design and product management. - For some projects, migration may not be an ideal use of time (e.g. older, rarely used projects that may be better off decommissioned) #### What should the process cover? 1. **Training:** What training will be provided to product teams pre-migration? When will it be provided, and how long will the team members have to review it? 1. **App planning:** How will the Design Systems team collaborate with the project team to plan out the app's architecture? How will the plan be documented (e.g. in a series of Phab tickets created by the product manager or tech lead?) 1. **Timeline:** How will a per-project timeline be determined and documented? 1. This should probably include a plan for maintenance post-migration, and a contingency plan for an extended timeline due to delays 1. **Personnel and roles:** Who will be working on the project, and what roles will they fulfill? 1. **Communication plan:** How will the Design Systems team and product team work together? 1. Slack: temporarily invite Design Systems team liaison(s) to the product team slack? Create a new channel to give product teams access to the Design Systems team directly? 1. Code review: how will product team members alert Design Systems team members that code is ready for review? 1. **QTE integration:** Which QTE team member(s) will be involved, and how will their work be integrated into the process? 1. **Project setup**: How will those working on the project for the first time set it up for local development and/or review? How will we account for the time it may take to get the project sufficiently set up locally? 1. Note that this might only apply to the liaison(s) from the Design Systems team, but it could also apply to older projects that product team members haven't worked with for a while or ever. 1. **Post-migration review:** How can product team members give us feedback on their experience, especially satisfaction metrics related to OKRs and recommendations for improvements? 1. **Technical specifications:** How will these decisions be made and documented? (See below for a full list) #### What technical specifications must be determined pre-migration? 1. **Development strategy:** What strategy will be used during development of the project to maintain a new Vue-ified version of the feature code without disrupting the production code? 1. **QTE review and staging:** How will the new Vue version be reviewed by QTE? Will there be any kind of staging environment? What about projects where any existing staging environments don't sufficiently mimic production? 1. **Deployment:** How will the new Vue version be deployed? 1. **Testing**: What unit, regression, or other testing will be completed? Should a baseline level of testing be required, or are there situations where a lack of tests is justified? 1. **Code conventions:** What coding standards or Vue style guide alignment will be required? 1. **Vuex**: Will the project require Vuex? 1. **Vue version**: If the project is built with Vue 2, how can we minimize the amount of work that will be needed to eventually migrate it to Vue 3? When will that migration happen, and who will do it?

The Design Systems Team should develop and document a migration process that can be used as a starting point for any migration of an existing product or feature to Vue. Documentation should probably live on-wiki somewhere.### Overview Individual projects will inevitably varyWe need a documented process to follow when migrating Wikimedia Foundation projects to Vue. We should list out the necessary aspects of the migration plan, including potential pitfalls and contingencies, discuss them all here, then document the process on-wiki, where it can be viewed by all and maintained/updated as we get into the migration phase. Parts of the process will be universal, but having a consistent proceswhile others will help us to move fastervary based on the project and to better measure outcomesthe product team. ### Details #### What potential pitfalls, delays, or exceptions might arise? This list is meant to capture as many potential problems as we can identify, so the risk they introduce can be mitigated in the plan if possible. - Introduction of production bugs/regressions - Introduction of performance issues, or lack of performance metrics altogether - Deployment is more complicated than anticipated, or risky - Delays: original estimate of work was wrong, urgent bugs in other projects arise, train delays, vacations... - For some projects, a 1:1 migration may not be ideal (e.g. older projects that are in dire need of improvements, or that were held back by technological limitations at the time of their development), and a full rebuild may be better or necessary. This would take longer and more heavily involve design and product management. - For some projects, migration may not be an ideal use of time (e.g. older, rarely used projects that may be better off decommissioned) #### What should the process cover? 1. **Training:** What training will be provided to product teams pre-migration? When will it be provided, and how long will the team members have to review it? 1. **App planning:** How will the Design Systems team collaborate with the project team to plan out the app's architecture? How will the plan be documented (e.g. in a series of Phab tickets created by the product manager or tech lead?) 1. **Timeline:** How will a per-project timeline be determined and documented? 1. This should probably include a plan for maintenance post-migration, and a contingency plan for an extended timeline due to delays 1. **Personnel and roles:** Who will be working on the project, and what roles will they fulfill? 1. **Communication plan:** How will the Design Systems team and product team work together? 1. Slack: temporarily invite Design Systems team liaison(s) to the product team slack? Create a new channel to give product teams access to the Design Systems team directly? 1. Code review: how will product team members alert Design Systems team members that code is ready for review? 1. **QTE integration:** Which QTE team member(s) will be involved, and how will their work be integrated into the process? 1. **Project setup**: How will those working on the project for the first time set it up for local development and/or review? How will we account for the time it may take to get the project sufficiently set up locally? 1. Note that this might only apply to the liaison(s) from the Design Systems team, but it could also apply to older projects that product team members haven't worked with for a while or ever. 1. **Post-migration review:** How can product team members give us feedback on their experience, especially satisfaction metrics related to OKRs and recommendations for improvements? 1. **Technical specifications:** How will these decisions be made and documented? (See below for a full list) #### What technical specifications must be determined pre-migration? 1. **Development strategy:** What strategy will be used during development of the project to maintain a new Vue-ified version of the feature code without disrupting the production code? 1. **QTE review and staging:** How will the new Vue version be reviewed by QTE? Will there be any kind of staging environment? What about projects where any existing staging environments don't sufficiently mimic production? 1. **Deployment:** How will the new Vue version be deployed? 1. **Testing**: What unit, regression, or other testing will be completed? Should a baseline level of testing be required, or are there situations where a lack of tests is justified? 1. **Code conventions:** What coding standards or Vue style guide alignment will be required? 1. **Vuex**: Will the project require Vuex? 1. **Vue version**: If the project is built with Vue 2, how can we minimize the amount of work that will be needed to eventually migrate it to Vue 3? When will that migration happen, and who will do it?