Rédiger des notes de version à partir des pull requests, sans publier d’informations internes
Demandez à Beeuni de lire un dépôt GitHub connecté, de vérifier la plage de versions et de rédiger des notes destinées aux utilisateurs, avec des références aux modifications.
Une pull request intitulée « Refactoriser le processus d’exportation » indique à une personne chargée de la revue où regarder. Elle apprend très peu de choses à un client. Les notes de version doivent expliquer ce qui a changé dans le produit, qui est concerné et si la modification est disponible dans cette version.
Déterminer ce qui figure réellement dans la version
Donnez à l’agent accès au dépôt via votre connexion GitHub configurée. Demandez-lui de trouver les balises précédente et actuelle, de comparer leurs commits et d’examiner les pull requests associées. Indiquez vous-même le dépôt et les balises si plusieurs versions sont en préparation.
Read the connected repository and compare v1.4.0 with v1.5.0.
Draft release notes for users, grouped into features and fixes.
Inspect the linked PRs and diffs rather than relying on titles alone.
Keep a separate list of internal changes, reversions, and uncertain availability.
Save the draft with PR references. Do not publish a release.Une PR fusionnée n’est pas nécessairement déployée, et une modification fusionnée au cours de la même semaine peut être destinée à une version ultérieure. La comparaison des balises permet de déterminer quel code est inclus. Il peut toutefois être nécessaire de vérifier auprès de l’équipe l’état des indicateurs de fonctionnalité et du déploiement progressif.
Demandez à l’agent de créer une liste de travail privée indiquant la PR source, le comportement modifié, les utilisateurs concernés et la présence éventuelle de la modification dans la version. Vérifiez les modifications annulées et les fonctionnalités qui restent désactivées. Tant qu’une personne ne les a pas confirmées, excluez les éléments incertains du brouillon public.
Passer des détails d’implémentation aux changements destinés aux utilisateurs
Ces exemples de notes de PR illustrent quelques choix de rédaction courants :
| Note de travail | Brouillon des notes de version | Choix éditorial |
|---|---|---|
| Enregistrer les filtres sélectionnés dans les paramètres de requête | Les vues filtrées conservent désormais leurs filtres lorsque vous partagez le lien. | Décrire le comportement visible |
| Corriger les doubles envois lors d’un double clic | Correction d’un problème qui pouvait créer des demandes en double lorsque l’on cliquait deux fois sur Envoyer. | Indiquer le déclencheur et son effet |
| Réorganiser les utilitaires de test | À omettre des notes publiques | Conserver les modifications de maintenance dans le suivi interne |
| Ajouter l’exportation derrière un indicateur de fonctionnalité désactivé | Attendre que l’exportation soit disponible | Confirmer la disponibilité avant d’annoncer la fonctionnalité |
Organiser les notes selon les besoins des lecteurs
Si la version le justifie, utilisez des rubriques telles que nouveautés, améliorations et corrections. N’affichez pas de titres vides. Regroupez en une seule entrée les PR qui contribuent à une même fonctionnalité. Présentez séparément les corrections distinctes lorsqu’elles concernent des actions différentes.
Ne dissimulez pas les actions requises dans une rubrique générale sur les améliorations. Si un champ d’API change, indiquez l’ancienne et la nouvelle forme, et ajoutez un lien vers les instructions de migration. Si le comportement change uniquement pour certains comptes ou clients, précisez qui est concerné. Demandez au responsable de la fonctionnalité de confirmer ces détails.
Conserver les références à l’appui du brouillon
- Gardez les références aux PR ou aux commits dans la version de travail, même si elles ne figurent pas dans les notes publiques.
- Vérifiez que chaque fonctionnalité annoncée est disponible dans la version décrite.
- Supprimez les noms d’hôtes internes, les identifiants, les informations sur les clients et le contenu de tickets non publiés.
- Remplacez les affirmations comme « plus rapide » par une description précise du comportement, sauf si vous disposez d’une mesure à citer.
Demandez deux fichiers : le brouillon public et la liste de travail indiquant les éléments inclus, exclus et non résolus. Après révision, vous pouvez demander à l’agent de mettre à jour le brouillon dans le dépôt, si la connexion autorise cette écriture. La publication de la version nécessite une instruction distincte. Si les notes indiquent qu’un bogue de formulaire est corrigé, le guide de test du site web décrit le relevé de reproduction que vous pouvez utiliser pour vérifier cette affirmation.
Autres articles
Infrastructure pour la recherche sur l’auto-amélioration récursive : exécuter et évaluer des agents qui s’améliorent
Comment Beeuni aide à mener des expériences successives d’amélioration des agents : modifier le code et les instructions, lancer les tests, examiner les échecs et comparer les versions.
Utiliser Beeuni pour mener et évaluer une expérience de réglage fin d’un modèle
Demandez à un agent de préparer les données d’entraînement, de lancer une tâche de réglage fin sur l’ordinateur d’entraînement auquel vous l’avez connecté, d’examiner les échecs et de comparer les résultats du modèle.