Comment faut-il écrire les notes de publication?
Existe-t-il des directives ou des pratiques optimales sur la rédaction des notes de publication? Je suppose que j'essaie de trouver le juste équilibre entre faire valoir le point sans être trop spécifique. De plus, les développeurs fournissent-ils généralement beaucoup plus de notes de publication pour l'équipe d'assurance qualité que celles soumises au public?
Les notes de publication publiques doivent contenir au moins:
- release, buildnumber
- tous les bugs publics corrigés
- toutes les fonctionnalités publiques ajoutées
Les notes de version de QA doivent contenir au minimum:
- release, buildnumber
- tous les bogues corrigés, y compris le numéro de bogue
- toutes les fonctionnalités ajoutées, y compris les liens vers les documents de conception
Pensez à votre public et essayez de penser à ce dont il a besoin.
Une autre chose à ajouter est le support nouveau ou interrompu pour certaines plates-formes. (Par exemple, nous quittons le support pour Win3.1 et ajoutons Vista 64 bits).
Si vous avez un système de gestion de projet/suivi des problèmes, vous devriez certainement l’utiliser pour générer vos notes de publication. Trac et Redmine en particulier sont très bons à cela.
Les points de publication doivent avoir quelques propriétés, IMO:
- N'oubliez pas votre public. S'il s'agit d'une application iPhone, peu de gens vont se soucier du fait qu'une erreur de logique particulière sur la ligne 572 de la classe Foo a été corrigée. Mais ils se soucient beaucoup de "l'application est maintenant sensible à l'accéléromètre".
- Résumez les nouveaux développements, fonctionnalités et corrections de bogues de manière aussi large que possible. Si vous pouvez les lier de manière thématique (par exemple, "nous avons implémenté les génériques et les types anonymes"), une brève présentation à ce sujet est un bon moyen de donner aux gens une vue d'ensemble.
- Détaillez les problèmes spécifiques qui ont été corrigés, avec des liens vers votre outil de suivi des bogues public, le cas échéant Cela peut généralement être généré automatiquement.
- Ne fournissez pas de détails atroces. Des résumés à une ou deux lignes de chaque élément ajouté ou corrigé devraient suffire.
- Incluez toujours des identificateurs de version spécifiques (par exemple, "v.1.4.5"), selon le cas.
Cela dépend vraiment de l'auditoire . Pour les utilisateurs techniques (par exemple, les développeurs qui utilisent votre API), vous pouvez être très technique . De l'autre côté, les utilisateurs finaux de haut niveau d'une application que vous avez créée ne sont peut-être intéressés que par nouvelles fonctionnalités et changements majeurs.
Entre les deux, se trouvent des utilisateurs non techniques qui ont également besoin des détails, par exemple le service d'assistance. Pour ces personnes, vous pouvez donner une description détaillée sans les détails techniques de bas niveau, par exemple "Correction d'un bug qui empêchait l'enregistrement de l'enregistrement dans la base de données.".
À mon avis, l'une des meilleures pratiques avec les notes de publication est l'automatisation. S'il existe certaines pratiques recommandées pour l'envoi de messages par le système de contrôle de révision ( http://drupal.org/node/52287 ), vous pouvez créer des notes de publication à l'aide d'un script automatisé ( http: //cvs.drupal. org/viewvc.py/drupal/contributions/astuces/cvs-release-notes/ ). Cela créerait vraiment des notes de publication de Nice: http://drupal.org/node/226165
Le principal contributeur de Notes de publication serait votre équipe de développement. Il est recommandé de permettre à vos développeurs et testeurs de capturer toutes les informations relatives aux notes de publication par rapport à vos éléments de travail liés aux ensembles de modifications de TFS.
Ensuite, vous pouvez utiliser un projet open source tel que http://tfschangelog.codeplex.com pour générer des notes de publication. Il comporte une version graphique et une version en ligne de commande facilitant la planification des rapports de notes de publication tous les soirs.