I think 3 month would be pretty good (you could even call them seasonal updates)

I don't know if I'm misunderstanding this or not, as I'm new to the promo team, but I think a get it...

The announcement should be made every 3 months, that announcement would not refer to a specific version of a software bundle, but would talk about all the progress made by applications in those 3 months. I believe the announcement should probably have a simple date instead of a version number based on a date. Like "KDE updates for Q1/2021".

If I understand well, according to jriddell the problem is:

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

So, instead of calling it just Applications, give it a name that makes it clear the announcement is talking about all applications, not only the ones in the bundle, so:

"KDE releases Application Universe Q1/2021 update"

I hope what i'm talking about here makes sense. I'm still a bit lost about how all this really works.

+1 for the ideas expressed here

Thank you, @Guilhermems . Yes, basically it is what you said.

Thanks, @ngraham for your support.

In T14091#249181, @mikeljohnson wrote:

I think 3 month would be pretty good (you could even call them seasonal updates)

I recall there was a reason for 4 months, but I can't find it. I think @ognarb explained it somewhere. Can you remind us please, Carl?

I am going to ask around to app developers, see what they think too, just to make sure we are all on the same page.

The terminology in the description above is incorrect which will confuse any discussion.

The bundled apps from the release service get released every 4 months with 1 monthly bugfixes inbetween.

Self released apps get released whenever they get released.

The monthly app update articles are timed for the release service new versions each month and mixes in announcements of new releases which once every 4 months is mostly the release service apps and otherwise is a wrap up of new self released apps. It also has notes of bugfixes, add-on releases and articles about app stores. This is a bit confusing and seems not to have had much traction.

The proposal to move the monthly app update articles to a three month cycle would be a worst of both worlds: not timed with a release and a mix of new announce and old wrap up.

My proposal would be to brand the release service again, have an announcement for that with all the new features on the 4 monthly cycle. If the wrap-up content has value then move that to a 4 month cycle which is published 2 months after the release service articles to space them out. And have any articles about app stores separate.

To me, this sounds like... pardon my Look Around You commentary here, but: An experiment was conducted, based upon the hypothesis that more frequent announcements would be advantageous. The results gathered during the experiment show that this hypothesis was not true, and a reversal to the previous approach would be advantageous. So, in short, yeah, a Quarterly App Catch-up or whatever it ends up being called seems a good idea. It also seems like this would make it perhaps a little easier for single-app highlights to show through a little easier, with an occasional big release announcement type thing. We could then call that approach a follow-up experiment ;)

I fully agree with this proposal and with the rationale behind it.

Nowadays the information flow and the amount of the available content is very high and people try to consume the "high quality content" only because of the limited time available for it. This holds true for reading newspapers, playing games, watching movies/series and so on. I don't think we can win more attention through quantity (anymore).

I doubt many people are _really_ going through the different "weekly updates" published on planet.kde. Most people will quickly scan such an update and move on to the next "content". Next time, the chances are high many people will only read the title (the "headline") because they know what they can expect from this article already and similar for other "trivial" or "self-explaining" news people are confronted with on the daily base.

In KDE we have many applications that are quite mature already and I don't think these applications need to report on the many small improvements here and there regularly or frequently.
For the state and for the quality of these applications a reporting with a higher quality is needed, not with a higher frequency.

I do see however the need to regularly tell the communiy "Hey, folks, look, we're still alive and working hard on the next release", etc. For this maybe smaller publications in the different social media can be used. An active and well maintained project homepage with a clear vision, development roadmap and a regular reporting on the progress is a differentiator in the open-source world. But if there is not enough "high quality content" to be published every month, we should rather reduce the frequency a bit and invest our resources into the preparation of the content of a higher quality for the next post. The frequency still can be increased in future if there is enough content available but we need to keep a certain quality bar I think and this is what this proposal is trying to address.

It seems this is worth repeating:

This is not about the apps, frameworks, and libraries release cycle.

