@1024pix/pix-ui 11.1.0

package/docs/architecture.stories.mdx

@@ -0,0 +1,106 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Architecture' />
+
+# Architecture du projet Pix UI
+
+## Arborescence générale
+
+- `.circleci` : configuration pour les [tests de circleci](https://app.circleci.com/pipelines/github/1024pix/pix-ui)
+- `.storybook` : configuration de l'outil Storybook.
+- `addon` : contenu de notre addon Pix UI.
+- `app` : aide l'Ember app à découvrir automatiquement les composants exportés par un addon.
+- `blueprints` : configuration des blueprints (permet de générer automatiquement un composant Pix UI).
+- `config` : configuration de l'addon ember.
+- `docs` : documentation du projet Pix UI.
+- `scripts` : scripts utiles aux [releases de Pix UI](/?path=/docs/développement-faire-une-release--page).
+- `tests` : dossier de tests unitaires et intégration.
+- `.env` : créé et utilisé par Storybook.
+- `CHANGELOG.md` : détails du contenu des dernières release.
+- `ember-cli-build.js` : sert uniquement à configurer l'application factice trouvée dans tests/dummy/.
+- `index.js` : point d'entrée (par défaut et par convention) pour un projet npm.
+- `package.json` : configuration du projet npm.
+
+Documentation ember sur l'[arborescence d'un addon ember ici](https://cli.emberjs.com/release/writing-addons/).
+
+### .storybook
+
+- `.storybook`
+  - `main.js`: indique l’emplacement des fichiers stories et des addons de storybook.
+  - `manager.js`: sert pour le thème de storybook.
+  - `preview-head.html` : setup automatique de storybook utile au live reload.
+  - `preview.js` : utile à la configuration générale des stories : chez nous on l'utilise pour l'ordre des onglets dans le menu de storybook etc.
+  - `storybook-custom-theme.js` : définition de notre thème storybook personnalisé.
+
+### addon
+
+Ce répertoire peut contenir un grand nombre des mêmes sous-répertoires et fichiers qu'une application Ember, comme `/components/` par exemple.
+Pour créer des composants, la plupart du travail se fera ici.
+
+- `addon`
+  - `components` : contient les templates et les controllers de chaque composants.
+    - `pix-tooltip.hbs`
+    - `pix-tooltip.js`
+  - `stories` : contient les stories.
+    - `pix-tooltip.stories.js`
+    - `pix-tooltip.stories.mdx`
+  - `styles` : contient les styles des composants et les styles généraux.
+    - `_colors.scss`
+    - `_fonts.scss`
+    - `_pix-tooltip.scss`
+    - `addon.scss` : point d'entrée des styles.
+
+### app
+
+Le répertoire des applications joue un rôle important pour aider une application Ember à localiser automatiquement les composants
+exportés par un addon.
+
+- `app`
+  - `components`
+    - `pix-tooltip.js` : sert à l'app Ember à retrouver le composant correspondant pour son export.
+  - `styles`
+    - `app.scss` : vide mais utile à [ember-cli-sass](https://github.com/adopted-ember-addons/ember-cli-sass).
+
+### blueprints
+
+Actuellement il n'existe qu'un blueprint sur Pix UI.
+Ce dernier est nommé `pix-component`, il contient tous les modèles permettant de générer les fichiers à la création d'un composant via la commande :
+
+```
+ember generate pix-component <component-name>
+```
+
+Pour plus d'informations sur les blueprints ember voir [la documentation](https://cli.emberjs.com/release/advanced-use/blueprints/).
+
+### config
+
+- `config`
+  - `ember-try.js` : configuration des versions d'Ember dont la compatibilité doit être vérifiée par la suite de tests.
+  - `environment.js` : valeurs par défaut pour les applications qui utilisent notre addon.
+  Les changements de valeurs dans l'application hôte surchargeront celles par défaut.
+
+### docs
+
+Si vous constatez qu'il manque des informations utile au développement du projet, il est vivement encouragé de rajouter de la documentation dans ce dossier là.
+Un fichier de documentation est rédigé en [markdown](https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet) et son extension est `.md` ou `.mdx`.
+
+Les fichiers suffixés par `stories.mdx` s'afficheront dans la documentation de storybook. Tandis que les autres ne seront visible que sur github.
+
+### scripts
+
+Une bonne partie des scripts présents dans ce dossier sont issus de [Pix-bot](https://github.com/1024pix/pix-bot) et servaient aux releases
+de Pix UI mais sont aujourd'hui obsolètes.
+
+Ils peuvent cependant servir en dernier recours si Pix-Bot ne fonctionne pas.
+
+### tests
+
+- `tests`
+  - `dummy` : ne sert pas sous Pix UI car nous utilisons Storybook pour tester et documenter nos composants.
+  - `helpers`
+  - `integration` : au moins un test d'intégration est attendu par composant
+  - `unit` : tests unitaires
+  - `index.html`
+  - `test-helper.js`
+
+Pour plus d'informations sur les bonnes pratiques de tests sur Pix UI voir [les guidelines des tests](/?path=/docs/développement-bonnes-pratiques-tests--page).

package/docs/breaking-changes.stories.mdx

@@ -0,0 +1,90 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Breaking changes' />
+
+# Breaking changes dans Pix UI
+
+## Qu'est-ce qu'un breaking change ?
+
+> Breaking change: change in one part of a software system that potentially
+> causes other components to fail; occurs most often in shared libraries of
+> code used by multiple applications.
+> [[wiktionary](https://en.wiktionary.org/wiki/breaking_change)]
+
+Au sens de Pix UI, un breaking change est un changement dans Pix UI qui va
+avoir un effet de bord indésirable dans une app Ember qui dépend de Pix UI. Cet
+effet indésirable peut-être une erreur, auquel cas cas les tests et/ou le build
+de l'app vont échouer, ce qui rend le problème facile à détecter.
+
+Mais le problème peut aussi être silencieux, obligeant le développeur qui fait
+la montée de version à être vigilant. On veut donc non seulement l'avertir de
+la présence de ce breaking change (en faisant un release majeure) mais aussi
+lui donner un maximum d'informations sur ce qu'il va devoir vérifier et
+modifier.
+
+## Comment identifier les *breaking changes* dans Pix UI ?
+
+Pour cela, on peut se poser les questions suivantes :
+
+Mes changements dans Pix UI peuvent-ils déclencher une erreur dans une app Pix ?
+
+Exemples :
+- Un composant est supprimé
+- Un composant change de nom
+- Un argument obligatoire est ajouté à un composant
+
+Mes changements dans Pix UI peuvent-ils provoquer un problème silencieux dans
+une app Pix ?
+
+Exemples :
+- Un argument facultatif change de nom
+- La valeur par défaut d'un argument change
+- Un changement de style CSS à l'intérieur va avoir des effets de bord à
+  l'extérieur (ex: un élément `block` devient un élément `inline`).
+
+Il faut prêter une attention particulière aux modifications et aux ajouts de
+code existant touchant les interfaces publiques des composants. Les ajouts de
+code provoquent rarement des *breaking-changes*.
+
+Exemples :
+- Un nouveau composant est ajouté
+- Un argument facultatif est ajouté
+
+Astuce : pour repérer les potentiels breaking changes, le mieux est d'installer
+la version en cours de développement de Pix UI dans une app Ember à partir de
+sa branche sur Github. Si, sans faire aucune autre modification que cette mise
+à jour, on observe des changements, alors il s'agit probablement de *breaking
+changes*.
+
+## Comment communiquer en cas de *breaking change* ?
+
+C'est au développeur qui ouvre la *pull request* qu'incombe la responsabilité
+d'identifier les éventuels *breaking changes* dans ses modifications et, le cas
+échéant, de les signaler dans le titre de la PR. Il lui faudra donner aussi un
+maximum d'informations dans une section breaking changes de la PR sur ce qu'il
+convient de faire pour vérifier que rien de casse lors de la montée de version
+de Pix UI.
+
+Ainsi :
+- le développeur qui fera la prochaine release de Pix UI saura que ce doit être
+  une version majeure ;
+- le développeur qui fera la montée de version de Pix UI côté app Ember aura
+  connaissance de ces *breaking changes* et de ce qu'il a à vérifier.
+
+## Comment éviter un *breaking change* ?
+
+On veut éviter de faire de trop nombreuses versions majeures, car elles
+impliquent un risque et un effort d'attention supplémentaire du développeur qui
+va faire la montée de version de Pix UI dans une app Ember.
+
+Plutôt que de supprimer une partie du code (comme par exemple l'argument d'une
+fonction devenu obsolète), on peut la marquer comme *deprecated* et lancer un
+warning pour avertir le développeur que la fonctionnalité sera prochainement
+supprimée ou modifiée.
+
+Lors de la montée de version suivante, on pourra supprimer tous les codes
+deprecated, ce qui permet de regrouper les breaking changes, laisser au
+développeur le temps d'adapter le code et éviter de multiplier les montées de
+versions majeures.
+
+

package/docs/changelog.stories.mdx

@@ -0,0 +1,6 @@
+import Changelog from '../CHANGELOG.md';
+import { Meta, Description } from '@storybook/addon-docs/blocks';
+
+<Meta title="CHANGELOG" />
+
+<Description>{Changelog}</Description>

package/docs/create-component.stories.mdx

@@ -0,0 +1,118 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Créer un composant' />
+
+# Créer un composant et sa story
+
+## Création des fichiers nécessaires au composant
+
+La commande suivante permet de générer un nouveau composant :
+
+```shell
+ember generate pix-component <component-name>
+```
+
+⚠️ Ne pas préfixer le nom du composant par `pix`, cela se fera automatiquement avec la commande.
+
+Cette commande est [un blueprint ember](https://cli.emberjs.com/release/advanced-use/blueprints/), c'est à dire une
+commande customisée, elle permet d'automatiser plusieurs choses.
+
+La commande crée et pré-remplit les fichiers suivant :
+* `addon/templates/components/pix-<component-name>.hbs`: template du composant.
+* `addon/components/pix-<component-name>.js`: controller du composant.
+* `addon/stories/pix-<component-name>.stories.mdx`: documentation du composant.
+* `addon/stories/pix-<component-name>.stories.js`: arguments et code de l'aperçu du composant dans la documentation.
+* `addon/styles/_pix-<component-name>.scss`: style du composant.
+* `app/components/pix-<component-name>.js`, sert uniquement à ember pour retrouver les composants existants dans le dossier `addon`. **On ne modifiera pas ce fichier là.**
+* `tests/integration/components/pix-<component-name>-test.js`: test du composant.
+
+De plus la commande met à jour les imports scss dans le fichier :
+* `addon.scss` (elle rajoutera l'import juste avant la ligne `html {`)
+
+## C'est quoi une story ?
+
+Une story, c'est deux fichiers :
+- un dont l'extension est `.stories.mdx`
+- un dont l'extension est `.stories.js`
+
+Ils permettent de visualiser et documenter le composant.
+
+Lorsqu'on lance Storybook ce dernier va dans `.storybook/main.js` afin de trouver l'emplacement des fichiers `.stories.js`
+et `stories.mdx`.
+
+Ces derniers permettent ainsi d'afficher un aperçu des composants ainsi que leur documentation.
+
+## Comment écrire une story ?
+
+Voici par exemple la story du composant PixMessage :
+
+```javascript
+// pix-message.stories.js
+import { hbs } from 'ember-cli-htmlbars'; // import nécessaire pour 'canvasContent'
+
+// Ici on instancie l'aperçu du composant dans la doc
+export const message = (args) => {
+  return {
+    template: hbs`
+      <PixMessage @type={{type}} @withIcon={{withIcon}}>
+        Ceci est un message {{type}}
+      </PixMessage>
+    `,
+    context: args
+  };
+};
+
+// Ici on définit et on documente les arguments du composant
+export const argTypes = {
+  type: {
+    name: 'type',
+    description: 'Type du message',
+    type: { name: 'string', required: false },
+    defaultValue: 'info',
+    control: { type: 'select', options: ['info', 'success', 'warning', 'alert'] },
+  },
+}
+```
+
+```markdown
+{/* pix-message.stories.mdx */}
+import { Meta, Story, Canvas, ArgsTable } from '@storybook/addon-docs/blocks';
+import centered from '@storybook/addon-centered/ember';
+import * as stories from './pix-message.stories.js';
+
+{/* Titre de la section affichée dans le menu de storybook */}
+
+<Meta
+  title='Notification/Message'
+  component='PixMessage'
+  decorators={[centered]}
+  argTypes={stories.argTypes}
+/>
+
+# Pix Message
+
+Un bandeau d'information, par défaut de type info, avec une icône facultative.
+
+{/* Affiche la prévisualisation du composant telle que définie dans pix-message.stories.js */}
+
+<Canvas isColumn>
+  <Story name="Message" story={stories.message} height={140} />
+</Canvas>
+
+## Usage
+
+```html
+<PixMessage @type='info' @withIcon='true'>
+  Ceci est un message à caractère informatif.
+</PixMessage>
+\```
+
+## Arguments
+
+{/* Affiche le tableau des arguments tels que définis dans pix-message.stories.js */}
+
+<ArgsTable story="Message" />
+
+```
+
+Plus d'information sur le [guide d'ember de Storybook ici](https://storybook.js.org/docs/guides/guide-ember/).

package/docs/design-system.stories.mdx

@@ -0,0 +1,20 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Design System' />
+
+# Design System
+
+> Un Design System s’apparente à une bibliothèque de composants, visuels et principes au code réutilisable.
+> (...)
+> Le Design System regroupe la charte ergonomique et la charte graphique.
+
+Voir : https://www.usabilis.com/design-system/
+
+Chez Pix, nos UX/UI designers guident notre Design System dont on retrouve la documentation sur [Zeroheight](https://zeroheight.com/8dd127da7/p/45cb0c-introduction).
+
+Puis ce sont les développeurs qui s'occupent d'implémenter le Design System avec une [librairie de composants Ember](https://cli.emberjs.com/release/writing-addons/)
+et dont la documentation est générée par [Storybook](https://storybook.js.org/docs/react/get-started/introduction).
+
+Ainsi pour le Design System de Pix, c'est Zeroheight qui fait foi, notre librairie Pix UI n'en n'étant que l'implémentation.
+
+S'il y a des doutes sur l'apparence d'un composant de notre Design System, il suffit de se rendre sur Zeroheight et d'inspecter le composant.

package/docs/good-practices-a11y.stories.mdx

@@ -0,0 +1,48 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+import accessibilityImage from './assets/accessibility-storybook.png';
+
+<Meta title='Développement/Bonnes pratiques/Accessibilité' />
+
+# Bonnes pratiques d'accessibilité
+
+L'accessiblité est un enjeu important sur nos composants UI.
+
+## S'assurer d'avoir un composant accessible
+
+- Penser au contraste entre le fond et le texte de votre composant.
+- La taille de la police ne peut pas être inférieure à `10px`.
+- La navigation au clavier permet d'accéder à toutes les parties de votre composant `Tab pour aller à l'élément suivant, Entrée ou Espace pour valider, Maj+Tab pour revenir à l'élément précédent`.
+- S'assurer que les éléments en focus suivent un ordre logique.
+- Lancer un logiciel de lecture d'écran (VoiceOver pour Mac) et s'assurer que ce soit compréhensible pour l'utilisateur.
+
+
+Exemples pour l'utilisation du lecteur d'écran :
+- Est-ce que l’information est lu et est compréhensible ?
+
+- Si l'information est obligatoire, est-ce signalé ?
+
+- Est-ce que les champs à remplir sont bien accompagnés d’un label ?
+
+- En cas d’erreur, est-ce que l’on prévient bien l'utilisateur pour corriger son erreur ?
+
+
+Pour vous aider à créer un composant accessible :
+
+- les channels Slack `#tech-a11y` (interne) et `#ext-hotline-accessibilité-pix-tanaguru` (externe avec Tanaguru) sont disponibles pour répondre à vos questions sur le sujet.
+- Nos pratiques sur l'accessibilité [ici](https://github.com/1024pix/pix/blob/dev/docs/Accessibilite.md)
+- Compte-rendu détaillé de notre atelier avec Tanaguru [ici](https://1024pix.atlassian.net/wiki/spaces/DEV/pages/2856288297/2021-05-27+-+Compte-rendu+Atelier+accessibilit+Tanaguru+les+devs)
+- Checklist des recommandations WebAIM [ici](https://webaim.org/standards/wcag/checklist#sc2.4.4)
+
+
+## Vérifier l'accessibilité d'un composant sur Storybook
+
+Pour chaque composant, dans la partie 'Canvas', vous pouvez accéder à l'onglet 'Accessibility' qui donne un aperçu des règles d'accessibilité validées (Passes) ou non (Violations).
+
+
+Il est possible de cliquer sur "More info..." pour connaître en détail ces règles.
+
+<img src={accessibilityImage} alt="Accessibility in Storybook"/>
+
+Mais cela ne couvre pas à 100% les règles d'accessibilité.
+
+

package/docs/good-practices-design.stories.mdx

@@ -0,0 +1,71 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Bonnes pratiques/Design' />
+
+# Bonnes pratiques design
+
+## Nommage
+
+- les **noms de branches** commencent par `pix-ui`.
+
+
+- Les **noms des fichiers** suivent l'exemple de la pix-tooltip.
+*Par exemple, pour les styles, on recomandera de rajouter `_` devant le nom du fichier pour indiquer que c'est un ["fichier partiel Sass"](https://sass-lang.com/guide#topic-4).*
+
+
+- Les **noms des composants** commencent par `Pix` et sont écrit en *PascalCase*.
+*Par exemple, un composant bouton devient : `PixButton`.*
+
+
+- Les **noms des propriétés des composants** sont écrit en *camelCase*.
+
+```hbs
+<PixSelect
+  @options={{options}}
+  @onChange={{onChange}}
+  @selectedOption="1"
+/>
+```
+
+- Les **noms des classes CSS** suivent la convention [BEM](https://github.com/1024pix/pix/blob/dev/docs/CSS.md).
+
+```html
+class='pix-tooltip__content'
+```
+
+## Intentions & Responsabilités
+
+Il faut garder une **responsabilité unique** par composant.
+
+- Un composant doit interagir uniquement dans son scope afin de ne pas devenir trop complexe et provoquer des effets de bord.
+- Un composant trop complexe induit plusieurs paramètres ce qui rend donc son utilisation délicate.
+
+Par exemple, si l'intention d'un composant est d'être un bouton (dans notre existant, *`PixButton`*) et qu'on le fait évoluer pour qu'il puisse devenir aussi un lien, il perd alors son intention d'origine (le nommage du composant *`PixButton`* ne fait alors plus sens) et prend trop de responsabilités.
+
+Il conviendra alors d'avoir un composant pour un bouton et un autre pour un lien.
+
+## Breaking changes
+
+Un breaking change implique un changement d'intention ou/et de responsabilités du composant. Il est nécessaire de l'indiquer dans la PR correspondante.
+
+Exemple de PR : [Enrichir la Pix Tooltip - BREAKING CHANGES (Pix-2000).](https://github.com/1024pix/pix-ui/pull/68)
+
+Lorsqu'une autre personne va mettre à jour Pix UI dans une application, il est important qu'elle **vérifie le bon fonctionnement et le bon affichage des composants impactés par ces changements**. Il faut lui faciliter au maximum cette tâche en indiquant clairement dans la description de la PR le ou les composants impactés et les vérifications à effectuer.
+
+## Rétrocompatibilité / Deprecated
+
+Il est aussi possible de signaler ces changements comme dépréciés :
+- Ne pas supprimer le composant actuel mais l'indiquer comme déprécié afin qu'il soit toujours utilisable le temps de faire les modifications. À terme, l'élément déprécié sera supprimé dans une nouvelle version majeure de Pix UI.
+
+Exemple d'un composant déprécié :
+```hbs
+<PixSelect>
+  <NewPixSelect
+    @options={{options}}
+    @onChange={{onChange}}
+    @selectedOption="1"
+  />
+</PixSelect>
+```
+
+Autres détails d'un breaking change sur la page [Installation](/?path=/docs/utiliser-pix-ui-installation--page).

package/docs/good-practices-responsive.stories.mdx

@@ -0,0 +1,51 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Bonnes pratiques/Responsive' />
+
+# Bonnes pratiques responsive
+
+La mise en place de composants responsive doit respecter les règles définies dans le Design System.
+
+## Breakpoints
+
+L'ensemble des breakpoints pour les différentes résolutions sont définis dans [le chapitre **Layout/Breakpoints** du Design System](https://zeroheight.com/8dd127da7/p/6877af-layout/t/47086b).
+
+Ils sont décris dans le fichier `addon/styles/_breakpoints.scss` et utilisables via la mixin `device-is`
+
+Par exemple, ici le style s'applique si on a moins la largeure d'une tablette.
+
+
+```scss
+@include device-is('tablet') {
+  padding: 32px 58px;
+  font-size: 0.875rem;
+}
+```
+
+Le différents devices disponibles sont :
+- `mobile`
+- `tablet`
+- `desktop`
+- `large-screen`
+
+## Mobile first
+
+Le développement des composants doit être pensé et développé pour mobile puis adapté à des résolutions et devices supérieurs par la suite.
+
+```scss
+.my-class {
+  width: 100px; // Sur mobile par défaut
+
+  @include device-is('tablet') {
+    width: 200px; // Sur tablette
+  }
+
+  @include device-is('desktop') {
+    width: 300px; // Sur desktop
+  }
+
+  @include device-is('large-screen') {
+    width: 400px; // Sur écran large
+  }
+}
+```

package/docs/good-practices-style-css.stories.mdx

@@ -0,0 +1,40 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Bonnes pratiques/Style CSS' />
+
+# Style CSS / SCSS
+
+## Arborescence
+
+- Les variables se trouvent dans leur fichier scss respectif: `_breakpoints.scss`, `_colors.scss`, `_fonts.scss`.
+- Chaque composant a son fichier scss qui sont importés dans `addon/styles/addon.scss`.
+
+~~~javascript
+@import 'pix-tooltip';
+~~~
+
+## Rendre surchargeable le SCSS
+
+Passer `...attributes` au composant.
+
+~~~html
+<div class="pix-background-header" ...attributes>
+~~~
+
+## Convention BEM
+
+Nos classes suivent la convention [BEM](https://github.com/1024pix/pix/blob/dev/docs/CSS.md).
+
+~~~javascript
+class='pix-tooltip__content'
+~~~
+
+## rem, spacing...
+
+Il est recommandé d'utiliser le `rem` plutot que `px`.
+1rem = 16px
+
+Concernant les niveaux de textes, se référer a ZeroHeight [ici](https://zeroheight.com/8dd127da7/p/20e4df-typographie/b/974231).
+
+Utiliser les **variables Sass** déjà existantes.
+*Par exemple, vérifier dans les fichiers `_fonts.scss` et `_colors.scss`. Si elles n'existent pas, les rajouter au bon endroit.*

package/docs/good-practices-tests.stories.mdx

@@ -0,0 +1,9 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Bonnes pratiques/Tests' />
+
+# Bonnes pratiques de test
+
+- Tests unitaires
+- Tests intégrations
+- Tests UI (en cours d'étude)

package/docs/make-a-release.stories.mdx

@@ -0,0 +1,66 @@
+import { Meta } from '@storybook/addon-docs/blocks';
+
+<Meta title='Développement/Faire une release' />
+
+# Faire une release
+
+## C'est quoi une release ?
+
+Une release est la publication d'un nouvelle version du projet.
+
+Autrement dit, on crée un tag git pour nommer cette version. Les nouveautés embarquées par cette version sont donc
+uniquement celles déjà présentes sur `dev` au moment de la release.
+
+Les applications se servant de Pix UI pourront alors se mettre à jour et utiliser les nouveaux composants et des
+dernières features en précisant le numéro de la version.
+
+Par ailleurs, sur Pix UI une release signifie aussi la mise à jour automatique de [notre storybook en ligne](https://storybook.pix.fr/).
+
+## Effectuer la release, méthode via slack (conseillée)
+
+Aller dans le canal slack dédié aux releases : [#tech-releases](https://1024pix.slack.com/archives/CVAMDQYHY), puis taper la commande suivante :
+- `/publish-pix-ui <version_souhaitée>`
+    `<version_souhaitée>` peut prendre 3 valeurs :
+    - `patch` : correctif de bug
+    - `minor` : modifications n'apportant pas de changement dans l'utilisation de Pix UI
+    - `major` : modifications apportant des breaking changes
+
+Vous devriez voir apparaître dans le canal un premier message (visible uniquement par vous) de Pix-bot vous indiquant
+que la demande de déploiement pour Pix UI a bien été prise en compte.
+
+Ensuite, Pix-Bot vous confirmera à nouveau via deux messages (un privé et un public) du bon déploiement de Pix UI en
+indiquant le numéro de sa nouvelle version.
+
+Et voilà 🎉
+
+Si vous souhaitez suivre le déroulement de la release, consulter les [logs](https://github.com/1024pix/pix-ui/actions/workflows/deploy-storybook.yml)
+de la  GitHub action `Deploy Pix UI Storybook`.
+
+## Constater le bon fonctionnement de la release
+
+Pour vérifier si la release s'est bien déroulée :
+- vérifier le contenu du [CHANGELOG.md](../CHANGELOG.md) : contient-il toutes les PR qui ont été mergées récemment sur la branche `dev` ?
+- vérifier si notre [Storybook en ligne](https://1024pix.github.io/pix-ui/) montre bien les nouveaux composants.
+
+
+## Effectuer la release, méthode à la mano (déconseillée)
+Après s'être mis à jour sur la branche dev, lancer le script de publication :
+- `git checkout dev`
+- `git pull`
+- `./scripts/publish.sh <version_souhaitée>`
+
+  `<version_souhaitée>` peut prendre 3 valeurs :
+    - `patch` : correctif de bug
+    - `minor` : modifications n'apportant pas de changement dans l'utilisation de Pix UI
+    - `major` : modifications apportant des breaking changes
+
+Pour plus d'informations au sujet de la version à choisir se référencer à [SemVer](https://semver.org/lang/fr/).
+
+Le script de publication effectuera automatiquement les actions suivantes :
+- mise à jour de la version du projet dans le `package.json`
+- création d'un tag git correspondant à la nouvelle version
+- mise à jour de la liste des changements dans le [CHANGELOG.md](../CHANGELOG.md)
+- mise à jour de la branche `master` par rapport à `dev`
+- re-[déploiement de storybook sur les GitHub Pages](/?path=/docs/développement-storybook--page)
+
+

package/docs/pull_request_template.md

@@ -0,0 +1,14 @@
+## :boom: BREAKING_CHANGES
+> _Décrivez ici les changements cassant (voir la doc associée)[https://github.com/1024pix/pix-ui/blob/dev/docs/breaking-changes.stories.mdx], s'il n'y en a pas indiquez le aussi.
+
+## :christmas_tree: Problème
+> _Décrivez ici le besoin ou l'intention couvert par cette Pull Request._
+
+## :gift: Solution
+> _Ajoutez à cet endroit, si nécessaire, des détails concernant la solution technique retenue et mise en oeuvre, des difficultés ou problèmes rencontrés._
+
+## :star2: Remarques
+> _Des infos supplémentaires, trucs et astuces ?_
+
+## :santa: Pour tester
+> _Les instructions pour reproduire le problème, les profils de test, le parcours spécifique à utiliser, etc._