...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
...
First Principles
Great release notes for an open-source product should have the following characteristics:
Clarity: Release notes should be written in a clear and concise language, avoiding technical jargon and explaining complex changes in simple terms.
Completeness: Release notes should be complete and cover all the changes, bug fixes, and new features in the release.
Relevance: Release notes should prioritize information that is relevant to the users, highlighting the most important changes and their impact. For each note, it's clear which users will find it most relevant.
Usability: Release notes should be easy to read and navigate, using headings, bullet points, and descriptive labels to organize the information.
Timeliness: Release notes should be published in a timely manner, soon after the release is made available, to keep users informed about the latest developments.
Accessibility: Release notes should be accessible to all users, including those with disabilities, by using accessible text formats and including alternative methods of accessing the information.
Meeting notes
Meeting notes
Where to add link to releases
...
Quick Introductions
Overview
Q1. What is beneficial about our current release notes Morning Glory (R2 2022) Release Notes?
- Content (plain language) to explain issues
- Sorted by area of functionality (first table)
- Easy to contact the person responsible for each area (easy to sort/group)
Q2. What is unclear about our current release notes?
- Not scannable/ Not easy to find things
- Descriptions are not detailed enough when posting a JIRA link. Need to provide more details.
- Comment column is not used
- Group: What needs to be done before a release upgrade Then another group for during and Then another group for after
- Group by functional area
- added by MF after meeting: hard to find the release notes in the first place, no link on main wiki page https://wiki.folio.org/ for Nolana release notes
- added by MF after meeting: for sections that are generated from JIRA issues, like the "Additional Known Issues" section in Nolana release notes, it isn't obvious that only the first 20 (or however many rows) are shown, and if there are more than 20, you have to do another click to see the full list of issues 2.2 - KG made change
- MF / GG: High level descriptions don't include additional narrative to provide context. For example, "this is a long awaited feature" or "this feature is connected to the bug that was first reported at first date"
Q3. What is missing with our current release notes?
- A way to engage with release notes? Be able to make a comment / ask a question.
- Maybe a release Kanban board
Q4. Have you reviewed release notes from other products/companies that you thought did a great job? If, so, please post links.
- Noora
- https://roadmap.thestorygraph.com/changelog
- https://miro.com/changelog/ these are weekly product updates, vs batched in releases, but I especially like how they have animations playing that show what the new features are, without the reader having to click to get more info. (MF)
- https://help.oclc.org/Discovery_and_Reference/WorldCat_Discovery/Release_notes/2022_release_notes/045WorldCat_Discovery_release_notes_November_2022 What I appreciate with the WCD release notes are the screenshots with notations showing exactly what's changing in the interface. Obviously only useful for some things in a FOLIO release and a completely smaller scale than our FOLIO updates too; so many not be practical.
...