Projects/kde.org/Planning

KDE Websites - Planning for the future

Contents:

1. Introduction

   1.1 Points for consideration

2. The current state and purpose of the KDE.org websites

   2.1 Current sites
       2.1.1 Introduction
       2.1.2 List of KDE.org main features
       2.1.3 list of KDE.org sub domains
   2.2 Purpose of current sites
   2.3 Future requirements

3. Porting KDE.org websites to a CMS

   3.1 CMS Options
       3.1.1 Drupal

4. Designing for Open Collaboration Services

1. Introduction:

This documents purpose is to define some direction for the furthering of the KDE community as it pertains to the kde.org websites.

1.1 Points for consideration:

   * Where are we currently?
   * Where are we headed?
   * What obstacles are in our path?
   * Porting of kde.org websites to a CMS system such as Drupal
   * Designing of systems to accommodate open collaboration services
   * Centralizing the management of users, information and services for all parts of the KDE community

2. The current state and purpose of the KDE.org websites

2.1 Current sites

2.1.1 Introduction

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

2.1.2 List of KDE.org main sections

   * About KDE

   * Download

   * Community
   * Develop
   * Explore

2.1.3 List of KDE.org sub domains

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: http://techbase.kde.org/Projects/kde.org/Site_Status. Please note that these lists may be out of date and incomplete.

   * http://dot.kde.org[1] (News About KDE)
   * http://events.kde.org[2] (Events Worldwide)
   * http://enterprise.kde.org[3] (KDE for your business)
   * http://ev.kde.org[4] (Association of K Desktop Environment)
   * http://docs.kde.org[5] (Searchable Software Documentation)
   * http://wiki.kde.org[6] (Community Wiki)
   * http://konsole.kde.org[7] (Console Emulator)
   * http://printing.kde.org[8] (Printing System)
   * http://games.kde.org[9] (Games Center)
   * http://kooka.kde.org[10] (Scanner Manager)
   * http://noatun.kde.org[11] (Noatun Media Player)
   * http://phonon.kde.org[12] (KDE Sound System (for future use))
   * http://multimedia.kde.org[13] (Multimedia Center)
   * http://utils.kde.org[14] (Utilities)
   * http://extragear.kde.org[15] (Good apps not part of the KDE official Release)
   * http://techbase.kde.org[16] (Programmers Team Home )
   * http://lxr.kde.org[17] (Source Cross reference )
   * http://websvn.kde.org[18] (WebSVN )
   * http://bugs.kde.org[19] (Bug Database )
   * http://lists.kde.org[20] (Mailing lists )
   * http://quality.kde.org[21] (Quality Assurance )
   * http://usability.kde.org[22] (Usability )
   * http://accessibility.kde.org[23] (Accessibility )
   * http://l10n.kde.org[24] (Translators )
   * http://freebsd.kde.org[25] (FreeBSD Packagers )
   * http://solaris.kde.org[26] (Solaris Packagers )
   * http://women.kde.org[27] (Women in KDE )
   * http://appeal.kde.org[28] (Appeal )
   * http://spread.kde.org[29] (Promotion )
   * http://kbabel.kde.org[30] (KBabel )
   * http://kdesvn-build.kde.org[31] ( Build KDE from SVN Sources)
   * http://edu.kde.org[32] (Educational Software )
   * http://kpdf.kde.org[33] (PDF Files Reader )
   * http://amarok.kde.org[34] (Music Player (unofficial site))
   * http://kopete.kde.org[35] (Instant Messaging (Messenger, ICQ, Jabber...) )
   * http://kmail.kde.org/[36] (E-mail Reader )
   * http://konqueror.kde.org[37] (Web Browser )
   * http://download.kde.org[38] (Downloads ) 

2.2 Purpose of current sites

2.3 Future requirements

3. Porting of KDE.org websites to a CMS:

3.1 CMS Options

   3.1.1 Drupal
   Why Drupal?

   * Positives
         o Well supported application
         o Good community
         o Scalable
         o Proven - used by large corporations
   * Negatives
         o Less flexibility than custom app
   * Scalability
         o An interesting article on some issues with Drupal (2007 = a bit old)
   * Extensibility
         o Drupal Services API (http://drupal.org/project/Services)
   * Modularity - Drupal was designed to be modular
   * Future proof
         o Drupal 6 - current stable release
         o Drupal 7 - on the horizon with big changes
         o Should we wait for 7?

Converting current website pages to Drupal pages:

   * Methods
         o Manual copy/paste
               + Positives
                     # Ensures everything is copied and works
                     # Gives an opportunity to review the content
               + Negatives
                     # Slow
                     # Time consuming
         o Automated script
               + Positives
                     # Speed
               + Negatives
                     # Accuracy
                     # Obsolete Data ported too
   * Research for Automated Script
         o How does Drupal store page data?
         o How do we determine needed data?
         o How do we handle corrupted data?
         o Shell script or PHP for conversion? Gimme egrep :D
   * Theme
         o Re-create Oxygen theme for Drupal 6.x
         o Changes to current theme? Visual refresh?

4. Designing for Open Collaboration Services:

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.

Method:

   * Feasibility study
         o Can we unite management of programs like SVN, kde.org and kde-look.org?
               + Who are we trying to unite?
                     # Amarok
                     # KDE-Look.org
                     # all KDE.org sub-domains
                     # Konversation
               + Physical location
               + Leadership/Direction
               + Technical Problems
                     # Scattered Databases
                     # Different CMS's
               + Contact relevant communities regarding their thoughts
         o 'Akonadi' for the web
               + Centralisation of all data and users
               + Too much scattered information to go in one big database structure?
               + Performance Issues
   * Design phase (assuming feasibility study succeeds)
         o 'Akonadi' for the web
               + Database design
               + API design
               + Open Collaboration compliant
               + Separate application or Drupal module?