In T11933#207146, @IlyaBizyaev wrote:

Is it really related to "debranding" though? Sounds like a separate issue that equally affects Plasma, for instance.

Yes because we need to work out what to publish for the release next month

most people aren't able to do it.

Pardon my ignorance, but I'm not aware of anyone who's able to do Dot translations

I mean most people aren't able to write the horrible PHP/HTML mix of markup needed for the announcements on kde.org. It's a significant time waster.

In T11933#207157, @jriddell wrote:

In T11933#207146, @IlyaBizyaev wrote:

Is it really related to "debranding" though? Sounds like a separate issue that equally affects Plasma, for instance.

Yes because we need to work out what to publish for the release next month

most people aren't able to do it.

Pardon my ignorance, but I'm not aware of anyone who's able to do Dot translations

I mean most people aren't able to write the horrible PHP/HTML mix of markup needed for the announcements on kde.org. It's a significant time waster.

True enough.

Let's make this month applications announcement in the dot. But I still think it's an issue we need to fix in the future. I created T11986

Thank you, Carl!

In T11933#207191, @ognarb wrote:

Let's make this month applications announcement in the dot.

My concern is that, once we do an announcement on the Dot, the translation feature just gets dropped and no one ever gets to fixing it.

In T11933#207150, @jriddell wrote:

It's directly related because we need to work out how to do the Apps Update announce next month

It seems to not affect this task in any way if the announcement just happens on kde.org as before, and following announcements transition to Dot together with that of Plasma when the Dot is actually ready.

On branch naming:

"release/19.12" is not so good because such branch corresponds to multiple releases: 19.11.70 through 19.12.5.
"stable/19.12" or "development/19.12" look better to me.

Questions for the "visionaries" of the change:

Does the future "release service" provide Beta and RC (Release Candidate) releases? If yes, will they be announced somehow at kde.org or dot.kde.org? How soon they will be announced after publishing beta/RC tarballs? (this last one is more of a cue than question)

What is the process to get a new release of your application mentioned in the next monthly announcement?

What applications are eligible for being mentioned in such announcement? Are software libraries OK? Are mobile apps OK? Is server-side software OK? Should Plasma be mentioned?

too late for branch naming, i already went with release/19.12

Does the future "release service" provide Beta and RC (Release Candidate) releases?

Yes

In T11933#207482, @aacid wrote:

too late for branch naming, i already went with release/19.12

Of course if there's an overwhelming majority of people that doesn't like it we can change the name to something else in 20.04

We also need to decide what to rename KDE_APPLICATIONS_VERSION_XXX in CMakeLists.txt if at all, or just pretend this is internal and noone cares

Keeping list of what needs to be done in phabricator is not really easy, am i doing this wrong?

Note that since the Beta for 19.12 is scheduled in 4 days i will probably just call everything KDE Applications because i don't think my questions will be answered by then

In T11933#207510, @aacid wrote:

Keeping list of what needs to be done in phabricator is not really easy, am i doing this wrong?

You can edit this task's description and add a list of checkboxes in there.

From https://secure.phabricator.com/book/phabricator/article/remarkup/:

You can add checkboxes to items by prefacing them with [ ] or [X], like this:

• Preheat oven to 450 degrees.
• Zest 35 lemons.

In T11933#207509, @aacid wrote:

We also need to decide what to rename KDE_APPLICATIONS_VERSION_XXX in CMakeLists.txt if at all, or just pretend this is internal and noone cares

KDE_RELEASE_SERVICE_XXX ?

We do need to rename it imho, otherwise it will only make things confusing. Would it be possible to do a mass renaming using the very same script that bumps the version numbers?

The only problem I can see is if someone hardcoded KDE_APPLICATIONS_VERSION in the source code instead of using ecm_setup_version, but I can volunteer to fix those apps (if any).

In T11933#207480, @aspotashev wrote:

On branch naming:

"release/19.12" is not so good because such branch corresponds to multiple releases: 19.11.70 through 19.12.5.
"stable/19.12" or "development/19.12" look better to me.

I don't see the problem honestly, imho it's clear that the 19.12.x bugfix release comes from the 19.12 release branch.

Questions for the "visionaries" of the change:

What is the process to get a new release of your application mentioned in the next monthly announcement?

You are supposed to help write the accouncement to make sure the app you care about gets mentioned.

What applications are eligible for being mentioned in such announcement? Are software libraries OK? Are mobile apps OK? Is server-side software OK? Should Plasma be mentioned?

I don't think there is such a whitelist, but I suppose the change needs to be somehow noteworthy. I'm not sure about Plasma, I guess they will keep doing their own announcements.

• New name for https://community.kde.org/Applications/19.12_Release_Notes

How about https://community.kde.org/19.12_Release_Notes or https://community.kde.org/Releases/19.12_Release_Notes. I think I prefer the first

• New name for https://kde.org/info/applications-19.08.0.php

How about https://kde.org/info/releases-19.08.0.php

• New name for https://kde.org/announcements/fulllog_applications-aether.php?version=19.08.0

