Definition of Done

TEDI-Ready Components

Design

• Component is designed using best practices:
  • Relies on TEDI variables (spacing, padding, colors, sizes etc) and styles (shadows, typography)
    • Create semantic variables if needed
  • Different variants are created according to the needs
  • Has dark theme
  • Has passed WCAG AA test in Figma
  • Is tested by another designer - design review: short texts, long texts, property naming etc - usability of the component for designers
  • Is responsive or adaptive, is tested on small and large device - if needed mobile version is created
  • Is technically up to date according to new Figma features
• Component has following statuses:
  • Status badges if its design, React component or/and Angular component is ready - on top of the frame: ✓ Figma, ✓ React, ✓ Angular
  • Informative badges (frame header):
    • If it's detachable (optional) - meaning you can detach the component and adjust it using variables
    • If it's tested against WCAG AA level
    • If it's documented
  • Ready for dev (built in Figma status) - if it's not yet developed in both React and Angular
  • Variant level status properties ("//Angular dev: done/not done" and "//React dev: done/not done") - statuses are removed after the component variant is developed in both
• Component has a Documentation section - includes links to Storybook (React and/or Angular) and Zeroheight
• Component has a Tips and Tricks section - instruction section which includes extra notes if there's something design specific other designers should know
• Component is published:
  • In Figma file - library publish for the TEDI-Ready Figma file, add correct notes what was changed
  • Figma version is updated - Figma version update according to the rules
  • Figma version is saved manually to file history - Add version and notes what changed
  • Figma version is published to the Figma community - Change version number manually, it does not change automatically
  • Add link that refers to the component to Figma table of contents
  • Close design task in Github
  • Create dev tasks about the component to Github kanban board (both React and Angular)
  • Add changes to release notes draft in Zeroheight - release notes is published once a month
  • Clean component from comments (optional)
  • Add component specific release notes time and notes to the footer of the frame in Figma
  • Update statuses page in Zeroheight

Figma: https://www.figma.com/design/jWiRIXhHRxwVdMSimKX2FF/TEDI-Design-System-(draft)?m=auto

Documentation (Zeroheight)

• Introduction page is created - includes instructions and examples
  • Links are added - cross reference to Figma and both Storybooks
• Accessibility page is created - includes instructions to meet accessibility requirements
• Writing principles is created (optional) - added only if the component includes text
• Update statuses page in Zeroheight

Code & Development

• The component is developed using best practices, conventions, and modern frontend trends
• The component follows BEM naming conventions (if applicable)
• The component implementation matches the Figma design, including all defined states and interactions
• The component supports responsiveness and scales across breakpoints (if applicable)
• The component does not introduce runtime errors or warnings
• Linter passes
• Component has export if needed
• The component has unit tests with at least 80% code coverage
• CodeCov passes minimum coverage threshold
• The component has passed code review
• The component has passed Chromatic visual review
• Storybook stories are created:
  • Cover all Figma variations
  • Include edge cases, empty/error states
• Component’s API (props, slots, events) is documented
• ZeroHeight is updated with design/development guidelines
• External dependencies used in the component are documented in Confluence with rationale.
• Semantic commit format is used (for semantic-release)
• External libraries comply with validated open source licenses
• Component is versioned correctly and ready for release if required
• Update statuses page in Zeroheight

Testing

1. The component has been manually WCAG tested
2. The component has been manually tested with:
   • Chrome
   • Safari
   • Firefox
   • Edge
3. Mobile devices
   • iPhone
   • Android
   • iPad
4. The component is tested on different screen sizes
5. WCAG guidelines for the component are documented in ZeroHeight
6. Statuses page in Zeroheight is updated

Community Components

When developing TEDI community components, the requirements are loose. However when you would like to contribute component that is TEDI-READY compatible, following DoD will help TEDI maintenance team to quickly convert it to TEDI-READY.

Code & Development

• The component is developed using best practices, conventions, and modern frontend trends
• The component follows BEM naming conventions (if applicable)
• The component implementation matches as much as possible the Figma design, including all defined states and interactions
• The component supports responsiveness and scales across breakpoints (if applicable)
• The component does not introduce runtime errors or warnings
• Linter passes
• Component has export if needed
• The component has unit tests with at least 80% code coverage
• Storybook stories are created:
  • Cover all Figma variations
  • Include edge cases, empty/error states
• Component’s API (props, slots, events) is documented
• Semantic commit format is used (for semantic-release)
• External libraries comply with validated open source licenses

Validated open source component licences

TEDI will use only third party libs that uses following open source licenses:

• MIT: https://opensource.org/license/mit/
• Apache 2: https://opensource.org/license/apache-2-0/
• BSD 2: https://opensource.org/license/bsd-2-clause/
• BSD 3: https://opensource.org/license/bsd-3-clause/
• EUPL 1.2: https://joinup.ec.europa.eu/collection/eupl/eupl-text-eupl-12

Open Source Initiative license list: https://opensource.org/licenses/