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