Jump to content

Promotion/This week in KDE

From KDE Community Wiki

"This Week in Plasma" (TWiP) and "This Week in KDE Apps" (TWiKA) are (mostly) weekly blog posts highlighting recent notable development changes within KDE. They are quite popular, and amount to good promo tools for KDE. They generally publish on Saturday and Sunday morning (respectively) EU time.

This page describes how to get involved in these efforts and help publish the posts.

Help is needed to improve this process. See https://invent.kde.org/teams/promo/tasks/-/issues/13 and the TODO items on the page here.


Where to coordinate work

In the Matrix room: https://matrix.to/#/#this-week-kde-apps:kde.org


Current process

1. Create skeleton of the post

Create a new merge request at https://invent.kde.org/websites/blogs-kde-org/-/merge_requests containing a skeleton of the post, e.g. from the boilerplate in https://invent.kde.org/websites/blogs-kde-org/-/issues/7. Follow the existing style and conventions of past merge requests.

TODO: have a bot automate this!

2. Collect relevant changes

Next, collect relevant-looking changes that the community might be interested in! This is necessarily subjective, but here are some factors that might make a change relevant:

  • It's a new feature
  • It's a user-facing improvement to something shipped by default
  • It's a change to a default theme or style
  • It measurably improves performance
  • It implements a new Wayland protocol or XDG desktop portal
  • It can be illustrated well with an image or a screen recording
  • You can think of a way to describe it to a normal-ish mildly technical person

The more factors apply, the more relevant the change is.

Where can you find relevant-looking changes? Here are some links to pre-made searches that will find changes likely to be relevant:

TWiP:

TWiKA:

  • TODO

Make sure to ignore anything that was already mentioned in a prior week's post!

TODO: have a bot automate the collection of changes somewhere, so that humans only need to do a bit of filtering on them and rewrite their descriptions as needed.

3. Write a blurb for each relevant change in the post skeleton

For each relevant-looking change, write an entry for it in the post skeleton. This entry needs to answer at least the "what", and "who", with the "why" being optional in case the benefit of the change isn't obvious. "Where" and "when" get answered by the section header.

For example:

Plasma 6.5.5 [WHERE and WHEN]

Improved KRunner’s search matching algorithms to prioritize partial matches at the beginning of apps’ names, descriptions, and keywords. [WHAT] This should fix issues like searching for “ala” and getting “KAlarm” as the top match instead of “Alacritty”. [WHY] (Harald Sitter, [WHO] KDE bug #512400 and KDE bug #512399)

4. Add relevant screenshots and screen recordings

Once all entries have been written, choose a few that can be easily illustrated with screenshots and screen recordings and make some! Since recently-merged changes necessarily won't be in a released version of the software yet, you'll need to be using a pre-release version. Options for this include:

5. Choose an exciting headliner change for the title

In most weeks, at least one item stands out as something that will get people really excited. Often these are juicy new features, but other times they'll be longstanding bugs with tons of duplicates, noticeable visual changes, or improvements to performance or Wayland support for something.

Pick one and write about it in the title! If more than one thing is really noteworthy, mention two! But don't go too long. For example:

This Week in Plasma: Saved clipboard items and tablet touch rings

If nothing stands out, just mention the section with the biggest changes:

This Week in Plasma: Lots of nice UI improvements

6. Write a short introduction that ties things together in a cohesive narrative

At this point, a story is probably starting to come together. Notice patterns! Was this a week where several improvements in hardware support got merged? That's the beginning of a story. Was it a weak heavy on bug fixed, but no new features. That's a different kind of story, but a story nonetheless.

Write an introduction to the post that would serve as an introuduction to that story in your mind. Usually it ends up looking somewhat like this:

"KDE contributors worked really hard on things X and Y this week, to strategically advance KDE goal Z. But we didn't forget about important topic Q!" Something like that.

For example:

This week the team made significant progress on KWin’s Wayland screen support. Specifically, better mirroring and custom modes — both items on the “Known Significant Issues” page — have been implemented for Plasma 6.6! The remaining items on that page are areas of active focus, too, as we race towards the Wayland finish line.

…But wait, there’s more!

7. Edit, proofread, condense, etc.

Now put the finishing touches on the post:

  • Change anything in the conclusion/outro part that seems necessary or relevant
  • Proofread and correct all spelling and grammar mistakes
  • Find-and-replace straight quotes and apostrophes with fancy ones (i.e. ’ “ and ” instead of ' " and ") and use real em-dashes (—) instead
  • Make sure you wrote the correct numbers of bugs in the extra bug info section (TWiP only)
  • Make sure you removed all headings with no content in them
  • Make sure the post's publish date and time are as intended
  • Make sure all changes are pushed to the merge request

8. Publish

Merge the merge request!

If publishing at a time in the future, push another dummy commit to the repo somewhere to make it actually get posted at the correct time.

TODO: fix this, Carl! :D

If you want to be nice, immediately create a skeleton of the next post.