We'd like this to have the option for individual app changelogs only e.g. https://kde.org/announcements/releases-changelog.php?version=19.08.0 listing them all with links to
https://kde.org/announcements/releases-changelog.php?version=19.08.0&app=okular with the okular changelog

[]Update / kill https://community.kde.org/Release_Team

wipe it!

[]New name for KDE_APPLICATIONS_VERSION_XXX in CMakeLists.txt files

discussed elsewhere, I like KDE_RELEASE_SERVICE_VERSION_XXX

[]New process for .0 and bugfix release announcements which become the KDE Apps Update

This should now be the monthly KDE Apps Update stories, written a few days in advance for translations and published after the tars are released at kde.org/announcements/releases-19.12.0.php

[]Rewrite and simplify the beta and RC release announcements

Just some simple factual links

[]New name for https://kde.org/announcements/announce-applications-19.08-rc.php

How about https://kde.org/announcements/releases-19.08-rc.php

In T11933#207937, @jriddell wrote:

• New name for https://community.kde.org/Applications/19.12_Release_Notes
  
  How about https://community.kde.org/19.12_Release_Notes or https://community.kde.org/Releases/19.12_Release_Notes. I think I prefer the first

I prefer the second. Then https://community.kde.org/Releases can contain an index to the sub-pages

• New name for https://kde.org/info/applications-19.08.0.php
  
  How about https://kde.org/info/releases-19.08.0.php

+1

[]Update / kill https://community.kde.org/Release_Team

wipe it!

+1 if an actualized module coordinators page exists / is created.

[]New name for https://kde.org/announcements/announce-applications-19.08-rc.php

How about https://kde.org/announcements/releases-19.08-rc.php

+1 simple and explicit

In T11933#207937, @jriddell wrote:

• New name for https://community.kde.org/Applications/19.12_Release_Notes
  
  How about https://community.kde.org/19.12_Release_Notes or https://community.kde.org/Releases/19.12_Release_Notes. I think I prefer the first
• New name for https://kde.org/info/applications-19.08.0.php
  
  How about https://kde.org/info/releases-19.08.0.php

I prefer https://kde.org/info/releases/19.08.0 or https://kde.org/releases/19.08.0/info

• New name for https://kde.org/announcements/fulllog_applications-aether.php?version=19.08.0
  
  We'd like this to have the option for individual app changelogs only e.g. https://kde.org/announcements/releases-changelog.php?version=19.08.0 listing them all with links to https://kde.org/announcements/releases-changelog.php?version=19.08.0&app=okular with the okular changelog

It would be nice to have this integrated somehow with kde.org/applications. ;)

I would go with something like:

https://kde.org/announcements/releases/19.08.0/changelog

and

https://kde.org/announcements/releases/19.08.0/changelog/kate or using the AppStream id https://kde.org/announcements/releases/19.08.0/changelog/org.kde.kate

[]New name for https://kde.org/announcements/announce-applications-19.08-rc.php

How about https://kde.org/announcements/releases-19.08-rc.php

Following the naming scheme of the other proposed page:

I would go with: https://kde.org/announcements/releases/19.08-rc

I would quite appreciate if the change to the release service could allow us to use more hierarchical urls ;)

^ Plays into https://github.com/ximion/appstream/issues/240

How about https://kde.org/announcements/releases-19.12-beta.php ?

From discussions with Albert my current plan is to scrap the final announce for KDE Applications / Release Service and instead have the monthly apps update story on kde.org/announcements and copies onto kde.org. I'm pondering if it can be written in YAML or similar with the PHP/HTML nonsense generated from that

That would seem to subsume the apps announcements into the All About The Apps initiative. What happens once that initiative ends? You'll be stuck doing blog posts forever, that's what! This is sort of the situation I'm in with my U&P posts that became a generic commit digest type of thing.

But we have been discussing about the naming and scope of the Applications releases way before the All About The Apps initiative. I think that @jriddell mentioned that it's consistent with the All About The Apps initiative, but at least I see the two changes unrelated to each other. Not sure what the others think about this.

In T11933#208150, @jriddell wrote:

From discussions with Albert my current plan is to scrap the final announce for KDE Applications / Release Service and instead have the monthly apps update story on kde.org/announcements and copies onto kde.org. I'm pondering if it can be written in YAML or similar with the PHP/HTML nonsense generated from that

If peoples are interested I could use the same system as in kate-editor.org to create announcement in yaml and markdown (and translatable). This would require to have the announcement in kde.org/announcements/release so that I don't need to care about converting all the older announcment now and just need to convert one or two announcements.

In T11933#208153, @ngraham wrote:

That would seem to subsume the apps announcements into the All About The Apps initiative. What happens once that initiative ends? You'll be stuck doing blog posts forever, that's what! This is sort of the situation I'm in with my U&P posts that became a generic commit digest type of thing.

The monthly app updates shouldn't just be me writing them. The idea for writing them came out of the idea for debranding KDE Applications. It's no different to who writes the KDE Applications announcements currently.

