Future of the dot

Fri Apr 3 21:24:37 BST 2020

Le vendredi, avril 3, 2020 10:07 AM, Paul Brown <paul.brown at kde.org> a écrit :

> > Loosing comments and their moderation seems like a big downside to this
> 

> > surely if Hugo can't do this we should, if considering moving from drupal,
> > look at alternatives that support what we need the dot to do?
> > I feel the ability to share and work together on an end formated story with
> > images/links (in their final place) is a critical feature to have
> > I'm not convinced how well the proposed workflow would work for
> > non-developers. It sounds pretty complicated compared to a cms
> > While Hugo might work fine for some websites in KDE, I think expecting
> > every web thing we use to be able to be done with a minimal tool like Hugo
> > is a bit unrealistic and there is no need to even try to do this (your plan
> > is also unlikely to succeed completly imho, so we will still have different
> > types of websites anyway)
> > So I think that if we are thinking about moving the dot from drupal we need
> > to have a proper look at what alternatives there are and whether they are
> > better than what we have currently
> 

> Although I don't want to overtax anyone with extra work, I would have to
> agree. From what you are saying, compared to other CMSs, there doesn't seem
> much advantage in using Hugo, at least not for non-developer content creators
> (which is, in theory, what Promo would mostly be made up of).
> 

> My first instinct would be to go with Wordpress, although I understand that
> that was tried and abandoned for some reason.

Hi,

it looks this is getting some push back. I now fixed the problem with the wrong
Url and I will try to fix the few broken page with broken formating.

For the old comments, It will be difficult to export them from the dot to a new system. I
would prefer not to do it, because it is less work, but in case we think this is
required I think we can find a solution and add this functionality to the exporter.

Looking at the last few posts, we can see that there is almost no comment, this is
because it is difficult to create an account and someone needs to review each account
creation manually. (Does anyone is taking care of it currently?)

A solution for commenting would be to integrate Discourse to our infrastructure and
then displaying the comments made in discourse in an iframe in the dot. This would
allow using only one platform for commenting for each KDE websites and provide a nicer
experience for the visitors.

But I think this needs to be discussed more in detail only after the entire GitLab
migration is done because the sysadmin workforce is limited and I think the GitLab
is a lot more important.

Using a static website for promotional websites has some advantages. For Google ranking,
the page speed makes a lot of impact. Generating a static website makes the page faster
to load compared to a CMS. We also get some SEO improvement from Hugo without using third
parties plugins. In a distant future, we could also use a self-hosted Netify instance to
provide a CMS-like interface to GitLab (same here this needs to be done after the complete
GitLab migration).

As for using another CMS, there are various problems:

* We need to find someone with experience with the theme engine of the CMS we want to use.
Using Hugo allows me to reuse existing work. I'm not familiar with the internal of
Wordpress or Drupal and I'm not willing to spend time learning them.

* Creating a theme for another CMS means maintaining a new theme and also another
place I need to patch when I want to update something in the global theme.

* We need to deploy the new system. The current infrastructure support Wordpress, Drupal 7,
Drupal 8 and a bunch of static site generators. Using one of the already used systems
means we can simplify the maintenance. If we were to use something else, it
would mean maintaining yet another system and making sure we make the security update
as soon as possible. Same here we need to find someone willing to do it.

* The user interface of a CMS isn't always more easy to use. The current Drupal interface
is very difficult to use and I still didn't figure out how it works. Wordpress is better
in this aspect but still not very intuitive and I needed a lot of googling to do basic things
like setting the homepage and using a template for a page.

* And I think for an open-source organization like us, it is important that everyone can
run our website on their computer, edit it and send their changes. Currently, with the dot, 

the Akademy website and some other websites only a few people can get the raw content, the
plugins used are not documented and the theme is not open source. So there is currently no
way to run a local version of the website, ... This isn't how I imagined KDE when I read our
manifesto and decided to contribute my free time to KDE. And I really hope this will change in the
future. This is a general complaint I have with how some things are done with our websites
and doesn't concern only the Drupal and Wordpress website. I didn't found any source for
relate.kde.org either, I needed to beg the store.kde.org developers for months to get the
installation instructions for their websites, ...

I hope this clarifies, the reason why I'm pushing for using a static website. And if someone
has a better solution, I would be interested in helping to implement it. 

Regards,
Carl Schwan

> Cheers
> 

> Paul
> 

> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 

> Promotion & Communication
> 

> www: http://kde.org
> Mastodon: https://mastodon.technology/@kde
> Facebook: https://www.facebook.com/kde/
> Twitter: https://twitter.com/kdecommunity
> LinkedIn: https://www.linkedin.com/company/kde

-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - carl at carlschwan.eu - 0x7F564CB5.asc
Type: application/pgp-keys
Size: 3196 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-www/attachments/20200403/95222310/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 823 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-www/attachments/20200403/95222310/attachment.sig>