[kde-guidelines] The principle of guidelines.kde.org -- one step
frans.englich at telia.com
Sun Sep 26 06:07:06 CEST 2004
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
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 --
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
Before my main point is explained, a future project of mine is closely related
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
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
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
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
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
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
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
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
I have written this before, but there was no reply.
What do people think?
More information about the kde-guidelines