What is it?
The Wikimedia Foundation Design Systems Team is a small team with limited resources that has been tasked with creating a centralized design system for Wikimedia, building modern tools for designing and developing UIs, and implementing major infrastructure changes to enable use of these modern tools. In order to succeed, we need to encourage adoption of these new systems, invite others to contribute to building them, and understand our stakeholders' needs.
Since our stakeholders represent a wide breadth of roles, experience levels, goals, and needs, we should develop standard processes for communicating with various stakeholders for different purposes.
Impact
End-user impact
- The more people can use our modern tools to build features, the more our end users will benefit from consistent, cohesive design and reliable, accessible, modern interfaces
- The more people who are newly enabled to build features, the more great features will exist for our end users
Codex-user impact
- Those who want to use Codex but are currently blocked for various reasons will get a clear understanding of what they can do, when, and how
- Those unfamiliar with Codex will learn about our work and become enabled to adopt it
Other impact
- We have long encountered confusion over what we're doing, when we're doing it, and how it will affect our stakeholders. Creating these processes will outline exactly how we can communicate better and more often, reducing that confusion.
- Better communication with stakeholders will give us a more accurate understanding of what they need and, therefore, what we should prioritize
What does it block?
- Most WMF teams are not using Codex for a wide variety of reasons, like:
- They need unfinished infrastructure in place first (design tokens, SSR, access to Figma components outside WMF, etc.)
- They need components that no one has designed and/or built yet
- They haven't used Codex or Vue yet and need training or onboarding
- They don't know much about Codex yet
- They haven't set aside time to adopt Codex/Vue
- We haven't discussed our work with volunteers much outside of some discussion in Phabricator, so many volunteer developers probably aren't aware of what we're building or how it affects them
Phases of work and owners
- Phase 1a: Standardize processes for collaboration on Codex
- Owner: DST
- To do:
- Develop brief processes for communication during collaborations. Review past collaborations, what went well, what could be better, etc. We will need a range from minor changes that will just require answering questions and code review, to larger projects that will require planning, check-ins, and more. (see T323336)
- Test this process on upcoming collaborations
- Phase 1b: Develop a process for interfacing with other teams to collect feedback about their blockers to Codex adoption, focusing on teams already using Vue
- Owner: DST
- To do:
- Write up a process for these interactions (see T323337)
- Meet with initial teams (Growth and Language?)
- Phase 2a: Develop a process for interfacing with other teams to collect feedback about their blockers to Codex adoption, focusing on other teams
- Owner: DST
- To do:
- Write up a process for these interactions, based on the outcomes from Phase 1b (see T323337)
- Meet with relevant product and tech teams
- Phase 2b: Develop a process for communicating with the volunteer community, inviting adoption of and contribution to Codex
- Owner: DST
- To do:
- Determine how to communicate the current status of Codex, plans for further work, and how the community can use it or get involved (e.g. regular "newsletter" updates, office hours, event sessions, etc)
- Ensure we're clarifying ways that volunteers can provide feedback on our work, both in terms of changes/additions they want to see and blockers they're facing
Cross-team dependencies
This completely depends on other teams, and those outside WMF! We will need to keep in mind the different needs of different stakeholders to cater our communication to them.
Existing Artifacts
- Open Questions