New pattern submission workflow - adeo/mozaic-design-system GitHub Wiki

Any BU or member of the core team can submit a new pattern.

To submit a new pattern, create a new branch and a pull request into the master branch of the main repo.

The minimal pull request should contain a style guide compatible documentation file (see the project readme).

The documentation should at minimum contain :

a well thought pattern name
a short and well thought definition
what’s the pattern to be developed
how it should works
in what cases it should be used or not

If your submission contain code

The pull request can also propose an implementation of the pattern’s scss/js code with his related live html examples.

But you may want to discuss the utility of the pattern before. It is maybe not the time, or the right pattern for other BU’s. It may spare you some work.

If you want to discuss about a pattern before submitting it :

you can create an issue in the main repo with the right label and convention (still to determine)
you can also go to the slack channel and ask
send the core team an e-mail

Acceptance (Merge) criterias :

The pull request (obviously) need to pass all automated tests

The documentation need to be reviewed by the core team members plus at least by 2 BU’s members. The documentation need to be as comprehensive and as complete as possible.

The reviewer need to assess, and can make suggestions about :

the comprehensiveness and clarity of the documentation
the naming (clear and representative of the pattern)
the usefulness of the pattern and if the pattern should be moved to the BU’s own source code instead
the quality of the information architecture (categories, tabs etc..)
the quality of the text / image / exemples formatting
the compatibility with his own BU’s architecture and practices
if the component should be overridable, and how

if the pattern does not contain code that need to be added later, the documentation can be published as a draft, in order to be seen by other BU’s in the Oficial up-to-date pattern library.

If / when the pattern does contain code :

the code need to be reviewed by the core team front-end.

The core team front-end need to assess :

the code standards, naming convention, and code comments
the consistency related to usage, configuration...
the overall quality regarding accessibility, SEO, compatibility etc
the retro-compatibility and possible collisions with other patterns and the rest of the code source
the correct tagging, labelling and categorisation of the pattern and our git flow implementation

The code also need to be reviewed by at least 3 front-end devs from differents BU’s all the points above and :

the compatibility and usefulness with their own code source