[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: KControl Module Guidelines
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-02-07 22:12:50
Message-ID: 200402072312.50031.frans.englich () telia ! com
[Download RAW message or body]

On Saturday 07 February 2004 17:56, Aaron J. Seigo wrote:
> this document is a KDE4 document. i think we should get that much really
> clear right from the start. getting in line with this document will require 
> us to do things that aren't appropriate in the KDE3 line, such as further
> panel reorg, renaming Peripherals to Hardware, etc. i'd suggest we assume
> that what we are describing is KDE4. 

Hehe.. I've already changed Peripherals to Hardware, and moved the laptop 
stuff to it. Anyway, the changes are really small so they are easily 
reversed.

> this will give us enough time to both 
> write the thing and implement the changes. we have between a year and a
> year and a half to finish.

The ideas I have involves code changes which easily can be achieved during a 
minor release. You mean we should wait until KDE4 because the code changes 
you had in mind requires it, and so our ideas can mature. 
I think a lot of stuff can be done incrementally. I also think it is a good 
thing if it's done often - it is proven that organizing KControl is difficult 
- we need to be able screw up, and let it evolve over time, accepting 
failures(I'm not saying we should go wild). I think you can draw a direct 
parallel to the Kathedral & Bazaar concept - if we lock us in like mages 
working on our cathedral for a year and do a huge revamp with little user 
input it can go in the total wrong direction. Instead if we start in 3.3 we 
will have two extra releases 3.3 RC/beta and 3.3 sharp, with user feedback 
and reviews to sanity check us and see if we are going in the right 
direction.
If we /assume/ we reach roughly the same result if we would have waited to 
KDE4 as when aiming for 3.3 the chances are actually higher we reach a better 
result if we aim for 3.3 since there we will have user feedback, reviews etc. 
For example, perhaps we agree not to have it like the moves I just did, but 
it will be "ventilated" during 3.3 development.

Feel free to elaborate on this subject, but AFAICT the coding changes is small 
enough for 3.3 and isn't 6 months(3.3 time scale?) enough for thinking out 
what to do? With smaller changes, and more feedback I think it will be easier 
to keep the feet to the ground.

Is there some specific parts of the guidelines we need to wait with? Those 
parts which are a little bit unsure should definitely go in so they can be 
tested in real life conditions(atleast during 3.3 development). Ideas which 
are "visions" really need to mature as mindfosters. What parts are to 
intrusive in the guidelines? 

My two cents,

		Frans




_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]