What's this all about?
KDE Frameworks, Plasma desktop, and our community have a rich history of nearly twenty years in creating great open-source software, making us a truly historic organisation of passionate developers; and along with that history some of our online infrastructure has begun to show its age. The KDE.org website and its various sections are the front door to the KDE ecosystem, it is how people new to KDE will judge us, and it's where our developers, translators, artists, and community members know their hard work will be presented to the world.

This forum and everyone wanting to participate will have the goal of revitalising the KDE.org website for our 20th anniversary, giving us a strong infrastructure to celebrate a stronger foundation for the next 20 years of KDE, community, and open-source.

Who is participating?
The WWW team, Promo Team, and VDG have all expressed desire to build a better KDE.org, and we'd all like to see the wider KDE community to contribute! You don't need to be a web developer or server administrator to chip in; even if it's a few minutes of feedback or a single idea, we would like to see you participate! We plan to build this website on a foundation of respect and openness - everybody and all constructive input will be welcomed.

What is being included?
KDE.org is big; it has several large sections of curated content, active forums, development tools, wikis, organisational pages, documentation, news, announcements, and more. Some of these systems can clearly be dated back to the KDE 3 days, while others are much more modern. If it's on KDE.org (and some special cases which aren't) we need to bring it up-to-date. This can include back-end software, integrating it more nicely into other systems, and more.

The primary goal will be getting as much as possible onto a modern content management system, and introducing a new lasting design which can be incorporated onto other systems. We will also need to move content onto the new systems, and ensure everything brought in is up-to-date. We also want to make sure that the work being done will be flexible enough to carry us into the future; the long-term decisions made now will be what we maintain for the foreseeable future!

When does this need to be done?
There's no specific goal to have the whole network completed; there's a huge number of assets and each one is unique, but I believe it's reasonable to have many of our most prominent pages and sections converted in time for our 20th anniversary. Beyond that, we'll work section-by-section page-by-page to ensure KDE.org is as amazing as it can be.

Where on IRC can an interested party go to discuss this? I've had a pile of ideas go through my head in the last few months regarding this topic and I suppose it's fortunate that a choice has been made to make a move.

rcharbonneau wrote:Where on IRC can an interested party go to discuss this? I've had a pile of ideas go through my head in the last few months regarding this topic and I suppose it's fortunate that a choice has been made to make a move.

I'd highly encourage you to simply post them a thread here! It will be easier to reference ideas and conversations easily as time goes on if we keep brainstorming and notes in the forum.

OK, before I go hog-wild with the ideas, do we have any platform requirements, database requirements that I should be made aware of? Could you provide the discussion with a list of all of the websites that are in the scope of this initiative?

My nick on IRC is VeryBewitching should the time arise where a more interactive discussion becomes required.

rcharbonneau wrote:OK, before I go hog-wild with the ideas, do we have any platform requirements, database requirements that I should be made aware of? Could you provide the discussion with a list of all of the websites that are in the scope of this initiative?

My nick on IRC is VeryBewitching should the time arise where a more interactive discussion becomes required.

I've been meaning to post the current technical information we've already discussed, I'll do that now in a new thread.

Excellent, I look forward to digging in.

Does this plan also include the development/improvement of application pages?

Like this one: https://www.kde.org/applications/development/kdevelop/

It has most of the relevant information (not all of them do), but it can look prettier. Most important, give the application developers an easy way to update the page. Probably allow them to have a "mini website". Thus avoiding the split of having 2 websites (KDE app site, and application site) (https://www.kdevelop.org/)

A page with a FAQ and links to the userbase wiki to tutorial would do wonders.

ovidiub13 wrote:Does this plan also include the development/improvement of application pages?

Like this one: https://www.kde.org/applications/development/kdevelop/

It has most of the relevant information (not all of them do), but it can look prettier. Most important, give the application developers an easy way to update the page. Probably allow them to have a "mini website". Thus avoiding the split of having 2 websites (KDE app site, and application site) (https://www.kdevelop.org/)

A page with a FAQ and links to the userbase wiki to tutorial would do wonders.

You've pretty much hit all the points we're striving for.

A huge shift in the website will be better allowing projects to self-moderate their pages, and to unify the various disparate systems which can reasonably be integrated. If the results are ideal an application developer will just submit their project to KDE.org via KIdentity, an admin will approve it as legitimate, and then the developer can add extra members, make announcements, update info, add various links, etc themselves.

Several projects do have these secondary websites, but we'll need to approach them on a case-by-case basis to see what happens. I honestly don't know what will happen, as some of them are very unique and have content which might not fit a more generic system. Others simply may not want to give up their unique websites. We'll need to wait and see, but hopefully more than not will simply make the switch.

One idea for the KDE Website Initiative i have and hope to be implemented (if possible) , is to have for each project (or subproject) a tab for bugs , discussions , wiki and show the code. Just like Github has done. I would like the site to be like that because yesterday i was trying to find the code for the joystick settings in system settings -> input devices with no result .
I think each project in the website should have the following:
1) homepage : a page with screenshots , descriptions etc to make it look cool
2) wiki
3) discussions (like a forum) and bugtracking : think of it like the issues tab on a github project
4) code repo
5) any other feature

What's the status of this? Were there any mockups made?

Let's have a meeting (hangout, IRC, mumble) and discuss this.
Is this weekend fine for anybody?

Count me in.

I think we have two possible approaches here

Top Down:
- we make a high level overview of how the entire site should be, with the main heirachy, gloal theme, then go for a big change

Bottom Up:
- we pick the most important pages; and fix the actual content before we worry about styling

IMHO https://www.kde.org/workspaces/plasmadesktop/ is one of the most pressing candidates.

david_edmundson wrote:Count me in.

I think we have two possible approaches here

Top Down:
- we make a high level overview of how the entire site should be, with the main heirachy, gloal theme, then go for a big change

Bottom Up:
- we pick the most important pages; and fix the actual content before we worry about styling

IMHO https://www.kde.org/workspaces/plasmadesktop/ is one of the most pressing candidates.

In this scenario you are assuming that Top Down only means changing the content of a site, including content's styling. But this proposal also includes the change of the underlying architecture, going from old-old capacity to something new (like drupal, as it seems). In that case any content you have needs to be ported first, from a file based approach to a db layer.

This raises the question: Does it make sense to change the content in this file based approach while working out the new system? You would touch each file/app page 2 times at minimum.

Of course it can make sense, if you have something like 2 teams, one taking care of the content itself, the information. Is it up to date, has all the info that is needed? Can be committed right now and you are done. The second team then only takes care of the new system and simply importing the content without even caring of the semantics.

Or you wait for the new system being in place and then reviewing content along with that so you have everything done at once. But this assumes you really have enough manpower in place to work on each part.

From my POV - and even though it might seem as a bit more work - it indeed makes sense to already fix the information we have right now and work on the backend in parallel.

neverendingo wrote:Or you wait for the new system being in place and then reviewing content along with that so you have everything done at once. But this assumes you really have enough manpower in place to work on each part.

I am going to recruit new members to the team. The only information I am waiting for before I start is: will the new site be built with Drupal 8?

Edit: ok, final decision about the CMS has not been made.

Why not use Django CMS? it's python and it's extremely flexible.

ovidiub13 wrote:Why not use Django CMS? it's python and it's extremely flexible.

because it's python? Seriously though, if you want to build a team you should make sure that
- you find enough members to be able to code with that platform and
- the sysadmins are also able to handle the system while running

Python might be nice (though i heard the opposite about Django) but it is questionable if all coders are used to it.