Release notes are a tiny but vital component of the release cycle. Release notes tend to be important because they form the core of the communications between product team & the other stakeholders.
Apart from out of the box (but limited) options available in Jira, there are various ways one can generate release notes. We have developed an app for Jira (earlier called as add-on/plug-in) that automates the process of release notes generation, formatting & dispatch. You can take a look at it here – Automated Release Notes for Jira
What are some best strategies to read confluence as a team, when there is a huge set of documents and having a team of good size?
- Use the page hierarchy to go into increasing detail. The parent page gives an overview, with child pages to expand on specific topics. Repeat recursively. That way readers can easily just read the overview or can dive into specific detail.
- Give pages titles that can be used in sentences on other pages. For example, everything in your organization that has a name should have a page with the name as its title. Then whenever someone mentions one of those on a page, they can press it to make the name a link. That way readers can find out more about something if they need to, at the point where it is mentioned.
- Don’t use blog posts for reference material like procedures/guides. A blog post is a point-in-time announcement. Reference pages will change over time, and you want anyone using them to be able to edit them to fix errors or omissions. No one edits a blog post, except possibly the author adding notes.
- Use chunking and labelling to break up content into digestible blocks with clear signposts. Put in a {toc} macro to jump to any heading. That way readers can quickly find what they need without having to read the entire page.
Don’t use a team/project space for long-lived content. If you want to capture information about something that will live beyond the life of a team or project, put it into a space that’s not owned by the team or project. Put it in a topic space that isn’t owned by one group of users. That way a new team or project is less likely to document it all over again, and readers are more likely to keep it up to date.
