Contribuer au cœur WordPress / Partie 1 : Trac, le gestionnaire de tickets utilisé par WP

En tant que logiciel open-source, WordPress a besoin de contributeurs et contributrices. Des personnes de tous les pays du monde contribuent à ce projet, et dans une volonté de développer cette culture de la contribution dans la communauté WordPress francophone, nous lançons une série d’articles/tutoriels sur le sujet.

In open source, we feel strongly that to really do something well, you have to get a lot of people involved.

Linus Torvalds

Cet article est le premier d’une série dédiée à la contribution au cœur WordPress. Aujourd’hui, l’objectif est de donner les pistes et liens permettant de trouver des tickets « simples » à corriger afin de pouvoir se lancer dans le grand bain de la contribution au CMS qui propulse plus de 30% du web.

Introduction à Trac, l’outil de ticketing utilisé par  WordPress

Trac est l’outil de ticket utilisé par l’écosystème WordPress.

Pour ouvrir un ticket, contribuer en offrant un patch sur un ticket existant ou pour y ajouter un commentaire – une recommandation, un conseil, une demande de modification, ou autre – il vous sera demandé d’être connecté·e avec votre compte WordPress.org.

Le Trac du cœur WordPress est accessible à l’adresse suivante : 
https://core.trac.wordpress.org/

Les différentes propriétés des tickets Trac WordPress

Type : 
Il y a quatre types de tickets :

• defect : bogue, erreur, ou résultat non prévu.
• enhancement : amélioration de fonctionnalités existantes
• feature request (nouvelle fonctionnalité)
• task (tâche à planifier pour les directeur·ices de la prochaine version du CMS ou pour les mainteneurs de composants)

Milestone : en français, il s’agit d’un « jalon ». Le jalon est la version de WordPress où le ticket sera potentiellement déployé. Par défaut, les nouveaux tickets sont mis en jalon Awaiting Review afin d’éviter le syndrome du scope creep (en anglais). Les seules personnes ayant la possibilité de modifier le jalon d’un ticket sont les committers (en anglais) et les trusted core contributors (en anglais).

Keywords : le champ keyword est le champ le plus important après le milestone. Ce ne sont pas seulement des étiquettes comme dans un article WordPress, mais plutôt une liste de mots-clés décrivant le statut du ticket. Les keywords sont utilisés par l’équipe cœur pour créer les rapports d’avancement de chaque version de WordPress. Par exemple, les tickets ayant le keyword ui-feedback ou ux-feedback sont poussés à l’équipe responsable du design pour qu’ils les prennent en compte lors de leurs meetings.

> Liste complète des mots-clés Trac (en anglais)

Component : le composant correspond à la partie de WordPress concernée par le ticket en question. L’équipe UI va par exemple travailler en priorité sur les tickets marqués Graphic Design, UI, ou Accessibilité. Si possible, essayez de choisir des composants bien spécifiques plutôt que des composants génériques comme General ou Administration.

> Consulter la liste complète des composants WordPress et de leurs mainteneurs (en anglais)

Resolution : à partir du moment où un ticket a fait l’objet d’un commit et qu’il est intégré dans le code source de WordPress, il sera fermé et passé en resolution fixed. Tous les tickets ne sont pas toujours fermés et committés, ils peuvent aussi être fermés pour un certain nombre de raisons :

• duplicate : doublon – la demande a déjà fait l’objet d’un ticket antérieur. L’équipe cœur vous indiquera le ticket en question puis fermera le  ticket en doublon.
• invalid: non-valide – il ne s’agit pas d’un bug, ou alors c’est une question relative au support WP ou à l’utilisation d’une extension ou d’un thème en particulier.
• worksforme : littéralement, « Cela fonctionne chez moi ». Le ticket ne peut pas être reproduit et nécessite de plus amples explications de la part de son propriétaire.
• wontfix: littéralement, « ne sera pas corrigé ». Parfois, certains bogues sont trop spécifiques pour être pris en charge par le cœur WordPress, ou alors ils ne font pas partie du périmètre du CMS.
• maybelater : assez proche de l’étiquette wontfix, maybelater est utilisée pour décrire des tickets qui n’ont pas une importance capitale, pour les tickets vraiment très secondaires ou pour des améliorations qui ne sont pas vraiment dans le périmètre du projet.

Attention, tout cela n’est pas une science exacte. N’hésitez pas à demander aux mainteneurs de composants pourquoi tel ou tel ticket a été placé dans tel ou tel statut 🙂 

