Improve Release Announcements to better serve Developers Interests
Open, Needs TriagePublic

Description

Rationale

Some developers were justifiably annoyed that the notes they had made for the Applications 19.08 release had been cut out of the final published version of the announcement.

However, data from past announcements show that a more accessible, mor digestible (=shorter), article-like format gets the release announcement more coverage in external outlets. This is something Promo has to work towards as per our goals.

To achieve the goals of Promo (maximizing coverage for KDE in general) and those of individual projects (getting more coverage for their applications and the work they carry out on them), we are carrying out this task.

Procedure

During the BoF we held during Akademy 2019, we discussed three ways we could make announcements fairer for the work developers do, giving them the recognition they deserve, while still maintaining the more accessible and copy-pasteable format we started to move to in 19.04.

These are the ideas we came up with:

  • Seek out and talk to developers who submit to the notes document and discuss their work. Explain one-to-one the criteria we use (see below) so they are aware of what we are looking for.
  • Ramp up the level of detail one notch from the Apps 19.08 announcement to cover more of developers' work. The level of detail included in 19.04 seems to have hit the sweet spot.
  • Add links to projects' home pages from the changelog (can this be done automatically?) so they benefit from more traffic.
  • Retroconning: using small changes to tell/remind users about applications they may not know about.
  • Make the criteria Promo applies to choose content explicit so developers can think about and reformulate their notes in a way Promo can use.

Current criteria looks something like this:

We tend to favour "interesting" over the "important". "Important" here referst to "every change, big or small that improves the software, contributing to its stability, usability, improving its usability, and/or adding useful features".

"Interesting", on the other hand, are changes that we can use to explain easily, concisely and often visually how the users benefit without having to give massive background explanations. A change can be both important and interesting, of course, in which case it is sure to be mentioned.

"Interesting" and "important" are not absolutes. They are more of a scale and you can also move a change from not-interesting to interesting by reframing it in such a way so that the effects of the change can be clearly shown to the users.

Here are some examples:

Important (but not very interesting)
  • Squashed bug stops slider from turning green on Thursdays
  • Changed from X framework to Y framework to make application future proof
  • Added the size of the file on the disk info to the status bar
  • Moved feature A from X menu to Y menu to improve usability
Interesting
  • Application no longer crashes when opening graphics in the CMYK colorspace (very annoying and dealbreaking bug corrected)
  • Application supports X file format, which is an industry de facto standard
  • Application got collaborative editing

TODO

  • Invite in developers (for example, the people from Cantor) for feedback
  • Discuss and brainstorm the above: What else can we do?
  • Formalise into a policy and put it on the wiki
paulb created this task.Sep 24 2019, 12:34 PM

Expanding a bit on the fact that the line between important and interesting may be not absolute, I think that any of items on the "Important (but not very interesting)" list become interesting if they were associated to a bug which had a relevant number of votes/reactions.

ognarb added a subscriber: ognarb.Sep 24 2019, 1:03 PM

I think it could also be interesting to compare the dot article to the announcement and the release announcemen in kde.org.

https://dot.kde.org/2019/08/15/kde-applications-1908-brings-new-features-konsole-dolphin-kdenlive-okular-and-dozens
https://kde.org/announcements/announce-applications-19.08.0

That are the goal of this two different but still similar announcements?

paulb added a comment.Sep 24 2019, 1:27 PM

I think it could also be interesting to compare the dot article to the announcement and the release announcemen in kde.org.

https://dot.kde.org/2019/08/15/kde-applications-1908-brings-new-features-konsole-dolphin-kdenlive-okular-and-dozens
https://kde.org/announcements/announce-applications-19.08.0

That are the goal of this two different but still similar announcements?

Agreed.

  • Changelog tells readers everything
  • Announcement focuses on changes and how they affect users. Minor changes or overly technical details are left out (which doesn't mean we don't consider them important -- it is more to increase readability of the text).
  • Dot article would be the five-minute, reader's-digest version of the announcement, 3 or 4 paragraphs long
paulb added a comment.Sep 24 2019, 1:31 PM

Expanding a bit on the fact that the line between important and interesting may be not absolute, I think that any of items on the "Important (but not very interesting)" list become interesting if they were associated to a bug which had a relevant number of votes/reactions.

Oh yes. If this is, say a long standing bug enough people have been complaining about, then it immediately becomes "interesting". That said, if enough people are complaining about it, then it would usually be because a very visible and probably a deal-breaking bug, like the "application crashes when opening graphics in the CMYK colorspace" mentioned above.

But, agreed: point taken.

