[kde-guidelines] The principle of guidelines.kde.org -- one step further

[Frans Englich]

Hello all,

The formation of our websites affects how easily information is found, and how 
swiftly it is to infiltrate and join development -- the threshold of KDE as an 
organization. I think, the positive effects we achieve by keeping all 
guidelines in one place, can be taken one step further.


All websites wants traffic, because their usefulness emerges from it. Websites 
are meeting places where people share ideas, and those ideas is what becomes 
the website's content. It's similar to how open source applications' quality 
is proportional to its amount of users.

When a website have visitors, that ensures content is updated, typos are 
fixed, it's properly maintained, and so forth -- because it matters to the 
visitors. When the website have users, the website lives, and doesn't die.

A website can miss users because it doesn't have relevant content(there's no 
reason to visit), there's too high competition(users visit other sites), or 
that content is spread out among different websites to the extent it have 
become diluted.

How does our future currently look?

Application developers have guidelines, usability, accessibility,  
 and developer.kde.org, as well as openusability.org to visit. Artists have 
artist, and guidelines.kde.org, as well as kde-look.com. On top of that, 
there's The Dot.

usability and artist.kde.org have, looking over a timespan in years, been 
unmaintained and dead, because there's few reasons to visit them. 
developer.kde.org is also in a quite rusty state, it could be much better. 

Imagine, if we had one developer site, and how that would affect what people 
read, and how good it maintenance state would be. If usability news were 
posted, people would read it because they didn't have to visit a specific 
site for "minor" news -- they would read it among all other developer news.

We want as much chaos, brain storming, and movement, as possible. But we 
want another thing too: Developers with broad competence. Not mad scientists.

This tackles the idea of keeping all guidelines in one place, 
guidelines.kde.org, perfectly: Different topics are not thrown into their own 
isolated corners, but are kept together, which results in a broad, 
wide-minded, competence. We want this -- not code monkeys buried in 
technology, but which have insights in all aspects they daily touch, such as 
usability. Because that's what in the end makes the guidelines matter -- 
implementation.

This can be achieved by mixing the content. In other words, we can 
bring developer focus on for example usability, by having it out in the open, 
instead of where it isn't seen. A way of "sneaking" the content upon the 
developers.

Before my main point is explained, a future project of mine is closely related 
to this. 

It is hard for developers and 3rd parties to use the KDE technologies since 
the notes are hidden in informal READMEs and text files in the CVS 
repository. It's unacceptable that building upon the KDE technologies requires 
checking out our inhouse development modules.

Combined with the content of developer.kde.org is loosely organized, 
scattered and vague -- but good things once one have found it -- I have in 
plans to organize what we have, into a KDE Development book. Specifically, a 
reference book which covers KDE technologies such as KConfigXT, autostart, 
DCOP, and so forth, at a high level, roughly as replacement for 
developer.kde.org(docbook). This needs KDE in order to have a 3rd party 
appeal.

What is my point with all this?

I would like, that we as long term goal aim at one central developer site. 
Just like Apple and GNOME has it, but we will by no doubt reach a much better 
result.

One major advantage would be purely technical. Everything would be written in 
Docbook, with the flexibility that brings. We would build a driver frontend 
to our API reference so all documentation could do exact references. 

We would let Cocoon handle the transformation chain, so it was taken care of 
automatically(cached). PDF downloads available for each page(print only what 
you need). We could show related commits, and display just added 
icons(feeds). Navigation would be generated automatically. A news engine 
would serve related news -- usability commentary on the net, and technical 
articles.

Maintenance would be a breeze -- which it also would be, considering how 
central and well visited the site would become. Usability and accessibility 
news would not only be read by the respective nerd visiting those separated 
sites, but also by the coding nerds, and everyone else who visit that central 
site. Our much important guidelines would be made readily available and have 
the impact they need.

Another reason is it would be good to have the future KDE Development Book in 
the same infrastructure as the guidelines currently being worked on: Same 
quality control, shared styles(which Lauri and Jan wrote?) and technical 
infrastructure.

Would this mean artist and usability.kde.org will be shut down? 
artists.kde.org -- yes, it's dead, and content will no matter what be located 
elsewhere. 

Regarding usability.kde.org, I hesitate a little. My plan was to blow life 
into it with KDE Usability Articles and the brushed up HIG, but they both got 
killed. Currently it doesn't have much value, and there's little reason to 
visit; there's a couple of links and contact information, which just as well 
could be at developer, as for other topics. The ideas which was supposed to 
be used(Recent Discussion, Style Guide Issues, Usability Reports) haven't 
been -- there's no activity. I think it would be strategic to let 
openusability -- which is superior -- and developer.kde.org become the two 
main points.

It's great talented and driving people(Celeste) have gotten their hands dirty, 
but I think an even better result can be achieved by pushing elsewhere. 

There's tons of work to do in KDE, and changes which can ease maintenance is 
of interest.

What does it practically mean? Since it can take a while before this 
second-stage documentation effort is started(I have some other project right 
now), everything continues as currently planned, with the only difference 
that we commit to www/areas/developer, instead of www/areas/guidelines. We 
use guidelines.kde.org temporarily, and when the integration is done, 
everything is merged into www/areas/developer, and developer.kde.org starts 
serving the new grande site. That's all -- www/areas/developer instead of 
www/areas/guidelines.


I have written this before, but there was no reply.

What do people think?


Cheers,

		Frans