[kdewebdev-site] RFC - Final Draft of www.kdewebdev.org vision statement

[David Joham]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Hello all!

This is the final draft of the www.kdewebdev.org Phase I vision statement. It 
is largely unchanged from the first draft. The most significant changes are a 
further definition of the vision of Phase II. 

Please review this document and post any and all final comments. I plan to 
create a final version of this document on Thursday night Mountain Daylight 
Time. Please have your comments in by then.

I apologize for this document being late. My Easter festivities included 
eating more sugar than I've probably had in two months and watching my 
friend's three year old play SpongeBob SquarePants on his XBox while we 
chatted in the living room. As a result, my Sunday evening included nausea 
(from the sugar) and a migraine (from the SpongeBob) and I didn't feel like 
doing anything more than lying on my bed watching the room spin.

Thankfully, I'm recovered now and ready to do some actual work. So, without 
further delay, please find, review and comment on the final draft of the 
Phase I vision statement.


www.kdewebdev.org: 
VISION

www.kdewebdev.org aims to be a the preeminent website for users of KDE's web 
development tools to find documentation, code samples and best-practice tips 
and tricks. The primary goals of www.kdewebdev.org are to allow web developers 
to help themselves, see what KDE offers in the way of tools and other 
development aides and to allow developers the opportunity to easily 
contribute back to the www.kdewebdev.org. community.


www.kdewebdev.org; 
DEVELOPMENT STRATEGY

The development of www.kdewebdev.org can be broken down into two phases: 

Phase I will be the development of a www.kdewebdev.org “umbrella” site as well 
as a “brochure-ware” site for each component in the www.kdewebdev.org family.  
When completed, these sites will serve to educate visitors about the tools 
and technology we offer as well as present a consistent, professional image 
that conveys confidence and trust. 

Phase II will be the development of an infrastructure that encourages 
interactive contributions to the www.kdewebdev.org community as well as 
providing mechanisms to increase core developer productivity. 

This document will concentrate on Phase I, but will touch on Phase II as well.


PHASE I Details

The primary goal of Phase I will be the development of a “portal” site 
(www.kdewebdev.org) that will professionally introduce visitors to the tools 
we offer and to convey a sense of cohesion. We want visitors to easily be 
able to see what tools are available, what they can do and to understand that 
these tools have been designed and developed to work together.

At a high level, www.kdewebdev.org  should (at a minimum) convey the following 
information to a visitor:

 * Introduce www.kdewebdev.org as an “umbrella” site for KDE's web tools
 * Briefly introduce the tools that are available and their features 
 * Provide a news area 
 * Provide one or two high level screen shots of each tool in action
 * Provide a FAQ
 * Provide links to access all <tool>.kdewebdev.org sub domains.

A good use case for someone who would use the www.kdewebdev.org web site would 
be a new KDE user who is trying to figure out how to replace FrontPage, 
Dreamweaver or any other tool (s)he is used to using. This user has never 
heard of Quanta or any of the tools we offer and needs to have a place where 
all of the available tools are presented in summary so that (s)he can easily 
match a development need with an available tool.

This “portal” site can almost be thought of as a teaser site. It won't have 
much detail about the tools themselves – rather it will have a one or two 
sentence description of the tool that invites and encourages the visitor to 
visit the tools, <tool>.kdewebdev.org subdomain for more information.

In Phase I, these <tool>.kdewebdev.org sub domains should (at a minimum) 
convey the following information to a visitor:

 * Introduce the tool and what it does 
 * Provide a feature list
 * Provide screen shots (if appropriate)
 * Provide a way for user to get support (mailing lists, etc)
 * Provide documentation on the use of the tool 
 * Provide instructions on how to get the tool
 * Provide a FAQ (if appropriate)
 * Provide contact information (if appropriate)
 * Provide a way to get back to the main www.kdewebdev.org site 

All <tool>.kdewebdev.org sub domain web sites will share a consistent user 
interface – further reinforcing the idea that KDE offers a suite of tools 
that are designed to work together.

When we are finished with Phase I, we will have a consistent, 
professional-looking web site that allows users (even ones that have never 
heard of us) to easily find  the tool that is right for them and the 
information they need to use it. We can then proceed to Phase II.


Preliminary PHASE II Details

There are two primary objectives of Phase II:

1) Manage growth in the CVS module 

As the project grows, the developer noise load and project complexity 
increases. A chief aim is to anticipate user concerns to divert noise as well 
as provide a central cohesion, focus and clarification to the development 
process. The developer support will both assist developers and inform users.

Examples of "noise" are the following:

* Red Hat released 3.0pr1 in 8.0 which was a disaster
* 3.1.4 had a serious delete bug in it
* Mandrake's 10.0 community release has a bad CVS snapshot

Each of these "incidents", be they an accident on our part or less than
spectacular judgment from a distribution, creates "noise" for us answering
repetitive emails and doing damage control. Also we can see by the age of
them they become less relevent with time but highly relevent when they are
first discovered. 

We need to be able to disburse important information for easy assimilation by 
users, including smaller issues like little fixes that come up on mailing 
lists. Additionally, we need to actively do damage control when necessary. 
Many users that have binary distributions  have a subjective opinion of our 
product that is based on how well their distribution packaged our code. 
Depending on the quality of the packaging, this opinion can be donwright 
terrible! We need to be able to point them to a page, and frankly stick 
distributions that have done less than good things feet to the fire. We 
should seek to control our reputation and destiny.


2) Create a www.kdewebdev.org shared code commons 

A www.kdewebdev.org shared code commons  will allow our users to build a 
community around our site. This community will add value to their use of the 
www.kdewebdev.org tools - hopefully leading to more sponsorship opportunities 
as a result.. 

As appropriate, each <tool>.kdewebdev.org sub directory should have the 
capability for users to upload materials that will help other developers use 
the sub domain's tools. This will include items such as Kommander scripts, 
JavaScript code and other items. It will be very important to develop a 
mechanism to ensure proper licensing schemes are followed as well as a policy 
to deal with conflicts as they arise.


Phase II objectives will be fully defined in a separate vision statement. The 
initial Phase II ideas are presented here to provide Phase I developers the 
insight into where the www.kdewebdev.org site is going so that they might be 
able to make appropriate design decisions in Phase I to accommodate Phase II.





-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfJMOdGtRHnP4AioRAor7AJsGgjsK2VUy9D7xuY+e19dbdAg1UwCgki4z
AsJQlNsHj51TkkjHzt54tZA=
=+BxI
-----END PGP SIGNATURE-----