## Summary
Should we officially "adopt" one of the existing component codebases (WVUI, WiKit, etc.) or start a new repository? What kind of policies around governance should we adopt for contributing, versioning, and more? We have already had many of these conversations in relation to WVUI; some/most of that work may apply here too.
## Considerations
#### Existing component libraries in the Wiki-verse
- **WiKit**: Wikimedia Deutschland's component library ([[ https://wmde.github.io/wikit/?path=/story/documentation-getting-started--page | Storybook ]])
- **WVUI**: Wikimedia Foundation's experimental shared library ([[ https://doc.wikimedia.org/wvui/master/ui/?path=/story/components-button--configurable | Storybook ]]). First developed by the Web team during the [[ https://phabricator.wikimedia.org/T255902 | Vue.js search experience project ]], now maintained by the Design Systems team
- **WMF team-specific libraries**: Language's [[ https://github.com/wikimedia/mediawiki-extensions-ContentTranslation/tree/master/app/src/lib/mediawiki.ui | MediaWikiUI ]], Structured Data's [[ https://github.com/wikimedia/mediawiki-extensions-MediaSearch/tree/master/resources/components/base | MediaSearch library ]]
- And more: see T272885 for a more comprehensive list
#### Some notes on recent WVUI work
The Design Systems team spent Q4 of FY 2020-2021 building new components in WVUI and thinking through library architecture, developer experience (DX), contributing guidelines and governance, and more. The goal of this experimentation was to help us come to a recommendation for a path toward a Vue component library that could be shared by the Wikimedia Foundation and Wikimedia Deutschland.
During this time, we maintained these priorities:
- Adhere to the [[ https://design.wikimedia.org/style-guide/index.html | Design Style Guide ]] (and Figma designs, if available). If we need to add a component that's not yet in the DSG, match OOUI design and accessibility standards
- Aim to offer similar functionality as OOUI, both to provide end users with all the tools they'll need to migrate their UIs to Vue, and to minimize cognitive overload of migrating from OOUI to WVUI. Exceptions: simplifying things if possible, use Vue tools when available (e.g. `v-model`), rethinking component architecture in terms of composition (versus the inheritance model in OOUI)
- For each component or set of components, create a task ([[ https://phabricator.wikimedia.org/T279714 | example ]]) that outlines:
- Existing versions of the component in the Wiki-verse
- Existing versions of the component in third-party libraries
- Existing design standards and resources for the component
- Possible implementations and their pros and cons
- Discussion, in comments, of what we think is the ideal implementation in terms of reusing existing work, following Wikimedia design standards, maintaining accessibility standards and other solved-problems from OOUI, DX for the library end user, maintainability of code and DX for developers of the library, and establishing/following patterns in the library itself
As a result of this process, we gained the following:
- A better understanding of how we can build and maintain a shared component library that will be useful to developer end-users, maintainable and scalable, collaboratively built, and adherent to Wikimedia design
- A process for thoroughly reviewing existing Vue work in the Wiki-verse to gain understanding of different potential implementations, re-use existing code whenever possible, and carry over lessons learned from developers who have been building with Vue within our ecosystems for a while now
#### Contribution policy
* WiKit and WVUI have some existing documentation about how to contribute:
** WiKit: [[ https://wmde.github.io/wikit/?path=/story/documentation-contributing--page | Contributing ]], [[ https://wmde.github.io/wikit/?path=/story/documentation-how-to-modify-existing-components--page | modifying existing components ]], [[ https://wmde.github.io/wikit/?path=/story/documentation-how-to-create-reusable-components-overview--page | creating reusable components ]]
** WVUI: [[ https://github.com/wikimedia/wvui/blob/master/CONTRIBUTING.md | contributing ]]
* How will we facilitate contributions from those outside the Design Systems team? What base work should be prioritized to enable more effective contributions, like getting the design token architecture implemented? What will the process be for teams that need a component that doesn't exist yet in the shared library?
#### Relevant links
* T272885: list of Vue projects and components in the wiki-verse (may be somewhat outdated; please update it as needed)
---
## Decisions
#### 1. Which codebase, existing or new, will serve the canonical, shared component library?
**Design Systems Team Proposal**: Transition WVUI from an experiment to the canonical shared library, or start a new library for this purpose. This would include:
* Updating existing technology as needed (e.g. moving to Vue 3, switching to a new build tool, employing new design token architecture)
* Welcoming feedback on existing WVUI code
* Continuing to methodically and closely review existing work when adding new code to WVUI. Our process includes documenting existing implementations in the wiki-verse and in third-party libraries, debating the merits of each implementation, then determining the ideal approach for our use case., We often carrying over lessons learned and actual code from that existing libraries when creating new work in WVUI. work (see notes above for more details on this process)
* Identifying other aspects of existing libraries that could be incorporated into WVUI (e.g. WiKit has excellent and extensive documentationn that displays in Storybook)
#### 2. How will the Design Systems team roll out releases and version those releases?
#### 3. What is the contribution policy for changes and new components?
**Design Systems Team Proposal:** Follow the governance model developed by WMF + WMDE designers (see T287535), and continue to document tech-specific contribution policy info in the shared component library.
#### 4. What are the library's design principles, and where will they be documented?
####