Hi. I had a discussion with Aaron on his blog (<a href="http://www.blogger.com/comment.g?blogID=7615673&postID=114537056816755856">http://www.blogger.com/comment.g?blogID=7615673&postID=114537056816755856</a>), but did not get the ultimate answer to my biggest concern.
<br><br>Aaron stated that KDE team has prepared the full UI and feature set related documents before they started actually implementing them. That's awesome! It means that there are documents describing what will be the feature set of KDE4. What will be the UI of the KDE, cases of workflow, target group, challenges, maybe there are charts, mockups, templates, there should be some docs about user interaction...
<br><br>The only problem from my point of view is that those docs are not known to community - including myself - and thus people actually don't know what KDE4 will be. And this problem is WAY wider than just curiosity of small group of people - it's about a reliability, predictibility, and cathedral vs bazaar problem. Can anyone tell me where those docs are?
<br><br>No company/project can currently rely on KDE4 because they don't know what it'll be. I assume that KDE team shared their vision with Mandriva, maybe Linspire, maybe some other distros which are totally kdeish. But noone else can prepare his own plans in tie with KDE4.
<br>More, it's users not only has TOTALLY NO influence on what KDE4 will be - since they were not invited to the discussion about KDE4 UI and feature set, but also they even cannot predict what will KDE4 be. So, Joe Average, who wants to use KDE, cannot say if he will want to use KDE4, because he doesn't know. And, against all good habits of Open projects, KDE team seems to focus on "big wow" instead of "release early, release often" method.
<br><br>The only reason for not publishing those documents (assuming that those docs are not published, and it's not only me who missed them) I can find is that it could start a laud discussion. But from my experience, the only reason for which people refuse to know other opinions is when they're afraid that they can be wrong.
<br><br>Also, from my discussion with KDE team members on the IRC channel, I got the picture of the project which doesn't believe that the community can help. It's a blind circle. If you don't let them help, they cannot do this. And if they cannot do this, you get no help.
<br><br>Aaron said during that comment thread, that if I want to help I can join one of the various projects - Oxygen, KDE docs, KDE QA... It's a problem. You should not require people to be a part of the project, any project, to let them help you. If Zeldman or Mayer would like to suggest you improvements to your website, would you ask them to join KDE Web Dev project first? If Jakob Nielsen would like to spend a few minutes and point you out the major flaws in your KDE4 UI plan, would you require him to join KDE4 project?
<br><br>The best moment, to let the plan get under the heavy discussion is just passing by. Once you already created the libraries, you will have to spend ten times more effort to redesign it if someone will point you a flaw than if you'd listen first, before acting.
<br><br><br><br>
Examples of UI/Feature set docs:<br>
1) <a href="http://wiki.mozilla.org/Firefox2">http://wiki.mozilla.org/Firefox2</a><br>
2) <a href="http://wiki.mozilla.org/Firefox:Home_Page">http://wiki.mozilla.org/Firefox:Home_Page</a><br>
3) <a href="http://wiki.flock.com/index.php?title=Cardinal:Specification">http://wiki.flock.com/index.php?title=Cardinal:Specification</a><br><br>Greetings<br>Zbigniew Braniecki<br>