In fact, and in view of some these comments, it seems to me the way forward would be to disconnect the announcements/wrapups/bulletins/whatever-you-want-to-call-them from the devs' release calendar entirely. The release cycle is too complex to make sense to an audience that just wants to know about the existing and upcoming new features in their software, which is what this is about.

By freeing the release cycle and promotional calendar from each other, if developers change their cycle again because they find something better, a promotional strategy that works would not be affected. It would also give Promo the freedom to try alternative strategies without having to go through an unwieldy and time-consuming discussion.

The content of these "bulletins" will be everything of note that has happened over the period (whatever that works out to be, 3 or 4 months) and comprise new features, new apps incorporated into KDE, version releases, newsworthy bugfixes, etc. that have appeared during the period. We can also add in new things users can look forward in the immediate future.

Promo will build the "bulletin" from what developers have shared on their blogs, from commits, and from whatever developers want to share with Promo directly. For projects we are missing information from, Promo members can actively seek devs and ask them directly to make sure we don't miss anything of importance. This will also help to open channels with projects we don't currently talk to on a regular basis. We can also use the "noteworthy" tag for commits and get information from there.

And talking of blogs, for people who need more detailed and frequent updates, they can always refer to project blogs themselves, some of which even publish weekly and monthly updates. Promo consistently shares these via KDE's official social media accounts.

As for the rebranding, we would remove any reference to releases and call it something like "The KDE Software Update", "KDE Software News", or "The KDE Software Bulletin" or whatever you like, something that is not misleading, does not omit apps, frameworks, or libraries, and that is catchy at the same time.

To summarise, my proposal is this:

1. Disconnect promo bulletin calendar from the release cycle
2. Set a periodicity that works from the promotional point of view
3. Give it a catchy and accurate name
4. Collect content from devs, blogs, and commits to fill bulletin
5. Glamour it up with videos, press release, etc., and make all the changes we include newsworthy

I disagree with dropping release announcements for apps which are part of the release service. Release announcements are what gets engagement and interest. Wrap-ups of the last month or three are less interesting. Releasing software and not having any announcement for up to four months is magnifying the the problem that linux distro model creates.

Disconnecting promo announcements from the release cycle seems like a bad idea to me. People want to be notified of new software as soon as it's released. This disconnection is a part of the problem with our current monthly announcement.

I agree with Leinir and I also don't really understand why there's a controversy here. We can forget about the release service itself; the apps it releases all have a predictable 4-month release cycle. Can't we go back, as Leinir suggested, to doing a release announcement each time these apps have a major release?

In T14091#249274, @jriddell wrote:

I disagree with dropping release announcements for apps which are part of the release service. Release announcements are what gets engagement and interest. Wrap-ups of the last month or three are less interesting. Releasing software and not having any announcement for up to four months is magnifying the the problem that linux distro model creates.

I understand why one would think that. Without "the experiment", I would've agreed that having an announcement with a release would probably be better than just having a wrapup without one. As you know, I had no reservations regarding moving to monthly announcements, as I did not think it would have a negative effect. Unfortunately the data does not support this and my presupposition that nothing important would change has been proven wrong. My ideal scenario would be to go back to what we had before, a quarterly release/announcement cycle, but we cannot suggest developers adhere to a given calendar for promotional reasons. And, as the stats have shown, monthly announcements, even when synchronised with releases, perform very poorly with regard to traffic, coverage from third parties, engagement, etc..

In T14091#249275, @ngraham wrote:

Disconnecting promo announcements from the release cycle seems like a bad idea to me. People want to be notified of new software as soon as it's released. This disconnection is a part of the problem with our current monthly announcement.

I agree with Leinir and I also don't really understand why there's a controversy here. We can forget about the release service itself; the apps it releases all have a predictable 4-month release cycle. Can't we go back, as Leinir suggested, to doing a release announcement each time these apps have a major release?

This sounds good too. Whatever gets us out of the monthly announcement cycle.

In T14091#249275, @ngraham wrote:

