Rédaction de notes de version

Produire des notes de version concises destinées aux utilisateurs pour une version Bitwarden. Le résultat est ce que les clients lisent — sur GitHub, dans l'App Store ou Google Play — donc chaque mot doit être orienté bénéfice, sans jargon, et exact sur ce que les utilisateurs vont réellement expérimenter.

Prérequis

Les recherches Jira automatisées nécessitent le plugin bitwarden-atlassian-tools (son serveur MCP expose search_issues, get_issue et get_issue_comments). Sans lui, ou quand on fonctionne dans un Claude.ai Project (les outils MCP n'y sont pas disponibles), repasser à demander à l'utilisateur de coller directement le contenu de la page de version et le texte du fil Slack — le reste de cette compétence fonctionne de façon identique de toute façon. Il n'y a pas d'intégration MCP Slack dans cette marketplace ; le fil Slack est toujours collecté en demandant à l'utilisateur de le coller.

Étape 1 : Rassembler les entrées

Rassembler deux entrées avant de rédiger quoi que ce soit :

1a. Page de version Jira

Demander à l'utilisateur l'URL de la page de version Jira (par ex. https://bitwarden.atlassian.net/projects/CL/versions/12345/tab/release-report-all-issues) ou le nom de la version (par ex. 2025.7.0).

Si search_issues est disponible, résoudre la requête :

• À partir d'une URL, extraire l'ID numérique de version (le segment après /versions/) et requêter par ID : fixVersion = 12345 ORDER BY issuetype ASC
• À partir d'un nom de version, le mettre entre guillemets : fixVersion = "2025.7.0" ORDER BY issuetype ASC

Appeler search_issues avec fields: ["summary", "issuetype", "labels", "components", "status", "description"], et parcourir les résultats en utilisant le nextPageToken retourné jusqu'à ce qu'aucun ne soit retourné. Pour chaque ticket, capturer le résumé, le type, les labels, les composants, le statut, et toute référence de feature flag trouvée dans la description. Les références de feature flag remontent généralement plus complètement dans le fil Slack (Étape 1b) ; appeler get_issue_comments uniquement pour les tickets individuels où le flag est ambigu après vérification des deux sources.

Si les outils MCP ne sont pas disponibles (contexte web app), demander à l'utilisateur de coller directement le contenu de la page de version ou une liste de résumés de ticket dans la conversation.

1b. Fil #release Slack

Le fil #release Slack est posté hebdomadairement et spécifie quels feature flags sont activés pour la version. C'est critique pour deux raisons :

• Inclure : Seuls les changements visibles à l'utilisateur dont le feature flag est activé dans cette version (ou qui n'ont pas de flag) doivent apparaître dans les notes.
• Versions serveur — suppressions de flags : Quand un feature flag est totalement supprimé du codebase serveur, cela signale que les utilisateurs auto-hébergés gagnent accès à la fonctionnalité. Celles-ci doivent apparaître dans les notes de version.

Demander à l'utilisateur de coller le contenu du fil.

Parser le fil pour en extraire :

• Version de release et date
• Liste des flags étant activés pour cette version (par plateforme si spécifié)
• Liste des flags étant supprimés (pour les versions serveur — capturer l'identifiant du flag et toute description de fonctionnalité associée du ticket ou du fil)
• Toutes notes PM ou ingénierie sur ce à souligner ou supprimer

Étape 2 : Déterminer la portée de la version

Identifier :

• Quel repo/produit est en cours de release (clients, serveur, mobile, extension navigateur, CLI, desktop)
• Quelles plateformes sont couvertes (web app, desktop, extension navigateur, mobile iOS, mobile Android, CLI)
• Numéro de version de la release

Si la release couvre plusieurs repos avec des notes de version séparées (par ex., clients et serveur ont chacun leur propre GitHub release), confirmer avec l'utilisateur s'il veut les notes pour tous ou pour un seul.

Étape 3 : Filtrer vers les changements visibles à l'utilisateur

Passer en revue chaque ticket de la version et le classifier. Seuls les éléments passant le filtre apparaissent comme des points nommés.

Inclure comme point nommé

• Nouvelles fonctionnalités ou capacités visibles à l'utilisateur
• Changements UI ou UX que les utilisateurs remarqueront
• Changements de politique et paramètres admin (y compris nouvelles options d'application)
• Améliorations de performance que les utilisateurs percevront
• Améliorations d'accessibilité significatives
• Nouveaux flux d'onboarding, visites produit, ou assistants de configuration
• Changements de flux de checkout, facturation, ou abonnement
• Éléments dont le feature flag est confirmé activé dans le fil Slack de cette version

Regrouper dans la ligne de rattrapage

• Refactorisation interne, nettoyage de code, ou changements d'architecture sans effet visible à l'utilisateur
• Mises à jour de dépendances sans changement visible à l'utilisateur
• Ajouts de couverture de test
• Instrumentation de logging, télémétrie, ou analytics
• Éléments derrière un feature flag qui n'est pas activé dans cette version
• Petits changements de texte ou label ne valant pas leur propre point
• Corrections de bugs trop étroites ou cas limite pour être significatives pour la plupart des utilisateurs

Toujours inclure (jamais regrouper) — versions serveur uniquement

Feature flags étant totalement supprimés du codebase serveur dans cette version. La suppression d'un flag est le moment où les utilisateurs auto-hébergés gagnent accès à une fonctionnalité. Rédiger chaque suppression comme une ligne visible à l'utilisateur décrivant ce que la fonctionnalité fait — pas l'identifiant interne du flag. Voir Étape 4 pour le format.

Exclure entièrement

• Corrections de sécurité, sauf si le fil Slack ou l'utilisateur approuve explicitement une formulation spécifique pour une (par défaut, exclure tous les correctifs de sécurité des points nommés)
• Changements d'outils internes sans impact utilisateur
• Changements dupliqués ou annulés

Étape 4 : Rédiger les notes de version

Règles de format

• Texte brut uniquement — aucun markdown, aucun astérisque, aucun en-tête, aucun caractère de puce
• Une ligne par changement notable
• Commencer chaque ligne par un verbe au passé : Ajout, Mise à jour, Correction, Amélioration, Suppression
• Rédiger du point de vue de l'utilisateur — qu'a-t-il gagné, perdu, ou remarqué ?
• Pas de numéros de ticket Jira, pas de terminologie interne, et critiquement : pas d'identifiants de feature flag
• Garder chaque ligne sous ~12 mots
• Viser 3–7 points notables maximum, suivi d'une ligne de rattrapage
• Terminer par : Diverses améliorations en arrière-plan et corrections mineures

Ton

Informatif, bref, orienté bénéfice. Éviter les superlatifs marketing (« excitant », « puissant »). Éviter le jargon ingénierie (« refactorisé », « migré », « échafaudé », « déprécié »). Rédiger pour un utilisateur non technique qui veut savoir si quelque chose a changé qui l'affecte.

Suppressions de flags serveur

Les lignes de suppression de flags décrivent la fonctionnalité que le flag gardait, dans un langage clair visible à l'utilisateur. Rechercher le ticket Jira associé, la page Confluence, ou la description du fil Slack pour trouver le bon cadrage. Le nom de flag interne est une clé de recherche uniquement — il n'apparaît jamais dans la sortie.

Utiliser le format :

Removed feature flag for [description visible à l'utilisateur de ce que la fonctionnalité fait]

Exemple : un flag nommé pm-36859-refactor-org-collections-vault-component devient :

Removed feature flag for organization vault collection management improvements

Les utilisateurs auto-hébergés sont l'audience principale pour cette ligne — ils reçoivent la fonctionnalité pour la première fois quand le flag est supprimé, donc la description doit communiquer le bénéfice clairement.

Exemple de sortie (release clients)

Updated UI for centralized ownership policy
Added a product tour for access intelligence
Added information banner to SCIM setup page
Added a checkout success page following Stripe payment flows
Various under-the-hood improvements and minor bug fixes

Exemple de sortie (version serveur avec suppressions de flags)

Added support for flexible collection permissions for enterprise plans
Improved admin console filtering for large organizations
Removed feature flag for flexible collection permission management
Removed feature flag for bulk collection management improvements
Various under-the-hood improvements and minor bug fixes

Étape 5 : Réviser et calibrer

Avant de présenter la sortie finale, vérifier :

• [ ] Chaque point nommé a son feature flag correspondant activé dans le fil Slack (ou n'a pas de flag)
• [ ] Aucun changement interne ou d'infrastructure uniquement n'apparaît comme point nommé
• [ ] Les versions serveur incluent une ligne pour chaque suppression de flag mentionnée dans le fil Slack, rédigée dans un langage visible à l'utilisateur
• [ ] Aucun identifiant de flag interne n'apparaît nulle part dans la sortie
• [ ] Total de points nommés entre 3 et 7 (si plus de 7 sont équalement importants, consolider les items similaires)
• [ ] La ligne de rattrapage est présente
• [ ] Aucun formatage markdown dans le texte de sortie