Severity et Priority : severity correspond à la criticité du ticket tel qu’il est interprété subjectivement. priority correspond à la criticité du ticket du point de vue objectif pour le projet WordPress. Seuls les committers et les trusted core contributors peuvent modifier la priorité.

Version : la version de WordPress sur laquelle le bug intervient. Normalement, vous devriez utiliser la dernière version à disposition.

Trouver les tickets étiquettés « good-first-bug », réservés aux contributeurs débutants

Les good-first-bug sont des tickets simples et « self-contained », c’est à dire que le futur patch n’a potentiellement pas d’impact sur le reste du CMS. Ce sont les tickets parfaits pour commencer à apprendre à contribuer à WordPress.

Ils sont normalement volontairement laissés aux personnes faisant leur première contribution au cœur WordPress et les «component mainteners» seront toujours particulièrement pédagogues et patients sur ce type de tickets.

Pour voir les tickets good-first-bug n’ayant pas encore de correctif, vous pouvez vous utiliser la requête good-first-bug + needs-patch (lien direct vers cette requête).

Travailler sur des tickets planifiés pour les prochaines versions de WordPress

La recherche personnalisée suivante permet par exemple de voir les tickets étiquettés comme étant des good-first-bug, needs-patch et qui sont planifiés pour la prochaine release (à ce jour, 4.9.9) :

> Consulter cette requête personnalisée

En suivant le lien ci-dessus, vous pourrez modifier le jalon (milestone) de votre requête, et cibler 4.9.10, 5.0.1, 5.1.2 et tout autre release à venir dont le jalon n’a pas encore été créé au moment de la rédaction de cet article.

Anatomie d’un ticket Trac

Dans la capture ci-dessus, on retrouve les informations suivantes : 

• Numéro du ticket #42203
• Titre du ticket (décrivant de façon concise le souci rencontré)
• Identifiant WordPress.org de la personne ayant ouvert le ticket : westonruter
• Jalon (milestone) : 5.0 – cela signifie que le ticket est planifié pour WordPress 5.0
• Criticité (severity) : Normal
• Composant : Bundled Theme (il s’agit des thèmes WordPress par défaut)
• Responsable du ticket (owner) : davidakennedy (c’est le responsable du composant Bundled Themes)
• Priorité (priority) : High
• Version de WordPress (version) : la version sur laquelle le bug a été constaté

En dessous de ce bloc, on trouve la liste des Attachments (pièces jointes) qui peut contenir :

• Des fichiers .diff : fichiers contenant les patches proposés dans le code source de WP, sous la forme d’un fichier de différentiel générés avec un outil de versioning (nous verrons comment générer des patches dans le prochain article de la série).
• Des captures d’écran du bug et de sa résolution, et tout autres types de fichiers (vidéos, animations, etc) pouvant aider à la reproduction du bug ou à son solutionnement.

En dessous de ce bloc on retrouvera le fil de discussion sur le ticket en question.

Au début vous serez forcément un peu perdu si c’est vos premiers pas sur Trac. N’hésitez pas à venir sur le Slack WordPress Francophone (lien pour s’inscrire gratuitement) et plus précisément sur le canal #contribution, nous vous aiderons avec plaisir 😃

La validation d’un ticket et son intégration dans le cœur

Une fois le ticket discuté, les patches testés et validés par l’équipe cœur et le responsable du composant concerné, un message de commit sera réalisé par un ou une core-committer (une personne qui a le droit de valider l’intégration de code dans WP – ils sont quelques dizaines).

Parfois, la validation d’un patch prend du temps (jusqu’à 10 ans et plus pour les cas les plus extrêmes ! mais la plupart du temps cela ne prend que quelques mois)  : soyez patient et n’oubliez de demander des nouvelles sur le fil de discussion de votre ticket.

Une fois le patch validé, vous serez gratifié·e d’un props (remerciement/mention) et serez intégré·e aux crédits de la version de WP concernée.

À noter : les props ne sont pas uniquement attribués aux personnes qui ont résolu le problème, mais aussi à la personne qui a ouvert le ticket ainsi qu’à toutes celles qui y ont contribué.

Liens & ressources pour aller plus loin

• Contribuer à WordPress en utilisant l’outil de ticket Trac (en anglais)
• Handbook for contributors (en anglais) : la documentation complète pour contribuer à WP
• Rapporter un bogue (en anglais)
• Rapporter un problème de sécurité (en anglais)