diff options
Diffstat (limited to 'docs/fr-fr')
| -rw-r--r-- | docs/fr-fr/README.md | 1 | ||||
| -rw-r--r-- | docs/fr-fr/breaking_changes.md | 1 | ||||
| -rw-r--r-- | docs/fr-fr/contributing.md | 2 |
3 files changed, 1 insertions, 3 deletions
diff --git a/docs/fr-fr/README.md b/docs/fr-fr/README.md index dfb9dcda4e..3d1f740abb 100644 --- a/docs/fr-fr/README.md +++ b/docs/fr-fr/README.md @@ -1,7 +1,6 @@ # Quantum Mechanical Keyboard Firmware [](https://github.com/qmk/qmk_firmware/tags) -[](https://travis-ci.org/qmk/qmk_firmware) [](https://discord.gg/Uq7gcHh) [](https://docs.qmk.fm) [](https://github.com/qmk/qmk_firmware/pulse/monthly) diff --git a/docs/fr-fr/breaking_changes.md b/docs/fr-fr/breaking_changes.md index 2dbb26e5a5..4c3817d2ef 100644 --- a/docs/fr-fr/breaking_changes.md +++ b/docs/fr-fr/breaking_changes.md @@ -103,5 +103,4 @@ Ceci est fait immédiatement après la fusion de la branche `future` précédent * [ ] `git push origin future` * Actions sur GitHub * [ ] Crée un PR pour `future` - * [ ] S'assurer que Travis ne relève aucun problème * [ ] Fusion le PR `future` diff --git a/docs/fr-fr/contributing.md b/docs/fr-fr/contributing.md index 58931cf1f6..d135871055 100644 --- a/docs/fr-fr/contributing.md +++ b/docs/fr-fr/contributing.md @@ -134,7 +134,7 @@ Les PR de nouvelles fonctionnalités de de correction de bug affectent tous les Voici quelques choses à garder en tête lorsque vous travaillez sur une fonctionnalité ou un bug fix. * **Désactivé par défaut** - la mémoire est plutôt limitée sur la plupart des puces que QMK supporte, et il est important que les keymaps courantes ne soient pas cassées. S'il vous plaît faites que vos features doivent être **activées** plutôt que désactivées. Si vous pensez qu'elle devrait être activée par défaut, ou que cela réduit la taille du code, parlez-nous-en. -* **Compilez localement avant de soumettre** - Cela devrait aller sans dire, mais votre code doit compiler! Notre système Travis devrait relever les problèmes, mais il est généralement plus rapide de compiler quelques claviers en local plutôt que d'attendre le retour des résultats +* **Compilez localement avant de soumettre** - Cela devrait aller sans dire, mais votre code doit compiler! Vous devriez toujours faire gaffe à ce que vos changements compilent avant d'ouvrir une pull request. * **Faites attention aux révisions et différentes bases de puces** - beaucoup de claviers ont des révisions qui permettent des changements de configuration mineurs, voir des bases de chip différentes. Essayez de faire que votre fonctionnalité soit supportée à la fois sur ARM et AVR, ou désactivez-là automatiquement sur les plateformes non supportées. * **Expliquez votre fonctionnalité** - Documentez-là dans `docs/`, soit dans un nouveau fichier, ou dans une partie d'un fichier existant. Si vous ne la documentez pas, personne ne pourra bénéficier de votre dur labeur. |