blogs.kde.org is in a bit of weird state - not quite dead, not quite thriving
either. I’d like to propose that we reinvent what it is and how it works.
Intro
But first let me list some of the challenges we are facing…
Right now we have two competing blog offerings that make little to no sense
to the outside. blogs.kde.org is a list of blogs of a small number of KDE
contributors while planet.kde.org is a list of all (well, those that have it
enabled anyway) KDE contributors. Without background knowledge this is puzzling
to say the least.
What’s more, blogs.kde.org is what I get when I google for ‘kde blog’ as first
result and its appearance is just terrible for being a first result. It looks
dated and in point of fact is quite clearly not cared for because it has a poll
‘Best Thing About Akademy Brno’… that akademy was 2014!
Meanwhile planet.kde.org is snazzy etc. but only the second result.
This is all quite meh.
Also, over the past couple of months I’ve talked to various contributors about
blogging and we all agree that we should do it more but it’s also a bit of a
drag. It doesn’t help when we have to fight our blog software either.
Case in point: I know a number of people that are on wordpress.com that aren’t
entirely happy with its offering and would happily have a KDE blog somewhere
on a KDE server instead.
Some contributors are also unhappy about having to moderate comments on their own
when their KDE blog posts are benefiting the whole community one way or another.
A fairly recent development is lastly that we also pull blog posts into discuss.kde.org for discussion. This is, to my mind, not exactly ideal because
it fragments discussion between the discuss thread and the actual blog comments.
Proposal
So, in a quest of having less disappointing things in my life I’d like to
propose reinvigorating blogs.kde.org and address all of the aforementioned
points using it.
First things first: blogs.kde.org as a mainpage needs to stop existing.
It should merge into planet.kde.org. Which domain gets used I don’t care much
about (any thoughts on this?).
Going to either of the two domains should get you to the planet main page.
To replace blogs.kde.org we start a blog hosting service that is open to
everyone with a dev account or e.v. membership. This new service will
not have a global main page but only individual ones.
e.g. blogs.kde.org/sitter/ might be my blog.
The mainpage, as it were, is the planet page.
blogs.kde.org should not be a replacement for personal blogs. If you want to
blog about your sunday afternoon walk in the park that still should go on
a personal blog
The software we use for this new blogs.kde.org should be Hugo to align nicely
with the rest of our websites where we have moved to static site
generation in recent years. This also reduces maintenance burden on sysadmins.
To drive discussion on the new blogs we’ll embed discuss.kde.org directly as
comment system. This joins the discussion space with entry points both
from the blog posts and discuss.kde.org proper. Joint moderation
can then also happen on discuss as well as spam prevention measures.
We also have various SSO providers enabled on discuss, making it easier to
join the discussion.
If all works out, a very similar treatment should befall dot.kde.org as
functionally it is simply our “news” blog. Input from the promo side would
be good on that. In particular whether Hugo can be made to work for them.
As for migrating dot, yes please. Hugo would not be my first choice by a long shot though. While it is great for static websites, it is neither flexible, nor intuitive, nor convenient for blogging.
My first choice would be a self-hosted WordPress, like LabPlot and Kdenlive have. WordPress is offers exactly content creators need, as that is what it is designed for.
KDE is already hosting two WP instances, so why not make Promo people’s current miserable content-creation experience, not a bit better, but a lot better?
If you’d migrate the Dot to HUGO too, I’d really recommend also looking at Decap CMS, because it’s really hard to get any new people up to speed with plain HUGO/Git for promo. If it’s feasible, a nicer (than just Hugo) editing UX wouldn’t hurt blogs.kde.org either.
Planet.kde.org being the homepage as it currently is, sounds good. Maybe on blogs.kde.org we should just add some instruction how to add your own blog to blogs.kde.org and then link to planet to read the blogs, but nothing more.
I’m personally thrilled by the possibility of a hosted blog service for devs. Bonus points on using Gitlab infrastructure. That would remove one of the excuses blockers I’m finding to start blogging about KDE stuff.
I have never heard of Decap, may be a a good happy medium. Either way, you are right that the current HUGO/git combo is really hard for non-technical people (maybe I am speaking for myself…).
Of course we want devs and technical people in Promo! But it is also one of those teams we can point to and say: “See? Non-technical people can contribute to KDE too!”. Hence learning the intricacies of Hugo, merge requests, and git in general just to proofread a blog post should not be a requirement for new Promo contributors looking to help.
I feel like this is an awesome idea, but this would mean maintaining some custom implementation, yeah?
Despite going counter to the only-Hugo proposal, my first thought after reading this was using something like WriteFreely, which I’ve been looking at recently, although I’ve not tried it in production yet. It’s Fediverse enabled (so instantly shareable to Mastodon and Lemmy), uses Markdown, provides multi-user blogging (and the ability to invite writers to colaborate on the same post), and doesn’t focus on having its own discussion system, it’s pretty no-nonsense.
They’re currently suffering from outdated docs, but I managed to fix their Docker setup myself and run it in Podman, even. Sending my changes upstream should make it easy to deploy. I can check how it works in production as well.
What tool(s) does Promo currently use to write copy for major release announcements? If I am not mistaken the announcements system is already Hugo based, so my thinking is that we could use it as a testing ground for Decap. If Decap makes the experience more like wordpress that’d be a win and can inform our choice for the software that powers the dot.
Just to make it clear: we don’t have to use Hugo for the dot, it’d just be preferable to have all blogs on the same tech stack so we can share theming and whatnot. As @aronkvh rightly points out, we’ll want to offer reasonable UX experience for blogs.kde.org anyway.
We use Hugo too and I’m doing the layouting by hand because plamsa and gear announcements have a quite compley layout.
We use Decap already for the akademy website. And I’m quite against using yet another technology because this means writing yet another theme which will quickly get out of sync. I’m already trying to slowly migrate all the remaining jekyll websites to Hugo, so that I can finally start a small visual refresh of our website (it’s already 8 years old).
Decap only works well on plain markdown documents which is the majority of the page on kde websites. But Announcements - KDE Community are usually using more complex layout that can’t be represented in markdown, so I use a lot of hugo short codes to make it work without using any html (that the translation tooling hate). The issue is that Decap doesn’t handle this hugo short codes well.
Most of the writing is done offline in, for example, Ghostwriter, because writing directly in the GitLab editor is very painful. Then we copy and paste the text over, add media and tweak.
Same goes for articles for the dot, but Drupal is much worse. The process is very error prone, because Drupal has this kind-of-simplified-but-not-really HTML thing going on. That would be sorto of okay, but Drupal has a tendency of effing up the editable-readable formatting between sessions, making it impossible to edit or proofread, as the whole essay gets scrunched up into one long-ass obfuscated string. When that happens, we have to start from scratch again.
The Hugo/GIT workflow for the announcements is okay. Not great, just okay (I do hate the fact we cannot change anything after translators have started working on the text. That is a gigantic drawback that should be solved at some point).
But for dot, we would want something much more writer-friendly. On a “proper” writer-oriented CMS, you can do all writing, editing, proofreading and tweaking online, as it provides the tools to do that, as well as locking, to avoid another contributor from overwriting your work.
Apologies for airing my peeves. I hope I have provided some insight.
The biggest downside I can think of for the dot is the lack of concurrent editing/viewing Concurrent editing · Issue #277 · decaporg/decap-cms · GitHub. For casual developer blogging it feels exactly like wordpress except a bit more low tech with regards to the media embedding options.
If it looks interesting enough I’ll get us a proper demo setup to play with KDE infrastructure.
Thanks for the chance to try-before-we-buy. It helps a lot.
Unfortunately this is unfit for serious blogging purposes.
There are no layout options for starters and that is a deal breaker. How would you place an image, say a vertical screenshot from a phone, in a column on the right and have the text flow around it? Notice you can’t even resize an image. How do you insert a non-YouTube video or an audio file? There is also no way to create a table or text box.
Of course you could switch to the code editor and start messing around with the raw HTML and styles, but for that we already have… well, what we already have.
These are are just some of the things I have missed with our current solutions at one time or another and have had to do without (which has resulted in an incomplete, cut down article), or had to jimmy some way, often with bad results and always with time wasted when this sort of thing should be a given.
Between hugo shortcodes, partial templates and Decap widgets (the youtube and image posting features in the demo are custom widgets by the looks of it) we could probably make most everything work.
In particular with regards to layouting we may be hitting a UX wall though. Markdown doesn’t lend itself all that well to the described ad-hoc layout requirements - in my experience anyway - consider something as trivial as centering a line… Long story short, I’m not convinced we’ll get to nearly as tantalizing a WYSIWYG experience as we would have with wordpress.
The question with all this is of course: are we willing to spend time on this, and who’s gonna do it. Any takers?
That is a general problem really. Also with wordpress. We don’t have a wordpress theme that aligns with our kde.org hugo site theme nor do I know of anyone who would work on it or maintain it to keep it synced up with the hugo theme. It’s not like we have a made bed on the wordpress side either.
I am not sure where that leaves us.
We have Hugo without complete promo team buy-in and Wordpress without complete web team buy-in. We may have to fudge the requirements a bit I fear.
Perhaps I should explain my motivation a bit: The reason my original proposal specifically talks about Hugo is because we can easily move from Hugo to something else if we find Hugo wildly crappy, precisely because of what makes content creation such a pain - Hugo’s text format is fairly “low-tech”. The same cannot be said about Wordpress. So… If nothing else Hugo is at least a stepping stone away from Drupal.
I would like to point out that Kdenlive, LabPlot, Krita all use WordPress, as do Nate, David E., and many more devs and community members, albeit offsite from KDE.org – that said, Nate has said several times would like to bring his blog onsite.
WordPress is the most used blogging/CMS platform for a reason and we have used it enough to know it will provide what we need. I understand the effort and work it will entail, but maybe the smartest move would be to bite the bullet now and work on providing official support for WordPress at KDE. It may be worthwhile committing all the way and not risk having to start over in a few months time when the compromise solution proves to be inadequate.
