The fact that a component already exists in previous libraries (WVUI, WiKit or OOUI) or is documented in the Design Style Guide shouldn't be interpreted as a green light for implementation by Codex code contributors.
We should update the "Component addition process" in the "[[ https://doc.wikimedia.org/codex/main/contributing/contributing-code.html#task-tracking | Code contribution workflow ]]" section to indicate the following (consider this a rough draft):
> **1. Create a new component task in Phabricator**
> New Codex components should have a corresponding task in Phabricator. You can reuse [[ https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?title=Design%E2%80%A6&description=%3D%3D%20Background%2FGoal%0D%0A%0D%0ADesign%E2%80%A6%0D%0A%0D%0A%3D%3D%3D%20User%20stories%0D%0A%0D%0AAs%20a%20designer%2C%20I%E2%80%A6%0D%0A%0D%0A%3D%3D%3D%20Considerations%0D%0A%0D%0A%3D%3D%3D%3D%20Development%20considerations%0D%0A%0D%0A%3D%3D%3D%20Acceptance%20criteria%20(or%20Done)%0D%0A%0D%0A%5B%5D%20&projects=codex%2C%20design-systems-team-fy2021-22-kanban&subscribers=Volker_E%2C%20bmartinezcalvo | this template ]] to create a component task in case it's missing.
> New component, bug or component improvement tickets should be added to the 'Needs Triage (Incoming Requests)' column in the [[ https://phabricator.wikimedia.org/tag/design-systems-team/ | Codex Phabricator Workboard ]].
>
> **2. Gather relevant design artifacts**
> Before a component can be implemented in Codex, it should be fully specified in the [[ https://www.figma.com/file/2Jb1lVkhEMDFxO20I5xwyA/%E2%9D%96-WikimediaUI-%E2%80%93-Components | WikimediaUI - Components ]] Figma file or in its corresponding exploration file in Figma.
> In any case, any task involving visual or interacction changes can be considered ready for implementation only once design specifications have been provided in the relevant Phabricator ticket. Until then, the ticket should remain in the 'Needs design' column in the [[ https://phabricator.wikimedia.org/tag/design-systems-team/ | Codex Phabricator Workboard ]].
>
> **3. Build the component**
> Once design specifications have been shared, and the task has been refined by the members of the Design Systems Team, the ticket will be moved to the 'Design Systems Backlog' column in the [[ https://phabricator.wikimedia.org/tag/design-systems-team/ | Codex Phabricator Workboard ]], indicating that implementation work can be initiated. You might assign the task to yourself and move it to the 'In Development' column in the [[ https://phabricator.wikimedia.org/project/view/5859/ | Design Systems Sprint Workboard ]].
> Create the Vue component, apply the necessary design tokens following the design specifications (See [[ https://doc.wikimedia.org/codex/main/contributing/contributing-code.html#writing-styles | Writing styles ]] below for details) and write unit tests.
>
> **5. Demo the component**
> Create component demos in VitePress following the existing examples and the potential specifications provided in the task.
>
> **6. Open a patch for review**
> Patches will be reviewed by developers, UX engineers, and designers.
> In order to communicate that a review is needed, the component ticket should be added to either the 'Code Review' or the 'Design Sign-Off' column in the [[ https://phabricator.wikimedia.org/project/view/5859/ | Design Systems Sprint Workboard ]] in Phabricator. The Design Systems Team will provide feedback in Gerrit and/or Phabricator, and move the component task to the right column in case further design or implementation work are needed to finalise the component before its release.
>
=== Questions
1. Regarding section '//5. Demo the component//': We might need to add more guidance. How might contributors know what the component demo page should look like? Should the structure of the demo page be specified in the component task? Or should we ask contributors to check how similar components are demoed and to reproduce existing structures?