I'm not in favor of implementing content scanning and profiling based on keywords on the Planet.

It is really not that complex and so much simpler than you think. Check practically any content filtering (pretty much nearly all platforms) where content is tagged by keywords and then you can follow certain keywords. It is the basis of the internet these days for SEO and many other purposes, really.

I don't know how such a filter could work in practice. There's no consensus on when a political topic is a KDE matter or not, as we e.g. saw in the climate change debate recently. As an international community that heavily relies on free traversal of borders many political issues are in our scope, too. Then there's patents, privacy which is a community goal(!), ... And Planet KDE is explicitly not a project news feed - the description of the planet says it's for personal blogs - so a filter based on whether a post is about a project or not would seem go go along its nature. Plus the e.V. and community matters are also "projects" in some sense.

Yes, that is fine. You do not have to set up filters if you like all. But there are people who would like to have special focus on certain topics, e.g. purely technical.

In T12322#212816, @jriddell wrote:

I would be against this as all of life is political so it would mean covering many topic including Free Software and KDE. Discussing politics is a good thing and reading about people's activities and interests outside KDE code is a good thing which builds community.

I would be against this as all of life is political so it would mean covering many topic including Free Software and KDE. Discussing politics is a good thing and reading about people's activities and interests outside KDE code is a good thing which builds community.

+1 - I think it is useful to have content filtering like for emails.

-1 the filter can't be tailored to your idiosyncrasies, if you don't like the title of a post, don't read it.

In T12321#212791, @hein wrote:

This ticket is for making the existing rules more visible, not a filter mechanism, though.

This ticket is for making the existing rules more visible, not a filter mechanism, though.

I think it needs to be more subtle. At least two layers for personal, also. Controversy free and controversy included. As anything, these categories would also need definition. But for example, political topics would fall under controversy for me, especially things like Trump, Brexit, etc. I am happy to read a fellow KDE developer cycling through Europe. But I want to avoid a fellow KDE developer's post about e.g. Brexit.

May I suggest an alternative solution of differentiating between KDE topics and personal topics? Then we could add a filter, same as we do for languages.

In T12298#212614, @jbbgameich wrote:

For flathub (and probably snap store as well), you only need to update the appstream metadata. As soon as a new version is released to flathub which includes this changes, the screenshots will be automatically updated.

For flathub (and probably snap store as well), you only need to update the appstream metadata. As soon as a new version is released to flathub which includes this changes, the screenshots will be automatically updated.

Btw, how can we put these in Flathub and Snapcraft?

suggestions welcome

@ognarb - Thanks for working on this! Maybe for the next step...how hard is it going to be to get a version of it going on a KDE server? Once we get it semi-working on a KDE server, people might be able to provide better feedback too if they can start playing around with a dev site. It sounds like you already have a lot of things set up like 2FA.

I would like to add one more idea: https://kde.org/images/screenshots/ can be removed in favor of https://cdn.kde.org/screenshots/ that mirrors https://cgit.kde.org/websites/product-screenshots.git/

Agreed. https://kde.org/applications/dolphin would be ideal IMO.

Actually https://kde.org/applications/system/dolphin already works and redirects to https://kde.org/applications/system/org.kde.dolphin

In T12058#208627, @ognarb wrote:

@aacid Completely agree, it's the reason why I added a lot of information to https://community.kde.org/KDE.org/Local_Setup.

In terms of /applications, that needs to remain separate because the generator relies on being able to add it's files to the contents of websites/kde-org-applications prior to it being uploaded.

For consideration - one more design.
Text is childish attempt at humor and for sure needs changes, but at least it is not "lorem ipsum".

In T10827#208522, @ognarb wrote:

Cantor got a beautiful website thanks to @filipesaraiva

https://cantor.kde.org/ 🎉

@aacid Completely agree, it's the reason why I added a lot of information to https://community.kde.org/KDE.org/Local_Setup. Since there was only really outdated information until recently and I needed to figure the installation process alone. The documentation is not perfect but at least the main information are here.

I disagree with having magic setup unless there's clear instructions provided

With regards to kdeslides/ these should be shifted to share.kde.org, which means they do not require a Git repository.

This looks like a bug in the theme, a possible hacky workaround in javascript is

Looks really nice and in-line with the overall KDE website theme. Good job!

Cantor got a beautiful website thanks to @filipesaraiva

@adrianchavesfernandez Please request push access :) In the meantime Phabricator diff are also ok

In T11657#208442, @nicolasfella wrote:

https://solid.kde.org/ should die as well

Should I request push access until we finish the migration, or should I use Phabricator differentials?

https://solid.kde.org/ should die as well

Marking as resolved since the redirection will be handled at D25120

