Acceptance 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 quality of the code examples
• that enough informations are provided about accessibility and html semantic (what tags to use, aria attributes etc)

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