Opposition to removing old KWin themes?

[Aaron J. Seigo]

hi all ...

this thread is a great study on "how not to ask questions and make decisions" 
in a community such as ours.

first off, never ask if there is opposition. why? because of *course* there 
is. there will be opposition for any statement, as long as the sample size of 
people is large enough. KDE is pretty large these days. so there will always 
be someone who disagrees with most any decision that gets made. that's life in 
a large community.

secondly, this is an art direction issue. it is not a decision that the 
majority of people who write software as their primary vocation are equipped 
to weigh in on, any more than most of those who do art are equipped to weigh 
in on algorithm choice. (exceptions exist, but they call them "exceptions" for 
a reason.)

thirdly, everywhere else in KDE we have a system of maintainers and 
meritocracy. we fail to extend this allowance to design issues over and over 
again and the only people who are satisfied with the results are ourselves 
because get to "have a say". we are failing the overwhelming majority of our 
users by not allowing those who should maintain the design to do so. how do i 
know this? well, besides the logic behind it, i also live with two such people 
and talk with hundreds if not thousands more throughout the year and the 
message is very, very clear from them.


so ....

this is a decision that should be made by the visual maintainers (in this 
case, that would be the KWin deco maintainer, Hugo for matinaining Oxygen and 
Nuno for coordinating art in many areas of KDE these das) in consultation with 
our real world user base. that consultation will help identify issues such as 
"sending an application over the network is faster when a simpler deco like 
Web and theme like Win95 are used" and "as an old timer with nostalgia, i like 
to play dress up with my desktop so it looks kind of like CDE. it makes me 
happy."

then the visual maintainers can craft a decision based on that input and their 
expertise. some input will be discarded (e.g. "nostalgic older timers are not 
a key decision swaying demographic for this decision"), others will cause 
modifications ("network transparency is important, we need to keep at least 
one minimalist theme").

once a decision has been made, the maintainers should then provide a statement 
of notice saying what decision has been arrived at and why. KDE will rely on 
the good faith efforts of the visual designers to ensure that the decision 
falls in line with our shared goals and concepts, including flexibility where 
it is advantageous.

the days of KDE software look and feel being able to be loosely managed 
communally are long, long past us. we are too large a group with too little 
average expertise in graphic and industrial design to do it "crowd sourcing" 
style. add to this that graphic design is often a matter of taste and that 
different art directors will want to take things in different directions, and 
the conclusion is innescapable: we need art maintainers, and the rest of us 
need to respect that and enable that process rather than hinder it.


my suggestion: let's try this all over again and consider this current thread 
an interesting exercise.

KDE art directors: come up with a set of decisions, ensure to the best of your 
ability they fit KDE's directions and commitments, document the reasons behind 
the decision, then post that decision somewhere it will be read by our 
stakeholders (i'd suggest a blog on planet.kde.org along with a note to k-c-d 
if it is a core matter; and i'm not sure this is).

then implement that decision.

this is how anything else gets done productively in KDE. so be it with art as 
well.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20100726/97ea2ef1/attachment.sig>