Okay, I did promise a follow-up with details on stuff like writing news, right? Time to keep that promise.
Writing news was my first real job back in 2000. Before that I only did some occasional translation and interpreting. After that it merged 
Here are some observations I can share with you.
The usually referred rule of “knowing your audience” is a very tricky thing. If you are software developer, you are rarely dealing with just one group of users. Let’s see:
New users who don’t know much about this kind of applications. Writing news for them is a nightmare for a developer, because the two sides have very little in common. They tend to skip paragraphs when amount of unknown terminology grows exponentially. A baby talk is out of question, because it’s a) offensive and b) inappropriate for other groups of users.
New users who know about this kind of applications. This group is much easier to deal with. You have similar background, you speak same “language”, yet all the details about your application are currently irrelevant for these users, because they have no experience with it.
Experienced users. The closest group of people to you apart from fellow developers. They don’t expect lengthy introductions, they just want details. Why?
Because the news is a tool for assisting decision making. Let me explain why and how.
When you visit a software project web page, you make a decision on what to do next: read more about the application, download the most recent version, download stable version etc. or just close the tab and go elsewhere. There are many criteria that affect decisions, and news is one of the important ones, because users expect being taken care of in return for paying close interest to a piece of software. They expect service, and if there is no recent news or the news is poorly written, it means no service. This is about investing time and efforts. I’ve seen many times how people first stumbled upon a web site of a project that had active internal life, saw no or rare and scarce news items and moved on, thinking it was abandoned.
So you release source code and then people expect you to do some extra work in return for their attention. Just how crazy is that? Not crazy at all. A happy user base means steady flow of bug reports and feature requests that are foundation of iterative improvements. A user who feels that (s)he’s been taken care of is likely to be forgiving some mess in the application and inclined to follow your work. And this is how backbone of communities grows. Look at Inkscape: terrible performance on complex drawings and yet an evergrowing community of users who are attached to the project.
But obviously you can’t write different news for different groups of users. Here is an advice: use the sandwich principle.
Start news with a teaser — a short overview of changes, e.g. “We’ve just released a new version of %APPLICATION% with major changes, including new features requested by our user community” or “A minor version of %APPLICATION% fixes a number of bugs reported by our users”. If you decompose any of the two examples into basic messages, you’ll see exactly this:
- Hey, there is a new version, the project is alive!
- Look, they have a community!
- Whoa, they actually care about what community says!
At this point, if the project itself is rather interesting, the decision will be likely to stay longer. The first group of users will probably not go for the rest of the sandwich, but they will get the message: “If you stay, we’ll take care of you”.
And then you can go for the bread of the sandwich: actual changes in the new version. Which will be discussed in the next post.
The unavoidable question would be, again, how much of that relates to small software projects that have a couple of dozen of followers and few releases a year. Actually, it’s the same except you get a lower amount of bug reports and feature requests, because you still deal with people who invested time or might invest time into learning your application.
When you release new versions seldom or are just busy pushing changes to Git repo at a speed of light, the trick is to establish a kind of encouragement to dialog between your users and yourself. The latest news could says something in the lines of “As far as we know this version works on most modern systems like X, Y and Z without any major flaws and does most things it should. We are not going to release updates a while, unless you encounter an issue with a newer version of these systems or come up with an interesting feature request” or “We are superbusy implementing hot stuff to make you happy as never before. Feel free to join the mailing list or IRC channel to find out more”. It’s not as good as releasing maintenance versions with tiny changes or providing nightly builds to say “Hey, we are still in business”, but you’d be building a rather good bridge to the user base nevertheless. Which is a very human thing that is appreciated.