Lignes directrices pour les contributeurs

Rapporter un problème ou une anomalie

  • Quelle version de la BOEW est affectée (v3.1.0, v3.1.1, etc)? Si ce n'est pas la dernière version stable, est-ce que la dernière version a résolue le problème?
  • Le problème fut trouvé avec quel navigateur (IE8, FireFox 18, Chrome 24, ou une combinaison de navigateurs)?
  • Un lien vers une page pouvant être utilisée pour reproduire le problème (URL public ou démo). Si une page ne peut être fournie, une photo peut ête attachée montrant le problème (utilisez [[la capacité fichier joint de GitHub | https://github.com/blog/1347-issue-attachments]] à cet effet.)

Créér une demande de retrait

Les demandes de retrait sont les bienvenues. Assurez-vous d'apporter les changements dans la dernière version du code et de limiter le champ de validation (commit range) seulement aux fichiers que vous aviez l’intention de modifier (pour éviter les conflits).

  • Pour réduire la pollution du code de base avec chaque sauvegarde (commit) considérez re-niveler (Rebasing) vos sauvegardes avant de créér une demande de retrait sur la branche principale.

Nouveaux composants

Les nouvelles composantes devraient être ajoutées dans un branchement de type feature-* (p. ex., feature-lightbox).

  • Crééz une nouvelle branche de la principale de la façon suivante:
    • git fetch upstream
    • git checkout upstream/v3.1
    • git checkout -b feature-nouvelle-composante
  • Les licences de toutes les nouvelles composantes et du code afférent doivent être compatibles avec la licence MIT utilisée par la Boîte à outils de l’expérience Web (BOEW).
  • Les nouveaux modules d’extension devraient suivre le structure et format des plugiciels actuels.
  • Inclure le bloc de texte sur les conditions d’utilisation de la BOEW dans tous les fichiers sources textuels soumis aux droits d’auteur de la Couronne.

Résolution de bogues et rustines logicielles applicable à toutes les versions

Devrait être soumise sur la branche v3.1.

  • Créér une nouvelle branche à partir de v3.1 de la façon suivante:
    • git fetch upstream
    • git checkout upstream/v3.1
    • git checkout -b -description-ma-rustine

Testez votre RP avant de le soumettre

  • Valider votre balisage HTML. Le balisage devrait être en HTML5 bien formé.
    • Pour vérifier si le balisage est bien formé, valider à l’aide d’un préréglage XHTML5 et cocher la case « Be lax about HTTP Content-Type ».
  • Valider votre CSS en apportant les changements suivants aux paramètres par défaut :
    • Profil : CSS niveau 3
    • Extensions Propriétaires : Avertissements
  • Valider votre code JavaScript
  • Optimiser votre code JavaScript, CSS et HTML
  • Recommandations quant au formatage :
    • Ajouter les tabulations en utilisant le style d'indentation K&R
    • Utiliser les guillemets simples pour les chaînes de caractères en JavaScript (de façon à ce que les guillemets doubles non échappés (unescaped) puissent être utilisés pour les attributs dans les données de sortie HTML)
  • Mettre à l’essai les pages Web par rapport à la « base de référence des essais de navigateurs » (browser test baseline) qui suit :
    • la version majeure actuelle et précédente de chaque navigateur qui compte pour au moins 5 % des visites au site Web;
    • toute version majeure d’un navigateur qui, à elle seule, compte pour au moins 5 % des visites au site Web;
    • les versions actuelles et précédentes des navigateurs par défaut de chaque système d’exploitation mobile qui compte pour au moins 5 % de la part de marché du système d’exploitation mobile à l’échelle du Canada ou à l’échelle mondiale.
  • Les essais des RP sont effectués par Travis-CI, mais la même série d'essais peut être exécuté à l'aide de la commande locale "ant test" avant de soumettre,