find latest status of new website redesign (2010) here: Neverendingo
This document outlines a plan for moving the KDE.org family of websites to a content management system (CMS) and explores future improvements to KDE websites.
The current state of the kde family of websites is quite poor. There are numerous pages and subdomain websites which are out of date, inaccurate or both. Compounding this problem is the lack of any specific maintainers for pages and for subdomain sites.
As well as having a rather large website at kde.org, there are also over 20 sub-domains (each with an independent website), hosted beneath kde.org
I've taken this list from http://www.kde.org/family/. Also, the current status of the kde.org sub domains can be viewed here: Projects/kde.org/Site Status. Please note that these lists may be out of date and incomplete.
As the scope of the KDE project grows, the ability of the KDE family of websites to scale and meet the demands of an increasingly large userbase will become increasingly important. These websites will need to make it efficient to find news, documentation and other content. These websites will also have to foster a community of collaboration among developers and users.
To accomplish these goals, a platform which can support thousands of users will need to be adopted.
Converting current website pages to Drupal pages
One of the main things that came out of Akademy 2008 was 'brining the KDE community to the desktop'. What does this mean? Ideas like 'seeing KDE users nearby' is a good example.
We all know that KDE has a large community that is going through a new phase of growth. Because of this, coordinating, designing and maintaining open collaboration services given the existing scattered state of different sections of the community would be almost impossible. And even if it was possible, maintaining the resulting mess would be an effective step backwards.
If we were able to centrally manage communities and services such as kde-look.org, kde.org and its sub-websites, svn, mailing lists, Amarok, Konversation, etc. then Open Collaboration services would be doable and far more powerful than previously possible.
If you think about the idea behind Akonadi (http://pim.kde.org/akonadi/), why don't we apply this to the KDE web community? Also, once we've done that, why don't we build our own web based 'Nepomuk'? Why not build the KDE community on these same 'pillars' as the desktop? This would make Open Collaboration services one of the most advanced out there for any community and allow the users of KDE unprecedented ease of use and integration with each other. Of course, due appreciation of privacy and security need to be taken into account. And once again, having centralized management would make maintaining privacy and security a lot easier.