View source for Guidelines and HOWTOs/Write this week in KDE

This page details how Nate Graham writes the weekly "This week in KDE" (TWIK) blog posts at https://pointieststick.com/category/this-week-in-kde/. Currently Nate takes care of all of this, but this information may be useful should the blog need to be tended by someone else or more than one person in the future.

== Purpose ==
* TWIK is basically a news blog, so timeliness is important. People want to know what happened *this week*; don't write about things that happened weeks or months ago. If you missed something, don't write about it; the opportunity has been lost.
* A explicit goal of TWIK is to generate positivity, passion, and excitement in the KDE community. People should feel energized and uplifted when they read a post. They should get a sense of KDE's forward momentum, believe that anything is possible, and want to contribute! Encourage contribution.

== Following changes ==
* CC yourself on every relevant-looking bug report you see. It helps if you do bug triage, so you see lots of bug reports. This way, whenever any interesting bug gets fixed, you'll receive an email about it.
* Become a follower for GitLab project of every piece of KDE software that you use or that interests you.
* Accept requests to report on things from projects that you don't follow when someone tells you about a relevant thing that they did that users would care about.

== Choosing what to cover ==
* Only write about user-facing changes. Code refactoring is important, but the user doesn't care unless it results in improved performance, fixed bugs, new features, etc.
* Phrase changes in a comprehensible way, using plain language when possible. A certain amount of technical jargon is required, which is okay, but minimize it as much as you can.
* Don't feel the need to be neutral and offer equal coverage to every project, which is impossible--and if it wasn't, the result would be too long to read anyway. Instead cover the apps you use and are passionate about! The passion will become infectious, which is one of the goals of TWIK.
* Don't overload a post. If it starts getting really long, break it up and post two in a week. Otherwise people's eyes will start to glaze over even when the content is really amazing.

== Emotional ==
* TWIK works in large part because it's not too formal and doesn't have flashy production values. Each post should have a distinct-yet-not-overwhelming author's voice, and feel like a casual conversation among friends--or at best an interesting talk or presentation given to a small audience familiar with the work. It shouldn't feel like it was put together by a committee.
* Content is king; visuals should be practically non-existent, save for the screenshots and videos of the actual software.
* In order to actually see everything that goes on so you can be notified of relevant changes, you will get a lot of email. Possibly 300 a day or more. You need to actually open and skim them all. Don't ignore your emails or filter them into folders that you never read! This defeats the point. You'll miss stuff, and by the time you look at old emails, relevant changes will have been made weeks or months ago so it doesn't make sense to still report them.
* When adding a screenshot that shows obvious bugs or visual issues, make a joke about them in the caption!

== Technical ==
* It's a simple Wordpress blog hosted by wordpress.com. Nothing fancy.
* Don't hotlink images from Phabricator or GitLab. Upload them to the site or imgur or another more image hosting site. Note that most gif hosting sites delete gifs after a few months, so it is usually a good idea to upload them to the website itself.