One thing more i forgot is https://download.kde.org/stable/applications/ needs to be somewhere else probably?

In T11933#207968, @ognarb wrote:

In T11933#207937, @jriddell wrote:

• New name for https://community.kde.org/Applications/19.12_Release_Notes
  
  How about https://community.kde.org/19.12_Release_Notes or https://community.kde.org/Releases/19.12_Release_Notes. I think I prefer the first
• New name for https://kde.org/info/applications-19.08.0.php
  
  How about https://kde.org/info/releases-19.08.0.php

I prefer https://kde.org/info/releases/19.08.0 or https://kde.org/releases/19.08.0/info

• New name for https://kde.org/announcements/fulllog_applications-aether.php?version=19.08.0
  
  We'd like this to have the option for individual app changelogs only e.g. https://kde.org/announcements/releases-changelog.php?version=19.08.0 listing them all with links to https://kde.org/announcements/releases-changelog.php?version=19.08.0&app=okular with the okular changelog

It would be nice to have this integrated somehow with kde.org/applications. ;)

I would go with something like:

https://kde.org/announcements/releases/19.08.0/changelog

and

https://kde.org/announcements/releases/19.08.0/changelog/kate or using the AppStream id https://kde.org/announcements/releases/19.08.0/changelog/org.kde.kate

Who is going to write all the code to generate those webpages? because what we have right now is monolotic.

Just to note that we didn't have an info/announcement page for the 19.12 Beta because i didn't know what to do, and it's probably going to be the same for the RC this friday.

Right. Unless someone informs me what text I should use, I will use the current templates that are at /www/announcements/announce-applications-YY.MM*php.

For the RC use this page
https://www-staging.kde.org/announcements/releases/19.12-rc/?letmein=1
which will be published at
https://kde.org/announcements/releases/19.12-rc
and can be edited at
https://invent.kde.org/websites/kde-org-announcements-releases/
the date at the top of the .md file decides whether it's published on www.kde.org or not.

For the final one I have
https://www-staging.kde.org/announcements/releases/2019-12-apps-update/?letmein=1
which will be fleshed out

release notes at
https://community.kde.org/Releases/19.12_Release_Notes

I've updated the schedule wiki page

and removed the release team wiki page

Unless Carl comes up with a better scheme just keep the info/ pages the same but rename to release-service-19.12.0.php

Changelog just keep it simple with this
https://kde.org/announcements/changelog-releases.php?version=19.12.0
which includes fulllog_release-service-$version.inc

And update kde.org and kde.org/announcements/ as normal

On download server I'd use https://download.kde.org/stable/release-service

and removed the release team wiki page

I honestly think that was a bit too on the "brutal" side as a solution, but ok, i'm not in the caring too much side lately

I think the removal of https://community.kde.org/Release_Team is a mistake. In fact there is an active release-team@ list, and it is worth having a page which describes it. It should be updated instead.

What does KDE release? I couldn't come up with a headline for the kde.org page, that's why it still reads "KDE Applications". We not only need an announcement text, but also new text for the kde.org main page, text for the announcement mailing list, etc.

"19.12 Releases" would do it

In T11933#212056, @ltoscano wrote:

I think the removal of https://community.kde.org/Release_Team is a mistake. In fact there is an active release-team@ list, and it is worth having a page which describes it. It should be updated instead.

make a replacement if you like but it would just be a description and pointer to the mailing list

How about this for renaming the variable in Cmake?
https://phabricator.kde.org/D25769

In T11933#212862, @jriddell wrote:

How about this for renaming the variable in Cmake?
https://phabricator.kde.org/D25769

There's a nicer way: set the version on the project line and remove these lines. See https://cmake.org/cmake/help/latest/variable/PROJECT_VERSION.html (needs CMake >= 3.0)

No, because that forces you to use all the version, so you can't do stuff like okular or khelpcenter do

For tomorrow's release the link is at
https://kde.org/announcements/releases/19.12

And text on kde.org and kde.org/announcements can be something like:
KDE Ships 19.12 Releases
"KDE's release service has made available hundreds of apps, libraries and plugins with new feature releases"

So since the new way we do the release (Montly Apps Update), the engagement in various social media are going down significantly. According to stats.kde.org, we are also losing readers. Also the new release announcements are getting less mentioned in the press. At the same time, Plasma announcements are getting more popular. So I don't think it's KDE popularity that is decreasing.

At the same time, promo is now spending much more time working on the announcements, since we need to write more announcements (every month). As a side effect, since we don't have as much time as before the quality of the announcement is lower and the big announcements are also smaller than before.

I would like to get back to a state similar to the "KDE Applications" period, there we only do big announcements for the feature releases and not much else for the bug fix releases. The current promo workforce is not able to handle more anyway.

In T11933#247450, @ognarb wrote:

So since the new way we do the release (Montly Apps Update), the engagement in various social media are going down significantly. According to stats.kde.org, we are also losing readers. Also the new release announcements are getting less mentioned in the press. At the same time, Plasma announcements are getting more popular. So I don't think it's KDE popularity that is decreasing.
[...]