I agree with Leinir and I also don't really understand why there's a controversy here. We can forget about the release service itself; the apps it releases all have a predictable 4-month release cycle. Can't we go back, as Leinir suggested, to doing a release announcement each time these apps have a major release?

... as long as this doesn't mean they are called "KDE applications", which would close the circle by going totally at the starting point.

The historical summary is: the original problem was the name. The proposed solution combined a change in the name with a change in the advertising model (which are not really linked to each other).

Sure, yeah. So regarding the name, I see two feasible paths forward:

1. Emphasize the name, and come up with a promo-friendly brand name like "KDE Gear" or KDE Galaxy" or something and write release announcements every 4 months that coincide with the release service's releases. Then we later do separate release announcements for the apps that are not using the release service.

2. De-emphasize the name and just do release announcements every 4 months that coincide with the release service's releases. These announcements would also include information on apps not using the release service that released new versions in the preceding 4 months. Basically these would be thrice-yearly wrap-ups of all app news that just happen to come out around when the release service does its releases.

I'd be fine with either, but I do think we need to get back to aligning the announcement's timing with the release service's release schedule so that people are reading an announcement of something that was just released.

Other than that, option 2 seems slightly preferable to me because it results in promo having to to only three announcements a year rather than 6 or more, and it also bypasses the discussion about naming the release service, which indeed, seems to go in circles. :) But I'd be okay with it if Promo signs off and we get a good name we can all agree on.

+1 to @ngraham's proposals.

I prefer 1 as I think it's easier to understand for casual readers having a branded release announce and the wrap ups have some value but as a separate story. But 2 can work as well.

In T14091#249282, @jriddell wrote:

+1 to @ngraham's proposals.

I prefer 1 as I think it's easier to understand for casual readers having a branded release announce and the wrap ups have some value but as a separate story. But 2 can work as well.

I prefer 1 as well. And for the same reasons.

I think Nate's proposal is sensible. +1

If we go with number 1, we then need to come up with a name. Let's start gathering suggestions:

Nate:

• KDE Gear
• KDE Galaxy

Me:

• KDE Universe
• KDE App Pack(s)
• KDE App Releases
• KDE Global Software News
• KDE Universal Software Updates

Here's 2 cents from a quiet observer:

1. Shorter is better. A name like "KDE Something" is more memorable than calling it "KDE + 3 other words". Why? Well, if people outside of the community perceive the name as too long, they will eventually start shortening it or dropping parts of it when they talk about your announcement. Not sure if this is a good or a bad thing; maybe it doesn't matter. But a shorter name gives you more space for other text in character-limited social media posts 😉

2. The name doesn't need to be 100% descriptive; you don't have to overexplain what the announcement is about. It can be something as simple as "KDE Dispatch"; it doesn't need to mention the words "release" or "software" at all. "KDE Memo" or "KDE Wire" also sound cool... You could take "The Scoop" and then just call it "The Skoop"...but that would probably be too kringe for most people 😅

Anyway, just sharing some ideas. I support this initiative, whichever name you pick in the end.

Although I like them for other reasons, I think all names that contain the word "app" or "applications" in them would not qualify. This discussion was had elsewhere and it was pointed out to me that the release did not only contain applications, making the name misleading. If you make it "applications [or apps], libraries and frameworks", which is more accurate, then it is too long.

Given the above, I agree with @skadinna that probably the only way forward is to have a non-100%-descriptive name.

Regardless of what name we choose, it seems like option 1 is the preference. Shall we commit to that now?

In T14091#249349, @ngraham wrote:

Regardless of what name we choose, it seems like option 1 is the preference. Shall we commit to that now?

+1

Cool. How do people feel about "KDE Gear" as a name? I believe Albert suggested this earlier and I quite like it. It's short and has no intrinsic meaning or connection to our apps, but "gear" has an implicit meaning of "equipment; useful stuff" which I think is appropriate.

What do people think about that?

I can live with "KDE Gear", but I could even live with other generic names like "KDE Bundle" or such ;)

No idea as a non-native speaker what sounds better or does convey better what we want to express.

I like KDE Gear, and it also fits the KDE logo :)

