Presentation: How to Win Friends and Influence People with Release Notes
This talk will present 5 ways in which release notes can be improved and used to attract attention, draw in new users, and motivate people to contribute to your project. The advice presented in the talk will be supported by research and observations on various FLOSS communities, but also on proprietary software. The goal is to convince developers and project maintainers that release notes are an incredibly valuable tool that should not be dismissed as an afterthought.
"Bugfixes and improvements."
Those three notorious words have almost become a meme in software development circles, and could easily be blamed as one of the main reasons why users don't read release notes, or consider them largely useless.
But it doesn't have to be like that.
Release notes are an important part of the software release process, and they play a big role in promotion as well. Transforming them into something that the users will enjoy reading and look forward to is not only possible, but also desirable. There are different ways to create release notes, and while developers usually look for the easiest, most automated way to save time, it's worth investing a bit more into their quality by giving them a human touch. This approach opens up an opportunity to involve non-coding contributors in your project - people who can write well and give feedback from an end-user's perspective.
The advice that will be presented in this talk can apply to any software project - FLOSS or not - but more importantly, it can be used to include various KDE projects into the the KDE Community goal "Streamlined Onboarding of New Contributors", as well as to increase the KDE Community's reach through promotion efforts.
One of the sessions at Akademy 2013 was dedicated to improving the release notes of KDE projects. Five years later, it would be interesting to revisit the conclusions and advice of those sessions. I intend to contact the contributors who participated in them, and compare how KDE projects used to approach release notes then versus how they approach them now.