We are not suggesting changing the release schedule, just the announcement schedule. We would publish and promote "KDE Applications" (or whatever we decide to brand it) on quarterly schedule, which would enable us to include more interesting feature changes and make more polished announcements, thus boosting KDE applications' popularity.

We are losing readers

Maybe it's because the announcements are not linked from kde.org main page anymore?

Can someone share some insight on why it was decided that that monthly application announcements don't belong there?

Also the webpage is now probably nicer, but the announcements section of it used to be really on the top and now it's buried like 4 page scrolls down, so less people are finding them (if the applications updates was in it)

In T11933#247460, @aacid wrote:

We are losing readers

Maybe it's because the announcements are not linked from kde.org main page anymore?

Can someone share some insight on why it was decided that that monthly application announcements don't belong there?

This was a bug and was just fixed with https://invent.kde.org/websites/kde-org/commit/aeeee7c51ec0a1f847b28fcdc06f714991ef9533

Also the webpage is now probably nicer, but the announcements section of it used to be really on the top and now it's buried like 4 page scrolls down, so less people are finding them (if the applications updates was in it)

Most of the visits are coming from social media post not from navigating inside the webpage. Also if moving the announcement sections to the bottom was really impacting the number of views, then Plasma announcement views should have decreased instead of growing (more than doubling actually).

While I agree that the announcements could be displayed more prominently on the front page, it will not have a significant impact on the visits to said announcements. To expand on what @ognarb just stated, although the number of visits to kde.org, including the front page, has gone up since the re-design to about 5000 unique visitors a day, on the 13th October, coinciding with the announcement of Plasma 5.20, visits to KDE.org ballooned to 21000 in a 24 hour period, the highest of the year. A resounded success however you look at it.

But, then again, that is on average the number of readers that see every single tweet we put out every day of the year.

Indeed, a massive proportion (81%) of those 21000 visitors mentioned earlier entered directly to the announcement, never even touching the front page. That is, they came from somewhere else, namely social media (which we broadly define to include news aggregators like Hacker News and Reddit).

We have to have a front page because it is what people expect, but the the amount of people who actually read it is only a fraction of the people that read us on social media. It follows that, if you are going to direct traffic to an announcement, your best bet is to do it from social media.

This is a roundabout way of saying that the moving of the announcements of app releases on the front page of kde.org has very likely had very little to do with their drop in popularity. It is also interesting to note that the decline in their popularity started more or less when the monthly release updates started.

I guess part of the problem is that the title of the media post reads something like "Interesting new feature in App A and first release of App B this month", instead of "KDE Releases October 2020 Updates". I often don't even find the monthly apps announcement on reddit, because there is no standard phrase to look for in its title.

The problem is what we just said:

1. Monthly releases do not contain enough significant changes to make them exciting for users and they generate fatigue: you haven't finished installing one update when, oh, they are announcing another with two more corrected bugs that never affected me.
2. The word "release" has proven to be weak as a noun and we often struggle to write a exciting headlines while trying to avoid the word combinations we were told not to use. "KDE Applications" (+ a number) and "Software Collection" (+ a number), despite probably being inaccurate, were stronger names under which we could promote stuff easier and which users could recognise.

Note we are not suggesting changing the schedule of releases for devs. It is not Promo's place to do that. We are saying we could collect all the most notable (from a user's point of view) changes over the period we decide (3 months is what was suggested), give it a stronger brand name and talk about it at the end of the period.

For small, incremental changes, the people who like to follow these things already have Nate's excellent blog posts.

Count me in the column of people who dislike the new style, for all the reasons brought up here. I think the old way was much better. I think we should chalk it up to a "we tried it, it didn't work, we want back to what we were doing before" experience. I would like to explore going in the opposite direction, and encouraging all apps using the release service to unify their release numbers (as Okular did) so we can go back to saying "Announcing the release of KDE Applicxations 21.04".

The new format doesn't seem to work, I agree. Just please don't go back to "let's release KDE", which has strong implication on the image of the community, and I believe can't be decided by promo alone.
Same for release all all applications together: what is the line?

Btw, when I originally discussed the issues with "KDE Applications" one of proposals was just to find a new, totally unrelated name for the bundle which wasn't made of "App", "applications" or any other generic word hard to distinguish.

"we tried it, it didn't work, we want back to what we were doing before"

What didn't work? We're getting less views? Fair, but really, do we care about that?

For me, the fact that we don't have a terrible product naming like "KDE Applications" is much more important than that (and yes, i know i was one of the original supporters of that name)

What didn't work? We're getting less views? Fair, but really, do we care about that?

Yes, we do. In fact, that is the whole point of Promo: to get more eyes on KDE stuff.

I'm just proposing getting rid of the monthly app update, but I don't mind calling it "Release YY.MM" if KDE Applications is a bad idea. But having to write an announcement every month and announce in it stuff we published already 2 weeks ago is a bad idea :/

