Senarai commit mungkin mengandungi fix null, refactor modal dan update copy. Semua itu membantu pembangun mengesan kerja, tetapi pengguna ingin tahu perkara lain: apa yang kini boleh dibuat, apa yang berubah dalam aliran mereka, dan adakah mereka perlu mengambil tindakan.
Semasa menulis release notes, kumpulkan perubahan mengikut kesan kepada pengguna. “Carian blog kini boleh mencari tajuk dan ringkasan” lebih jelas daripada “add query filter”. Sebut pembetulan yang menyelesaikan masalah nyata, serta perubahan yang mungkin membuat orang mencari butang di tempat lama. Jangan menjanjikan ciri yang masih hanya wujud pada branch pembangunan.
Semak apa yang benar-benar dideploy
Git menunjukkan niat dan sejarah, tetapi build boleh gagal atau deploy mungkin tertunda. Bandingkan commit keluaran dengan rekod deployment sebelum menerbitkan nota. Jika satu ciri bergantung pada konfigurasi luar, uji aliran di produksi. Catat juga isu yang masih diketahui jika ia memberi kesan kepada pengguna.
Minta seorang bukan pembangun membaca nota keluaran sebelum diterbitkan. Tanya apa yang dia fikir berubah dan sama ada perlu melakukan sesuatu. Jika jawapannya berbeza daripada niat pasukan, tukar bahasa nota itu. Release notes ialah komunikasi produk; pembaca tidak sepatutnya perlu mengenali nama class untuk memahaminya.
Release notes pendek yang jujur membina kepercayaan. Ia memaksa pasukan melihat perubahan dari sudut orang yang menggunakan produk, bukan hanya dari sudut fail yang disentuh sepanjang minggu.