Where possible, it would be great if we could get some screenshots/gifs of the cool new features like we had for the 17.12.0 announcement.

Don't know if that is automatically included somehow: There is a new application in kde utils: kbackup

Yes thanks! I'm taking in mind the info from here also: https://community.kde.org/Applications/18.04_Release_Notes

I've started a (very early) draft here: https://notes.kde.org/p/applications_18.04.0_announcement

I can call this a beta1 now: https://notes.kde.org/p/applications_18.04.0_announcement.

Pending issues:

• We only have a gif and a screenshot for Kleopatra, can we get something similar from the other apps as well?
• The Kmail features from @mlaurent haven't been filled in.
• Under which section should I include "baloo-widgets"?

Feedback and corrections always welcome. =)

Thanks Neofytos! I've done a bit of editing, but this is looking really good. I think the baloo-widgets features and bugfixes should be mentioned under the system category, and maybe even in the Dolphin section.

Hi @ngraham, thanks for your input and edits.

So far we preferred paragraphs over bullet points, the former being the time consuming part of writing these announcements since bullet points are rather well written by the developers themselves. My understanding is that a flowing text would be more appealing to people. I also noticed you replaced "our" with "KDE", I used the former to emphasize the community aspect of KDE. Do you have specific reasons for doing these changes? I don't have a strong opinion on either, just trying to understand the reasoning and figure out what suits us better. =)

I thought the bullet points made it a bit easier to read. When everything is in paragraph form with no line breaks or bottom padding between paragraphs, the text can become a big indistinct block. But I don't have strong feelings on the matter, and if paragraphs better matches the final formatting (especially if there will be reasonable whitespace between paragraphs), then I'm fine with it.

As for "our" vs "KDE's", my thinking was that these announcements could be an opportunity to reinforce the branding that "KDE" refers to the community itself, at least in the "Announcement text" section. The word "our" could work in the subsequent sections.

In the spectacle section, this part has a typo (buton) and is not really understandable:
"... and how displays a buton to open the Settings window..."

or should "how" be "now" ?

I was going to edit this text, but I've seen the bit about bullet points vs. paragraphs, so I don't want to undo other contributors' effort by converting everything back to paragraphs.

The reason why I prefer paragraphs is because a list of bullet points doesn't really tell a story. That approach makes our announcements look like glorified release notes. I like to combine related points into sentences, separate more technical details into their own paragraph, and start with a lighter intro...but yeah, as I said, we should probably go with your approach this time, since so much work has already been done on the text.

And fantastic work, by the way! I'll take one final look and let you know if I find any typos or major issues.

well for kdepim, we add bullet points and would be happy if others will change this to a nice paragraphs...

@neofytosk Thanks for working on this, looking pretty good already!

There are now some screenshots linked in T8426 and T8427. Feel free to include some of them, or ask for additions or changes which we would be happy to provide. I guess it would be best to copy the screenshots over to www.kde.org instead of linking to the version on Phabricator, though.

@skadinna I guess it's all about improving the text for the use case of cursory reading. A wall of text is not optimal in that regard, and too many bullet points are neither. Do you have a good idea for a compromise, i.e. how to best group the bullet points into larger, yet still accessible sections?

In T8357#136718, @mkoller wrote:

In the spectacle section, this part has a typo (buton) and is not really understandable:
"... and how displays a buton to open the Settings window..."

or should "how" be "now" ?

Thanks, fixed.

I'm fine with paragraphs as long as it's legible and doesn't look like a wall of text.

@dhaumann Any new features or important bug fixes for Kate which should be added to the announcement?

When I am converting bullet points into paragraphs, I try to group them by common subjects. For example several bullet points might all be about full screen mode, others are about usability fixes or about SVG images.

Another thing that I find works is to target groups of users or actions, for example "if you are moving files, this and this will make it easier for you."

We are talking technical things here, and it's very often than you have 5-6 different features/fixes that have no overlap between them. So it's hard to make everything sound exciting in that way.

To avoid longer text, we could choose only 3-4 points per application that we consider significant/attractive and link to a full changelog for the rest, similar to what is already done for Plasma bugfix releases.

Or a hybrid. Talk about some interesting things first, then add a list like: "Further improvements in <Appname>: * Item 1 * Item 2 * Item 3".

In T8357#136881, @cfeck wrote:

Or a hybrid. Talk about some interesting things first, then add a list like: "Further improvements in <Appname>: * Item 1 * Item 2 * Item 3".

I like this approach TBH. We can make an educated guess what the most important features are, but to assume that one of those * Item X * points might not be an exciting thing to someone's workflow would be perhaps a bit short-sighted.

In T8357#136935, @James wrote:

I like this approach TBH. We can make an educated guess what the most important features are, but to assume that one of those * Item X * points might not be an exciting thing to someone's workflow would be perhaps a bit short-sighted.

