Ways of Contributions

Making an engineering contribuition

We always appreciate the help and contributions of other engineers across Mews, whether it's new variants, simple bug fixes, or building out entire components. Before any code changes happen though, be sure to follow these steps:

  1. Talk to your designer
    Check in with your designer and make sure the changes have been approved by the MDS team, via the request process. We don’t recommend starting a PR on new functionality — no matter how small — without confirming this, as you may spend time on changes that won’t be approved to merge into MDS.
  2. Technical Design Doc
    Create a technical design doc (TDD), for any net-new components or component additions/updates within MDS. This allows everyone to discuss the component API and functionality before starting to build.
  3. Implement and Test
    Once the TDD has been finalized, it's time to build. If you're creating a new component, check out our documentation. Don't forget about tests if you're updating an existing component.
  4. Pull request
    When your work is complete and all tests are passed, make a draft pull request for your changes by following the development guidelines. This will start the CI process, running a variety of tests. Once those tests are passed, mark your PR as "Ready for review" and ping us on #rnd-designsystem. Your changes will be reviewed by an engineer and a designer from the MDS team. We ensure each component is built to spec, accessible, performant and works well with other components.
  5. Release
    Now the fun part: releasing your component! After an MDS team member merges your change and Github has been updated, feel free to announce your component/changes on the #rnd-designsystem Slack channel.


Engineering checklist

We recommend following this checklist to ensure standardized quality for all MDS components.

  • The component is implemented strictly according to the design system. Its API does not allow extra variants or behavior that is not documented.
  • The implemented component is modular and follows the separation of concerns principle. Every component has a clear purpose and should contain logic, styles, and types regarding it.
  • The component is fully accessible (WCAG 2.0 Level AA compliance).
  • There are no 3rd party libraries used. We want to keep the implementation as light and independent as possible. This is especially concerning lodash and fp-ts.
  • The component is covered with an accessibility test and all complex functions are covered with unit tests.
  • All fundamental values (spacings, colors, elevations, …) are connected to design tokens.
  • There's a storybook story defined according to our guide for every component:
    • covering the fundamental use cases with just the needed stories
    • following the recommended techniques
    • offering some component API documentation by adding comments to the TS interface, as explained in the Confluence page
    • ensuring the story itself has no A11y problems
    • ensuring the Storybook UI is robust and can not be broken using the available controls in the story
  • Technical documentation is written and published on Supernova.