We can brainstorm what to call it later. For the moment I object to "release" because it not only doesn't say what it is for, it doesn't even say what it is: "Release" of what? What should be the most important word in your headline is devoid of meaning for the reader. But this is another discussion to be carried out by Promo.

Fair, but really, do we care about that?

Yes.

Btw, when I originally discussed the issues with "KDE Applications" one of proposals was just to find a new, totally unrelated name for the bundle which wasn't made of "App", "applications" or any other generic word hard to distinguish.

I don't see how we can come up with a word for a bundle of applications that doesn't include the word applications in it. But I'm bad at naming things; maybe someone else can come yup something something good. Ooh, how about some kind of Web 3.0 name like "Plarq". Just imagine: "KDE announces the release of Plarq 21.04!"

Or maybe we can go back to using the word "Applications" even though isn't a 100% technically accurate word for all contexts.

In T11933#247531, @ngraham wrote:

Fair, but really, do we care about that?

Yes.

Btw, when I originally discussed the issues with "KDE Applications" one of proposals was just to find a new, totally unrelated name for the bundle which wasn't made of "App", "applications" or any other generic word hard to distinguish.

I don't see how we can come up with a word for a bundle of applications that doesn't include the word applications in it. But I'm bad at naming things; maybe someone else can come yup something something good. Ooh, how about some kind of Web 3.0 name like "Plarq". Just imagine: "KDE announces the release of Plarq 21.04!"

Let's agree to disagree: this is exactly what I had in mind.

Or maybe we can go back to using the word "Applications" even though isn't a 100% technically accurate word for all contexts.

And live forever with the confusion between app(lications) by KDE (everything) and this specific subset "KDE Applications". I don't and won't like it and I don't think it helps.

I don't see how we can come up with a word for a bundle of applications that doesn't include the word applications in it. But I'm bad at naming things; maybe someone else can come yup something something good. Ooh, how about some kind of Web 3.0 name like "Plarq". Just imagine: "KDE announces the release of Plarq 21.04!"

Exactly, our friends at Gnome just invented "Gnome Circle", it means nothing, but it's a product name (well, not really but bear with me), if you see it you'll be, yeah they're not talking about circles here, and if you're interested you'll look for more.

One relatively easy name would be "KDE Gear" as opposed to "KDE Extragear" but, then again we've been trying to kill the extragear name for decades because it conveys the idea that they are "extra" things, i.e. non core, which it's not the truth, the only difference between release service apps and non release service apps is if they're release with a well known 4/1 month cadence or not. So let's not do that ;)

KDE Gear isn't bad. I kind of like that. "Gear" is also a slang term for "nebulous collection of useful stuff" which seems to fit quite well.

Two things regarding this discussion:

1. The discussion is veering a bit off topic. The main thing we first have to clarify is the periodicity of the announcements and whether you agree with the proposal.
2. By trying to avoid the naming of the thing that is going to most interest users (that is, "applications" in this case) you are adding a layer of obfuscation that can confuse and thus risk turning people away. For example: "Circle" is a baaaad name for a software bundle because what do you mean by "circle"? It forces you to explain to your audience what you mean. Skip that and just call it for what it is.
3. Deciding names should really be Promo's job. We have often been saddled with less than optimal names because someone has fixated on them before consulting with us and it has made things so much more difficult marketing-wise. Names of products are decided by marketing teams (and not engineers) in companies for a reason. Let us brainstorm 5 or 6 options and then you can pick from those.

Okay, so it was three.

1. If we do a release every month i don't understand why an announcement every month is not ideal. We had that before too and according to you it wasn't a problem?
2. "just call it for what it is" yeah ok, "what is it?"
3. "We have often been saddled with less than optimal names because someone has fixated on them before consulting with us and it has made things so much more difficult marketing-wise." Can you give some examples?

In T11933#247538, @aacid wrote:

1. If we do a release every month i don't understand why an announcement every month is not ideal. We had that before too and according to you it wasn't a problem?

Before it was just a small announcement, now it is a full blow announcement with tons of stuff not related to the release service. https://kde.org/announcements/releases/2020-02-apps-update/ vs https://kde.org/announcements/announce-applications-16.12.3/. Also, the announcements are not always at the same date in the month, sometimes we have only 1-2 weeks separating two announcements, sometimes 5 weeks. So very difficult to plan in advance and the amount of content differs a lot between each announcement.

In T11933#247538, @aacid wrote:

1. If we do a release every month i don't understand why an announcement every month is not ideal.

Read back the prior comments. We have already explained this.

We had that before too and according to you it wasn't a problem?

It has always been problematic. The change in periodicity and the debranding led to a nosedive in popularity of the announcements. Again, we have already explained this.

2. "just call it for what it is" yeah ok, "what is it?"

For the audience we are targeting, "new versions of KDE applications".

One of Promo's main aims is to expand our userbase. For users, apps make the platform. The underlying platform can be the most masterful work of software engineering the world has ever seen, but for users it will only ever be as good as its apps. Fortunately KDE has spectacular apps and, as a Community, we already recognise through the "it's all about the apps" goal. By focusing on what would interest potential users, we can at least have a shot of tempting new people to try our stuff.