That's a very good point. On one hand, it's sometimes safer to assume that "X doesn't crash when opening files" will have a larger impact on the majority of X's users than let's say "X gained another shortcut to perform an action". On the other hand, you never know what might be the one thing that really affects peoples' use cases or frustrates them, or how much effort the developer put into fixing it and you simply ignore it. I'm often tempted to leave something out when I see a long list of features and fixes, but it's very hard to do this kind of sorting light-heartedly.

If we had a specific target group (end users, developers, organizations) it would possibly make picking out the 2-3 features/fixes or going for a specific writing style simpler. But my understanding is that we are going for a more generic audience here.

A hybrid approach could indeed work for us. In such a case, I would leave it up to the developers to point out the couple of features they would like to mention first in the short text. After all, they know their users better than everyone. These can be distinguished in devs' initial notes for the announcement. If they don't care for doing that, the persons writing the announcement can decide on what people might be interested in based on their own experience.

I would like to commit this for translation on 15th of April. Would be nice if we can get in the kmail news.

@mardelle Thanks for adding your points about Kdenlive. I transformed them into some kind of bullet/paragraph text and added them to https://notes.kde.org/p/applications_18.04.0_announcement. Feel free to correct any glaring mistakes I made ;)

In T8357#136881, @cfeck wrote:

Or a hybrid. Talk about some interesting things first, then add a list like: "Further improvements in <Appname>: * Item 1 * Item 2 * Item 3".

Great idea. I now split up some of the longer bullet lists and reordered some points. Simply adding a short blurp was enough in most cases. Feel free to elaborate if needed, though, and continue where I left off.

Thanks @rkflx for reworking the text, it does flow much better with your changes. We'll see if we can improve the style with the next major release.

@cfeck If not done by now, I'll say go ahead and commit so translators can get some time ahead of release on April 19. Friendly reminder to add the photo's you find suitable and remove the related comments from the notes. =)

In T8357#138560, @neofytosk wrote:

Friendly reminder to add the photo's you find suitable and remove the related comments from the notes. =)

I think we/the developers wanted to provide lots of options and leave that to you/the promo crew. :)

In T8357#138561, @ngraham wrote:

In T8357#138560, @neofytosk wrote:

Friendly reminder to add the photo's you find suitable and remove the related comments from the notes. =)

I think we/the developers wanted to provide lots of options and leave that to you/the promo crew. :)

Yup, that was intended for @cfeck (silly extra line, fixed it now). As I don't have access to edit the final text/layout, I left that part for him to tackle. ;)

In T8357#138560, @neofytosk wrote:

We'll see if we can improve the style with the next major release.

Yup, improving is always good…

Talking of improvements: What would perhaps help to smooth the process a bit is a timeline right in the task description (and possibly add it to the release schedule), i.e. until when to provide the initial bullet points, when it is time for polishing, when translations start etc.

For 18.04 it was a bit of back and forth in some parts, in particular I felt a bit uncomfortable having to add more points after you already started the writing/polishing. Having a clear deadline sometimes works wonders in synchronising efforts ;)

In T8357#137795, @cfeck wrote:

I would like to commit this for translation on 15th of April. Would be nice if we can get in the kmail news.

@cfeck What's the status on this? Currently the page only has the new text for "System", all other sections still have the 17.12 text, while translations are starting to trickle in based on the incomplete text…

I believe @ngraham can also edit the page, in case you need a helping hand.

(Also, I wonder if there is a way to tweak the vertical spacing CSS for <li>, because it currently blows up the length of the page quite a bit. Anybody?)

Going to commit the remaining text tonight; was swamped with unexpected work, and couldn't complete it earlier.

It's all in. Please check https://www.kde.org/announcements/announce-applications-18.04.0.php for anything that needs to be fixed before adding the link to the front page.

I hope the image choice looks sane, and please send apologizes to the translation teams for not being able to commit the text earlier...

In T8357#138911, @cfeck wrote:

It's all in. Please check https://www.kde.org/announcements/announce-applications-18.04.0.php for anything that needs to be fixed before adding the link to the front page.

I hope the image choice looks sane, and please send apologizes to the translation teams for not being able to commit the text earlier...

Thanks @cfeck for working on this! The announcement is looking really great.

Just one small issue I noted: @skadinna's corrections from Monday did not make it into the final text (even in the parts you added later on). I guess this should be solvable by including a short timeline into the task description for next time…

Oh, I didn't notice the changes. I copied the raw text to the machine where I prepared the HTML. Regarding the timeline, I have added a comment on 11th April that I wanted to commit this on 15th.

In T8357#138560, @neofytosk wrote:

We'll see if we can improve the style with the next major release.

FWIW, I think the GIMP team found a really nice and coherent balance between headings, (a lot of) images, longer text and bullet points in their recent release notes: https://www.gimp.org/release-notes/gimp-2.10.html