Créér une demande de retrait
Les demandes de retrait (Pull requests) sont bienvenues. Veuillez vous assurer que vos modifications sont à jour et limitez la portée d'engagement (commit) seulement aux fichiers que vous désirez modifier (pour éviter des conflits).
- Pour réduire la pollution d'engagement dans la base de code principale, considérez rebaser vos engagements avant de créer une demande de retrait de la branche principale.
Nouvelles composantes
Devraient être ajoutées dans une branche feature-* (p.e., feature-lightbox) qui est créé à partir de la branche maître (master).
- Créer une nouvelle branche du maître en utilisant :
git fetch upstream
git checkout upstream/master
git checkout -b my-cool-new-feature
- L'accord de licence pour toutes les nouvelles composantes et code de support doit être compatible avec la licence MIT utilisée par la BOEW.
- Les nouveaux modules d'extension devraient utiliser la même structure et format que les modules d'extension existants.
- Inclure le bloc commentaire d'avis à l'intérieur de tout fichiers sources à base textuelle qui dérivent du droit d'auteur de la Couronne.
Correction d'anomalies et déploiements de correctifs qui s'appliquent à toutes les versions
Devraient être soumises à la branche maître.
- Créer une nouvelle branche du maître en utilisant :
git fetch upstream
git checkout upstream/master
git checkout -b my-patch-description
Tester votre rapiécage avant de soumettre
- Validez vos balises HTML pour vous assurer du HTML5 bien formé.
- Ces tests seront exécutés comme partie de l'intégration (build) par défaut, ou en apellant
grunt htmllint
pour exécuter la tâche sur votre construction HTML. - Vous pouvez manuellement tester pour des balises bien formées en utilisant le validateur HTML W3C, validez avec une paramètre XHTML5 et un crochet à "Be lax about HTTP Content-Type".
- Ces tests seront exécutés comme partie de l'intégration (build) par défaut, ou en apellant
-
Validez votre CSS avec les changements suivants aux paramètres par défaut:
- Profile: CSS level 3
- Vendor extensions: Warnings
- Validez votre code JavaScript. Cette validation est effectuée en apellant
grunt eslint
- Optimiser votre code JavaScript, CSS et HTML
- Recommandations de formattage :
- L'indentation peut être renforcé en installant un module d'extension EditorConfig pour votre environnement de développement intégré préféré.
- Indenter avec la tabulation en utilisant le style d'indentation K&R
- Utiliser des double guillemets pour des chaînes de caractères en JavaScript (pour que les guillemets simples non échappés puissent être utilisés pour des attributs dans le code de sortie HTML).
-
Tester les pages Web contre la base de test des fureteurs suivants :
- Les versions majeures courante et précédente de chaque fureteur qui compte pour au moins 5 pourcent des visitesFootnote 1 sur le site Web;
- N'importe quelle version majeure d'un fureteur qui, par lui même, compte pour 5 pourcent des visitesFootnote 1 du site Web; et
- La version majeure courante de fureteur mobile qui compte pour au moins 5 pourcent des visitesFootnote 1 sur le site Web effecutées avec les appareils mobiles.
- Les tests sur les déploiements de correctifs sont exécutés par Travis-CI, mais la même batterie de tests peut être exécutée en utilisant
grunt dist
localement avant de soumettre.
Commit Messages
Needs translation
When committing changes for a pull request, your commit message should start off with the name of the affected plugin(s) or topic, followed by a colon and a short description of what's changed. A longer description can also optionally be included. If the commit resolves a pre-existing issue on GitHub, include "Fixes #issue-id." as a part of the long description.
- Message example
Plugin name/topic: Short description of the change.
(Optional) Long description of the change. Fixes #1715.- Command line example
git commit -m "Plugin name/topic: Short description of the change." -m "(Optional) Long description of the change. Fixes #1715."
- Date de modification :