I know the release includes more things apart from applications. But for savvy followers, we already have things like devs' blog posts (which we also regularly promote) and the detailed changelog.

Also, despite that everything you do, every bug you fix, every library you update, is important, not everything is newsworthy, meaning not everything is publishable because not everything is interesting to the general public.

Publish enough stuff that is not interesting for the general public, and you start to lose your audience, even if you publish interesting stuff in between. Lose enough audience, and the possibility of growing the userbase goes away, because you end up preaching exclusively to the choir of diehard fans and that's it.

We have already experienced this several times over the last few years, which has made us more selective of what we publish and even inspired the "noteworthy" tag for merge requests.

3. "We have often been saddled with less than optimal names because someone has fixated on them before consulting with us and it has made things so much more difficult marketing-wise." Can you give some examples?

Sure: "Big Screen" (confusing: in every day parlance "Big Screen" refers to a movie screen, not a TV screen), "KClock" (why not just "Klock"? Or, if you want to be cute, "Klok"? It is also hard to figure out how to pronounce that), "Kdenlive" (contrived, does not give any clue as to what the app is about), "Plasma" (so many things come up before a FLOSS desktop when you search for that word), ... the list is a long one.

But that is not the point. I understand that the creators of FLOSS projects should have all the right to name them whatever they want, however hard that name makes it to promote. I respect that. But this is not a personal project.

In T11933#247540, @paulb wrote:

In T11933#247538, @aacid wrote:

1. If we do a release every month i don't understand why an announcement every month is not ideal.

Read back the prior comments. We have already explained this.

We had that before too and according to you it wasn't a problem?

It has always been problematic. The change in periodicity and the debranding led to a nosedive in popularity of the announcements. Again, we have already explained this.

So brand it again, but not as "KDE applications".

2. "just call it for what it is" yeah ok, "what is it?"

For the audience we are targeting, "new versions of KDE applications".

Does it mean you are not going to provide any clue about version number, like "Today KDE releases a new bunch of applications"?

One of Promo's main aims is to expand our userbase. For users, apps make the platform. The underlying platform can be the most masterful work of software engineering the world has ever seen, but for users it will only ever be as good as its apps. Fortunately KDE has spectacular apps and, as a Community, we already recognise through the "it's all about the apps" goal. By focusing on what would interest potential users, we can at least have a shot of tempting new people to try our stuff.

But you shouldn't confuse people more by providing incomplete

I know the release includes more things apart from applications. But for savvy followers, we already have things like devs' blog posts (which we also regularly promote) and the detailed changelog.

That (the release including not application) is not the problem, the problem is the specific confusion coming from the string "KDE applications" which has a precise (unfortunate) story as personal name.

Also, despite that everything you do, every bug you fix, every library you update, is important, not everything is newsworthy, meaning not everything is publishable because not everything is interesting to the general public.

Publish enough stuff that is not interesting for the general public, and you start to lose your audience, even if you publish interesting stuff in between. Lose enough audience, and the possibility of growing the userbase goes away, because you end up preaching exclusively to the choir of diehard fans and that's it.

We have already experienced this several times over the last few years, which has made us more selective of what we publish and even inspired the "noteworthy" tag for merge requests.

I don't think anyone complains about this. This is not new at all, and no one ever said that every fix should be mentioned. I don't see how this changed: the story for all release announcement (of every kind, with maybe the exception of Frameworks) is about developers providing the list of changes, and whoever writes the announcement select the relevant news. It may not have always happened, but that's how it has been always intended. But I thought we were talking about the frequency of he announcements here, not the content.

3. "We have often been saddled with less than optimal names because someone has fixated on them before consulting with us and it has made things so much more difficult marketing-wise." Can you give some examples?

Sure: "Big Screen" (confusing: in every day parlance "Big Screen" refers to a movie screen, not a TV screen), "KClock" (why not just "Klock"? Or, if you want to be cute, "Klok"? It is also hard to figure out how to pronounce that), "Kdenlive" (contrived, does not give any clue as to what the app is about), "Plasma" (so many things come up before a FLOSS desktop when you search for that word), ... the list is a long one.

I can understand the problems with a generic name like "Big Screen", but I don't see the problem with the choice of KClock and Kdenlive. Why this fixation that the program name should give a clue of the role? Both choices are totally valid, and there are successful programs (FLOSS and proprietary) whose name doesn't connect to its role.

I'd point out that Plasma, in the right context (software) is not so complicated.

I also need to point out that marking the generic usage of "KDE applications" as fine, while on the other hand pointing out that Big Screen or Plasma are not, is a bit weird.

But that is not the point. I understand that the creators of FLOSS projects should have all the right to name them whatever they want, however hard that name makes it to promote. I respect that. But this is not a personal project.

Sure there can be suggestions, and names should have a legal vetting before being approved (and a double check that the name is not offensive), but I otherwise find this last sentence and what implies ("not a personal project", so you are not free to give uncommon but valid names) a bit disturbing, given that the real world has successful software with strange names.

