Change Details

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? Versioning, contribution policy, etc. We have already had many of these conversations in relation to WVUI; some/most of that work may apply here too. **Considerations** * **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 ]] ** We should also consider how to 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 we use as the canonical, shared component library? 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? 4. What are the library's design principles, and where will they be documented?

## 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 #### 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 carry over lessons learned and actual code from existing libraries when creating new work in WVUI. * Identifying other aspects of existing libraries that could be incorporated into WVUI (e.g. documentation) #### 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? #### 4. What are the library's design principles, and where will they be documented? .

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? Versioning, contribution policy, etc. We have already had many of these conversations in relation to WVUI; some/most of that work may apply here too.## Summary **Considerations** * **Contribution policy:** *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 #### 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 ]] ** We should also consider how to* How will we facilitate contributions from those outside the Design Systems team: what? 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 **Relevant links** * T272885: list of Vue projects and components in the wiki-verse (may be somewhat outdated; please update it as needed) **--- ## Decisions** 1 #### 1. Which codebase, existing or new, will we use asserve 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: 2.* Updating existing technology as needed (e.g. moving to Vue 3, switching to a new build tool, How will the Demploying new design Systems team roll out releases and version those releases?token architecture) 3. What is the contribution policy for changes and new components?* 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 carry over lessons learned and actual code from existing libraries when creating new work in WVUI. * Identifying other aspects of existing libraries that could be incorporated into WVUI (e.g. documentation) #### 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? #### 4. What are the library's design principles, and where will they be documented? .