"KDE Gear" is a great name

What would the new calendar look like? When would the next announcement be made?

To coincide with the next major version of the release service, on April, 22nd?
https://community.kde.org/Schedules/release_service/21.04_Release_Schedule#Thursday.2C_April_22.2C_2021:_21.04_Release

Next one, some time in August, then December.

One thing to tidy up then is how should bugfix releases be announced? An e-mail to kde-announce yes and an info page like https://kde.org/info/releases-20.12.2/ but should there be anything at all at https://kde.org/announcements/ and on the front page or just nothing at all?

In T14091#249489, @jriddell wrote:

One thing to tidy up then is how should bugfix releases be announced? An e-mail to kde-announce yes and an info page like https://kde.org/info/releases-20.12.2/ but should there be anything at all at https://kde.org/announcements/ and on the front page or just nothing at all?

One of the reasons for the adjustment is that the payback for these smaller announcements is so small that they are not worth the time and effort it takes to compose them and put them out there. Based on that, the answer would be "no". As you suggest: a couple of lines to the mailing list saying that the release has happened should be enough.

We do bugfix announcements for Plasma, but they are very small and low effort, with typically three prominent bugfixes selected on the day of the announcement by Jon yelling "hey who knows what cool things were fixed recently?" in the plasma chatroom. It's quite ad hoc but it seems to work well on an effort-to-reward ratio as I do see people posting these bugfix announcements on social media.

It's quite ad hoc but it seems to work well on an effort-to-reward ratio as I do see people posting these bugfix announcements on social media.

Similar for the info page (https://kde.org/info/releases-20.12.2/) and full changelog (https://kde.org/announcements/fulllog_releases-20.12.2/) of the release service. It's (mostly) script generated and the information might be interesting for technical users and distro packagers. It contains the fingerprint of the GPG key the packages are signed with, for example.

e-mail send to kde-community

How about "KDE Drop" for quadmonthly update?

It's clear it's actual "stuff" that's releasing, short, and sounds good(maybe?)

A challenge I think I'm seeing coming up with a good name is that... KDE sounds really, *really* *cool* already. Like, more than three letters have any right to be.

But, it's a whole 3 syllables. Adding more syllables to it makes it unwieldy runs the risk of being,*not* cool...

KDE Plasma sounds good and it looks good. KDE Neon sounds good and looks good..

plasma, neon.. Very nice 'soft' words to balance the hard-pitchiness of KDE.

Plasma, Neon, Drop.. They sound right together, and even fits the 'theme' of "matter". (Okay, that's all the pushing I'm doing on my own name idea, promise!)

Regarding the timing/diminishing-returns issue (as I agree with ltoscano that its separate from naming)... I feel it's a 2-step decision-tree here:

1. Who's the audience?
2. How to package+distribute the blog/info/post/presser

Because something meant strictly meant for KDEnthusiasts shouldn't read the same as something meant for general techies, and the method of propagation should be tailored to match.

A chunky quadmonthly KDE Drop can be written and posted and submitted with the expectation that it will be covered by "tech media" like Ars, Liliputing, OMG Ubuntu, etc etc. These can have a cool, easy name, and have info "unfurl", getting more technical only as the post goes on.

Non-bundle apps can be posted to social media as noteworthy updates happen, where they can freely propagate amongst enthusiasts and contributers, without 'tainting the pool' re:KDE for general readers.
If compiled together, rather than piecemealed, these could benefit from bulkier, more straightforward, non-PR titles. They're meant for those delving deeper, rather than discovering. A technical "boring" title can repel overreporting. Sounds like we're seeing now that over coverage can be a bad thing.

Might help to consider a realistic goal or intended outcome of each infodump.

I've scheduled in the first quarterly app update article here https://phabricator.kde.org/E754

And renamed release service to KDE Gear https://phabricator.kde.org/calendar/query/KhNLCxe1xjoI/2021/04/ https://community.kde.org/Schedules/KDE_Gear_21.04_Schedule https://community.kde.org/KDE_Gear