To re-steer the conversation:

We would like to do a bigger announcement for the general public every 3 or 4 months (instead of monthly) containing the highlights of all the most exciting changes users can look forward to in applications (and other stuff where applicable) when they hit their distros repos/the app stores they are using.

We would want to give it a name (TBD) + version number related to the date the announcement is made -- maybe something like 21.03, 21.06, 21.09, etc., but also open to discussion.

This may require projects adjust their version numbering from what it currently is for the announcement, but the advantages from a promotional point of view would be substantial.

Does this sound reasonable?

This is about the promo announcement. Changing the version number to accommodate a promo messaging is going a bit far.
Some applications won't be under any unified schema anyway. Without mentioning krita which will probably have its own announcement, there are several others which won't and don't need to be released together. Or do you want to include krita releases as well? Then the unified versioning doesn't work anyway.
Also, in 3 months there may be several (sub)releases.

Fine with aggregating the promo messaging, but changing the versioning of applications (which ones? Release service? All?) is not something up to promo or marketing.

Thank you Luigi. We would like to hear what others think about this too.

To chime in as well:

To my knowledge, this is the situation we have:

• We have a collection of software that is released on a 4-month-schedule. We currently call this the Release Service and by now (as Okular now also changed versioning), those applications then have version YY.MM.
• We have Krita, which is the biggest exception to the aforementioned scheme. They use their own versioning and also publish their own announcements, since they usually easily have enough changes to fill a whole announcement with it.
• We have another collection of software that releases on an on-demand basis, mostly "when it's ready". This includes software like KStars, Digikam and other, mostly smaller, pieces of software produced by the KDE community.

Now, one of the problems we were facing is that we called the first group "KDE Applications <YY.MM>", which implied that those were all our applications which isn't the case.
We have circumvented this problem by renaming the first group to "Release Service" and moved from a 4-month-schedule for announcements to a monthly announcement schedule including every update from every piece of software.

This has led to two problems that I can see:

• The monthly interval of announcements is too short. There are not enough "exciting" new features for users to look forward to. The ones that want to be up-to-date all the time read Nate's blog anyways, and the other users just want the créme-de-la-créme improvements - something that our current interval isn't suitable for.
• There is no version X to point out. Earlier on we'd say "KDE releases KDE Applications 19.12" and the 19.12 was something tangible and relatable for users. Now, this has disappeared.

Thus, we need solutions for those issues.
The first one should as far as I can gather be uncontroversial from its basic idea - we switch back to a longer timespan between announcements. Personally I'd suggest 4 months again, mainly because of reasons explained below:
We as Promo cannot control versioning. It strikes me as unproductive if we'd try to convince every project to adopt a common versioning system - whilst that would be nice for us, it seems rather unrealistic and developers wouldn't like it.
Now, this leaves us with the problem of which version number to promote again. And here, I think we have to be practical in the end. Say in these bigger announcements we'd like to promote all applications, not only the ones in Release Service. Then I'd still favor calling this "KDE releases <fancy name> 21.04", even if some of the software promoted in the announcement follows a different versioning scheme.

This way we do not interfere with the versioning of the developers but have a tangible number to promote.

And for (sub)releases that happen inbetween - those are 99% of the time bugfix releases either way, no? Looking at the changelogs for 20.08.1/2/3, they do not seem to contain something that'd warrant a separate article - so then we just can keep doing it the way we do right now, have a changelog and site for them but not a fully-fledged release announcement.

Okay. I guess we can compromise on the version thing. It is going to look weird when users look at he "About" dialogue. Maybe we can come up with some clever solution to that too. Just spitballing, but maybe it will be possible to change the text in the about to "Version [whatever], part of KDE [clever name] version [whatever]"

The current setup is just a compromise that nobody complained about. Some apps get released every 4 months with the release service. Some do their own releases with their own announcements. We have a monthly app update that I write and includes everything released in the last month as well as reviewing apps stores (to promote the new distribution channels we have) and every 4 months its timed with the release service for those apps.

Some people want apps released with the 4 monthly bundle to have their own version numbers as well as the bundle version number. I've no idea why but we've had that discussion and people are attached to it.

Calling the bundle KDE Applications is problematic as it clashes with applications not released with the bundle.

I'm not against branding the bundle again. Choosing a name seems problematic. Maybe Paul is volunteering to choose a name which seems as reliable a method as any.

If the bundle has a brand again then should the monthly app updates continue? Is there value in doing a monthly article showing what new apps have been released in the last month and what new app stores we have?

In T11933#247614, @jriddell wrote:

The current setup is just a compromise that nobody complained about.

We didn't have enough data. We do now and it does not work for promotion purposes, unfortunately.

Some apps get released every 4 months with the release service. Some do their own releases with their own announcements. We have a monthly app update that I write and includes everything released in the last month as well as reviewing apps stores (to promote the new distribution channels we have) and every 4 months its timed with the release service for those apps.

