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