Happy holidays to all in the KDE universe who celebrate them! As 2025 draws to a close, I thought it would be a good time to take stock.
Thank you so much for your work on this!
I hope that someone can take a part of it and help you.
All the best 
@ngraham, can any of the work be automated? I imagine that deterministically creating a Hugo-CommonMark list of merged MRs and resolved Bugzilla tickets would reduce the load.
I wouldn’t be able to spend time on this, nor would I be capable of it, but I was imagining what hardships I would encounter: apart from setting up environments and testing changes, collecting MRs would definitely be one of them and automatizing this would be useful for sure.
Reading TWiP while having a coffee had become a Saturday morning ritual. Thanks for all the amazing work.
Nate, much appreciation and gratitude for all the work you’ve put into “This Week in Plasma/KDE” through all the years! And I can totally understand the need to have more time for recreation and to spend with your family!
I think I’ve been following it since 2019/18(?), the time when I just had switched to KDE – time flies… I always felt there is a kind of joy and exitement your blog transports about KDE and working on KDE, and it was definitely a factor that inspired me to eventually get involved to do some little work on KDE myself!
Reading these was one of the main things that convinced me KDE was to be my next DE, and I’ve never looked back since! You have done fantastic work with this and I have always enjoyed reading what new awesome features I was about to get next. 
Thanks for the kind words, everyone!
To be clear, this isn’t the end yet. In the short term, I’m going to be reducing the frequency, not canceling it entirely.
Yes, as I wrote, There are probably plenty of opportunities for automation.
But it needs to all be carefully curated. A dump of all merged/fixed MRs and bug reports will number in the hundreds; a big part of the secret sauce is really in choosing what to report and what to omit.
Even then it’s a careful balance and I probably haven’t always gotten it right. For example, reporting too many bug fixes makes the product seem buggier than it is.
Apologies. I missed that part.
Just to echo other commenters, a massive thanks to @ngraham for all the effort that’s gone into this over the years. It’s the only periodical I read and I really look forward to it.
Totally respect your wise decision to put family first. All the best.
Thank you for all the great work!! Wise decision on your part and I wish you all the happiness and success in the path ahead
I’ve been a long-time fan of KDE, and have always enjoyed the posts that explain what new developments are occurring. Back in the day, I remember gathering ideas from artists for the first version of Plasma, and reading KHTML devlogs was practically a special interest. I’ve been looking for ways to contribute that don’t involve code (that’s my day job), and am interested. Before I commit, however, I’d like to know a little bit more about what that work looks like.
Thanks!
Thanks so much for thinking of volunteering! I’ll answer as best I can:
It’s a bit hard to say because my current workflow is integrated with my other daily work (which is something I’m also hoping to change around a bit). Taken together, probably 3-4 hours. But this represents a standalone, un-automated process. Like I mentioned in the post, I’m sure there are some automation opportunities.
How do you gauge what is relevant or irrelevant to the readership?
Good question. The readership is diverse, but I try to keep it mostly high level (new features and significant-seeming UI improvements) with some significant-seeming low-level technical stuff for the more technical folks.
“Significant-seeming” is something I play by ear. I feel like I have a decent idea of what the community is interested in at this point, and if you’re a longtime user, you probably have this already yourself. Regardless, I generally apply the filter of “can I explain this is comprehensible terms to someone who’s mildly technical but not a KDE developer?”
I ignore code refactoring, basic maintenance, etc. That stuff is basically expected, and doesn’t feel interesting enough to report on.
I’ve been starting to feel like most of the bug fixing section is the same. People expect bug fixes, and outside of the really big high priority ones, mentioning so many might be making Plasma feel buggier than it is.
What are your primary data sources for the work?
Right now I’m subscribed to a zillion bug reports as a result of 8 years of bug triage, and I’m subscribed to all merge requests in every Plasma-aligned git repo. So as a part of my daily email routine, I notice anything that was merged or fixed that looks relevant and mark it with a tag in Thunderbird to look at it later, and then later I add it to the post.
This workflow worked as a complement to things I was already doing, but probably won’t work for someone else. Instead, probably it makes sense to put together Bugzilla and Invent queries, e.g.
For the Bugzilla tickets, it’s important to make sure they were actually resolved by a code change. I don’t generally mention cases where the original reporter says, “this is working for me now” and sets the status to RESOLVED FIXED.
Is there a certain amount of lead time for publication? (e.g. for editing/etc.)
I try to publish early morning Saturday EU time, which happens to be late evening Friday my time. I usually take an hour or two just before publishing to edit, finalize, polish, etc. But the publication time isn’t set in stone; as long as it’s reasonably consistent, I don’t think anyone will complain. Posts can also be scheduled in advance.
Is there anything like brand guidelines or a tone that I’d need to learn?
Being written by me, TWiP is currently very much in my writing style and voice. If someone else is taking over or doing a bunch of the work, it’s totally reasonable for that to change.
I do think it’s important to keep the tone positive and upbeat, though. Communicate how cool it is that all this stuff is getting build and distributed for free! It’s exciting.
I also find that it’s good to own up to mistakes and not try to hide them. If there was a blunder or problem, admit it and say we’re working on it! IMO we don’t benefit from trying to hide our issues.
But that’s how I’ve done it personally. Again I think it’s totally reasonable for it to change a bit to reflect the personalities of new contributors. IMO one of KDE’s communication advantages is that we present a human and personal style, and don’t use the standard bland, personality-less corporate- speak that’s all too common these days.
Thanks again!
Dear Nate,
Thank you for your work for KDE.
Family is the most important thing in life. Enjoy your children before they grow up and leave home.
I wish you and your family all the best for 2026.
Thanks! GitHub - rweekly/rweekly.org: R Weekly can be a good collaborative model to keep TWIP forward.
Thanks for many years of weekly summaries!
In some ways KDE is outgrowing TWiP; it’s no longer really necessary to provide weekly evidence that we’re still keeping the lights on.
In all bluntness, I strongly disagree. These regular posts are what provide visibility into KDE development for enthusiasts and aspiring contributors. They explain why changes aren’t as easy as one would initially assume, and that we’re all just people trying to do our respective best for users. They drive constant traffic to KDE and generate discussions, getting syndicated via RSS, Phoronix, Reddit, KDE Discuss, and more. They are responsible for a lot of goodwill, as well as the feeling that one’s recurring donations are worth the investment.
TWiP has been the best promo campaign for KDE that isn’t strictly speaking a promo campaign. In fact, with how outsized an impact this kind of community work is producing, and the regular time commitment required, I wonder if KDE e.V. may want to contract out the production of a hand-curated, well-written TWiP that at least comes close to what @ngraham has been producing for years.
Nate might need 3-4 hours to compile and rephrase commits from all over the Plasmaverse, someone who isn’t involved in literally everything all the time across all repositories might take a few more hours. Even with a full day’s worth of “promo” work a week, paying someone reliable to do this right would probably be an excellent deal for the e.V. compared to a half-baked best effort by unaccountable committee. And infinitely better than the annoying “OMG the sky is falling unless you donate” that I tend to get on a regular basis even from worthy charities.
Just something to consider. Thanks again and enjoy the holidays!
Here’s a thought.
We know that verbatim commit messages are just plain unsuitable for more mainstream readership such as TWiP. We also know that they don’t make for great changelogs either. Useful change reporting usually happens per MR, rather than per commit. We also know that some people want to know about improvements that they’re getting right now, as opposed to four months into the future.
Good changelogs and insightful TWiP blurbs are close enough that they could be tackled together. We can change CI hooks for Plasma MRs to require specially crafted Markdown files with text descriptions and even images.
Here’s how Actual Budget does it. Their release notes then automatically incorporate the line from the text file, which looks like this. For Plasma, we could expand the format a bit, listing:
Fixed bug(s), reviewer(s), notability tags and related links are optional. Descriptive paragraph is optional for boring maintenance changes, bug fixes and performance improvements, but strongly encouraged for the latter two. Other fields are mandatory. Want to submit a change? Describe its impact for end users.
Release changelogs can source all the snippet files for a given release, and list them in single-line format with an expansion arrow for more details per improvement.
TWiP posts can source all the snippet files for any release since the last post, creating template Markdown text. The TWiP editor can then tweak them further and add personal touches (including header and footer essay texts, but also tweaking changelog paragraphs) before posting.
The nice thing about having these files in git is that not only can they be reviewed as part of the MR, with suggestions via regular code comments, but also they can be tweaked after the initial MR by anyone who wants to focus on promo stuff. The best of both worlds: original sourcing by the developer(s) responsible for the change, but open to be polished by crafty wordsmiths.
I’m aware that this duplicates the (CC)BUG: and FIXED-IN: tags currently used in commit messages. Frankly, I think separate files can do as good a job at all of these, plus some extra bits that the integrated commit stuff can’t be expected to do.
Someone (am I signing myself up here?) would have to write some scripts, put the CI rules in place and add a convenience template generator to kde-builder or such. With that in place though, I could see it working out with (largely) community-sourced blurbs increasing the quality and scalability of release notes and roughly preserving that of TWiP - which, and yes I’m a total fanboy, are virtually impossible to beat in their past/current state.
@jpetso there is an ongoing discussion on how to make it more manageable. Including potentially creating some sort of automation into a SoK project.
Can you please file your suggestions here: Make production of TWiKA and TWiP posts more manageable (#13) · Issues · Teams / Promo / Tasks · GitLab
Thanks for the pointer, I posted there
I’m pretty sure I cannot DM yet, as my account is still new, so I’m replying here.
After reviewing the resources @Duha linked to KDE’s wider efforts, I think this will involve more than I’m capable of delivering. Somehow, scanning MRs and bug reports for a few hours a week, recompiling KDE and capturing a handful of gifs, and writing some blurbs seems totally reasonable. Coordinating with a team of promo organizers, adjusting build and contribution systems, and processing media uploaded by developers is, in comparison, overwhelming. I’ll continue lurking, and find a different way to dip my toes into contributing.
Thanks for responding to my questions! I hope y’all find a way to keep this going, as I love hearing about developments.