Some people want apps released with the 4 monthly bundle to have their own version numbers as well as the bundle version number. I've no idea why but we've had that discussion and people are attached to it.

Thanks for the clarification. No touching any of the project's version numbering systems. Makes sense and got it.

This may be a dumb idea, I do not know enough to decide if it is, but... would it be possible to include the "collection" the software belongs to in the "About" dialogue, say, like "Konsole Version X.Y.Z - Collection 21.03"? This would help users know where they are.

Calling the bundle KDE Applications is problematic as it clashes with applications not released with the bundle.

Okay.

I'm not against branding the bundle again. Choosing a name seems problematic. Maybe Paul is volunteering to choose a name which seems as reliable a method as any.

Well... Not Paul specifically. I was suggesting Promo brainstorm several alternatives and then stakeholders picking from among them.

If the bundle has a brand again then should the monthly app updates continue?

I would suggest discontinuing it. Firstly because people who are interested in a constant stream of information regarding progress of Plasma and apps already have blogs from several developers, which make it a wee bit redundant. Secondly because it has proven to be not as popular as having a big announcement with a lot of substantial changes since the last announcement.

Is there value in doing a monthly article showing what new apps have been released in the last month and what new app stores we have?

Again, I would say probably not and for similar reasons: Existing blogs and a decline in interest in news about applications because of fatigue due to being too frequent and not "meaty" enough.

In T11933#247583, @paulb wrote:

To re-steer the conversation:

We would like to do a bigger announcement for the general public every 3 or 4 months (instead of monthly) containing the highlights of all the most exciting changes users can look forward to in applications (and other stuff where applicable) when they hit their distros repos/the app stores they are using.

That sounds fine to me if people in the promo community think it makes sense.

We would want to give it a name (TBD) + version number related to the date the announcement is made -- maybe something like 21.03, 21.06, 21.09, etc., but also open to discussion.

This may require projects adjust their version numbering from what it currently is for the announcement, but the advantages from a promotional point of view would be substantial.

Does this sound reasonable?

Asking people to adjust their versioning doesn't seem reasonable at all.

In T11933#247596, @xyquadrat wrote:

To chime in as well:

To my knowledge, this is the situation we have:

• We have a collection of software that is released on a 4-month-schedule. We currently call this the Release Service

No, we don't call it "Release Service", we don't call it anything, release service is the internal term we use for the process in which a bunch of unrelated applications get released at the same time because it eases the release procedure to have one person do 200 releases instead of 200 people doing one release each.

and by now (as Okular now also changed versioning), those applications then have version YY.MM.

No, that's not correct either, there's a bunch of applications with other versioning schemes released as part of the release service.

• We have Krita, which is the biggest exception to the aforementioned scheme. They use their own versioning and also publish their own announcements, since they usually easily have enough changes to fill a whole announcement with it.
• We have another collection of software that releases on an on-demand basis, mostly "when it's ready". This includes software like KStars, Digikam and other, mostly smaller, pieces of software produced by the KDE community.
  
  Now, one of the problems we were facing is that we called the first group "KDE Applications <YY.MM>", which implied that those were all our applications which isn't the case. We have circumvented this problem by renaming the first group to "Release Service" and moved from a 4-month-schedule for announcements to a monthly announcement schedule including every update from every piece of software.

Again, "Release Service" is an internal engineering term, try to use it as little as possible, don't capitalize it and don't add quotes to it.

This has led to two problems that I can see:

• The monthly interval of announcements is too short. There are not enough "exciting" new features for users to look forward to. The ones that want to be up-to-date all the time read Nate's blog anyways, and the other users just want the créme-de-la-créme improvements - something that our current interval isn't suitable for.
• There is no version X to point out. Earlier on we'd say "KDE releases KDE Applications 19.12" and the 19.12 was something tangible and relatable for users. Now, this has disappeared.
  
  Thus, we need solutions for those issues. The first one should as far as I can gather be uncontroversial from its basic idea - we switch back to a longer timespan between announcements. Personally I'd suggest 4 months again, mainly because of reasons explained below: We as Promo cannot control versioning. It strikes me as unproductive if we'd try to convince every project to adopt a common versioning system - whilst that would be nice for us, it seems rather unrealistic and developers wouldn't like it. Now, this leaves us with the problem of which version number to promote again. And here, I think we have to be practical in the end. Say in these bigger announcements we'd like to promote all applications, not only the ones in Release Service. Then I'd still favor calling this "KDE releases <fancy name> 21.04", even if some of the software promoted in the announcement follows a different versioning scheme.
  
  This way we do not interfere with the versioning of the developers but have a tangible number to promote.

That's basically what Luigi suggested, invent a new name and use it for the announcements.

In T11933#247481, @paulb wrote:

2. The word "release" has proven to be weak as a noun

It is a verb in my sentence. We are releasing updates. For new applications, there really should be one blog post for each of them. For existing stuff, we are releasing only updates, either bug fixes, or major updates.

there really should be one blog post for each of them

Yes.

Discussion moved to https://phabricator.kde.org/T14091