Personally I really enjoyed reading the release notes from 19.08 and was also impressed when I saw them the first time.
I was really cool and pleasant to have this full text which covers the most interesting part. After finishing I always take look into the full release notes to dive deeper into it.
What about combining those two formats? Cover the interesting parts with floating text and the important ones underneath it with bullets like it was with 19.04 and before.


Maybe make the link to the full changelog/release notes also more prominent?

As discussed at the BoF on KDE Applications at Akademy there is the idea to replace KDE Applications with a de-branded Release Service and instead of announcing that having monthly 'this month from KDE' app announces. This could coincide with the Release Services releases in the months when they happen.

That doesn't really answer the question of how much or how little should be included in them though.

https://marc.info/?t=156872681800005&r=1&w=2

paulb added a comment.Sep 24 2019, 4:06 PM

Personally I really enjoyed reading the release notes from 19.08 and was also impressed when I saw them the first time.
I was really cool and pleasant to have this full text which covers the most interesting part.

Good to hear. This was the aim. But, as mentioned above, we left stuff out without consulting some of the developers. These developers were logically annoyed. We want to avoid overlooking poeple's work while at the same time sharing the information in a the most friendly style and format possible.

After finishing I always take look into the full release notes to dive deeper into it.
What about combining those two formats? Cover the interesting parts with floating text and the important ones underneath it with bullets like it was with 19.04 and before.

Okay. Will look into that too. Great suggestions.

Maybe make the link to the full changelog/release notes also more prominent?

Okay. Point taken. Putting it at the beginning as well as at the end and including the links to the projects from the changelog may compensate.

paulb added a comment.EditedSep 24 2019, 4:12 PM

As discussed at the BoF on KDE Applications at Akademy there is the idea to replace KDE Applications with a de-branded Release Service and instead of announcing that having monthly 'this month from KDE' app announces. This could coincide with the Release Services releases in the months when they happen.

I didn't realise that this would supersede the quarterly KDE Applications releases. Does this render this discussion moot?

That doesn't really answer the question of how much or how little should be included in them though.

Well, it kind of does help: As you mention in the linked emails, a monthly report would necessarily pack less info than a quarterly announcement, so you would be able to go into more detail.

Is this is a sure thing? If so, when is it going to start?

paulb updated the task description. (Show Details)Sep 24 2019, 4:33 PM

As discussed at the BoF on KDE Applications at Akademy there is the idea to replace KDE Applications with a de-branded Release Service and instead of announcing that having monthly 'this month from KDE' app announces. This could coincide with the Release Services releases in the months when they happen.

I didn't realise that this would supersede the quarterly KDE Applications releases. Does this render this discussion moot?

Not moot but part of the same discussion.

That doesn't really answer the question of how much or how little should be included in them though.

Well, it kind of does help: As you mention in the linked emails, a monthly report would necessarily pack less info than a quarterly announcement, so you would be able to go into more detail.

Is this is a sure thing? If so, when is it going to start?

As sure as anything, someone just needs to take the lead and plan it, which I might do if I get time.

Let's try an october one next week
https://phabricator.kde.org/T11809

paulb added a comment.EditedOct 1 2019, 2:44 PM

Let's try an october one next week
https://phabricator.kde.org/T11809

Sorry... Let's try an October... what?

An App Update announce on the Dot

paulb added a comment.Oct 1 2019, 3:40 PM

An App Update announce on the Dot

Right. So we're talking about one of these shorter ones you mentioned, yes? Reporting on a small incremental release. Because a full release is not due until December, correct?

The idea is to have a monthly article listing all the releases made by KDE in the last month

paulb added a comment.Oct 1 2019, 4:04 PM

So will there be a Applications 19.12 release or was 19.08 the last one?

I would hope that for 19.12 it will be de-branded to become the Release Service

ognarb added a comment.Oct 2 2019, 1:08 PM

My fear with a release service happening every month and having most of our apps release every 4 months, is that we will have every 4 months a very big announcement and otherwise only a small announcement. Maybe it's not a problem, I don't know...

Yeah it will cause an unbalance, but looking at the list of changes so far it'll be a decent article

paulb added a subscriber: ngraham.Oct 2 2019, 3:54 PM

Let's try what @jriddell suggests.

On one hand, quarterly big announcements have worked for us: they drum up excitement and give readers something to look forward to. But these peaks tail of quite sharply.

SO

On the other hand, more frequent updates on progress in app development may give us a more consistent and longer sustained flow of traffic and interest that will gradually grow, like what @ngraham has managed on his blog. We have not figured out how to grow traffic to the Dot yet (whether we need to do that is another discussion) and this may help.