@adrianchavesfernandez I created D25120, I can push it if nobody objects

@ognarb Will you take care of the redirection?

I understand the need for branding, but a simple site to display all icons is not really immersive for the user. Taking a look at how Apple advertise their icons on https://www.apple.com/macos/catalina/ you can see that they do a combined showcase of their desktop layout and feature a few core applications which obviously also have their icons displayed on the page. This is pretty effective and subtle.
Microsoft even dials it back further on https://www.microsoft.com/de-de/windows/windows-10-apps and https://www.microsoft.com/de-de/windows/features by not even making the interface the important part, but rather the entertainment and productivity you could have when using them.
A page listing all icons could be done like https://fontawesome.com/icons?d=gallery and similar icon sets do it, or make it similar to how Cuttlefish looks (att. 1).

In T8449#207901, @duffus wrote:

How have you been thinking of implementing these things without diverging from upstream?

How have you been thinking of implementing these things without diverging from upstream?

Ok it was a lot easier than planned to switch to UUID. Literary 3 line codes added and I don't need to modify the client library.

Got it 👍

@joricke the old screenshot in the Konsole website is here because when I did the website, the new split screen feature didn't exist yet. Without maintenance the page are often getting outdated. So yes this is part of this task ;)

One thing I noticed while browsing the re-design candidates: many websites showcase screenshots with features that don't exist anymore. Case in point: the Konsole website shows the old split-tab feature that doesn't work on current builds.
Then there are some applications like Okular using screenshots from KDE3 which is just confusing to viewers.

Uhm, in order to strengthen plasma / breeze branding? I think it can be a nice-to-have.

Why though?

An Integer ID should be fine, my main reason for that was to have something that would be uniquely identifiable across systems as being an Identity account reference.

It will be quite hard to use uuid instead of integer id without changing the code in a lot of place and making the system harder to maintain :( It this a crucial requirement? or is integer id also fine?

https://kde.org/goals

You are right, but I would like to break the connection that KDE is Plasma

@ognarb thanks for working on this

Ok apparently it's using neither the username not the email address for the linking the two accounts since modifying both still recognized to link the account together. I suppose it's using a sort of id. I will need to take a closer look if it's just an integer or an uuid. It's quite easy to change the integer id to an uuid in a django project ;)

Ideally any API would use a UUID or something along those lines - we'd preferrably not rely on any human readable identifier to link accounts (which is what a username does currently with Identity, which is why it is so hard to change those)

In T11714#206052, @paulb wrote:

I will probably add one or two more sections about Plasma mobile and Kirigami/Framework or a section linking to k.o/products, so it's not final yet.

Good idea.

As it stands, the current text is good: short and to the point. Adding a short description of frameworks to this isn't going to hurt.

according to the comment in the code

What is the Nickname field used for in creating account form?

Current progress can be followed at https://identity.carlschwan.eu/ ;) I didn't setup sending mail yet, so let me know if you want to test it so that I can manually give you the link with the registration token.

I've now created https://invent.kde.org/groups/teams/infrastructuretests/ as requested.

Thanks for working on this Carl. For now not having all the necessary functionality working should be okay as it will be a good starting point for us to perform a good assessment of the capabilities of the system and determine what we'd need to do to satisfy the rest of our requirements.

Ok, I will try to provide by the end of this week a working prototype with some but not all requested features and instruction how to deploy without docker and with Apache.

In T8449#197436, @ognarb wrote:

I found another problem, the blender id devs didn't explicitly add a LICENSE file to the repo (there are some mention of gpl2.0+ in the repo). I think they forgot (most of the KDE website repos don't have a LICENSE file too) but I prefer to be sure. So I created a request to add it explicitly.

Having an existing foundation to build anything special we have on top of would be nice yes, especially if they've already done stuff like making an initial OAuth2 provider and an API.

Sure, why not. I'm not sure how much time I can dedicate to this though as I'm quite packed.

Would be also interested in making use of Vue for our websites. Also because Vue has a lovely community behind it. @joricke would you be up to join forces with @ognarb on this?

applied thanks!

I already added a .htaccess to the jekyll branch with some redirection so that the user don't get 404 errors.

Keeping existing URLs might be interesting in one or the other case, probably not all of them.

Should we use https://github.com/jekyll/jekyll-redirect-from to avoid breaking existing URLs, or it does not matter?

I'm sure we can work together :) I'm currently doing the support page (documentation, faq, ...), if you want you can do the homepage ;)

Yes let's close it and redirect to https://kde.org/applications/utilities/

@ognarb I see you started already. Do you want help with this one, or should I pick a different website to port? (I’m not sure how fleasible parallel work on this is)

@ognarb Shall we close this?