Decision making processes in KDE (?)

[Matthias Welwarsky]

--Boundary-02=_rjO69F63G0jKgSL
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Content-Description: signed data
Content-Disposition: inline

Hello all,

now that the list has settled a bit, I'd like to sum up some of the thoughts 
going 'round in my mind. The main topic I'd like to talk about is how 
decisions are being made, if they can be delegated, if they should be 
delegated, and how conflicts can be resolved quickly.

Basically there's the question: "Does KDE need a formal decision making 
process or not?" What aspects of KDE development should be decided by a 
formal process?

Until now there has been no formalized process at all. This has some good and 
some bad aspects. The good thing is: there are no rules but only common sense 
or technical consideration. This speeds up the making of decisions 
enormously. However, it only works for small groups of people. For large 
groups, there's no common sense, and large groups of experts will discuss 
endlessly on technical matters.

You may argue that KDE _is_ a large group of people, but actually that's not 
true. "800+ CVS accounts" is good for marketing the importance of KDE, but 
it's of course not the truth. KDE is small groups of people. Are there any 
project teams that actually have more than a hand full of regular 
contributors? Think of a team as "people who need to communicate to 
accomplish  something". 

I dare say that any team with more than 4 people cannot argue based on common 
sense, and few more people cannot argue based on technical consideration. 

Conclusion: KDE only worked up to now because there were nearly no conflicts 
that needed to be settled involving more than a few people. Conflicts 
involving larger groups were settled by divine intervention (Coolo or Waldo 
or someone just did what deemed the correct thing to do for him), or were not 
settled at all. 

Recent example: KMail maintainership. This conflict could not be resolved by 
technical means. The group was to large to base arguments on common sense. 
So, it was _not_ settled at all. It was delayed into the future and has 
reemerged now that the pressure of the release cycle is gone.

So, what do you think formalized decision processes would change? Nobody in 
KDE has any obligation to anything but KDE itself, and KDE is diffuse, 
without a clear outline or direction. So, anyone can make anything out of his 
dedication to the KDE project. Why would he obey any ruling, be it based on a 
voting, or on a dictatorship.

So, there's the question of "Who votes?". There's no "We, the people". Based 
on what attributes would we decide who has the right to vote. CVS account? 
@kde.org email address? Number of bugs fixed since the last release? We have 
no established rules on how to get an account or a kde.org-email. 

How would we force rivaling developers to obey a decision? How would you stop 
a Don Sanders from interfering with KMail development, given that the 
majority of votes decided so?

Note that I don't say that KDE _cannot_ have formalized processes, but that we 
must be aware of the difficulty of implementing them. I _do_ say that we must 
be extremely careful about what we regulate and what not. For me it seems to 
be clear that there is not the easy way of just adopting another projects 
regulations. They won't fit the KDE way. 

I also say we should not concentrate on what we regulate, but firsthand on how 
we're going to enforce the rules.

Perhaps we should have a look at history, maybe at the American Constitution, 
not at its content, only at the way how it was implemented.

In one of my most famous books, "Dune", young Paul Atreides was asked: "What 
is leadership?" and he answered: "Someone gives orders." He was then told he 
still had a lot to learn.

regards,
	matze

-- 
Matthias Welwarsky
Fachschaft Informatik FH Darmstadt
Email: matze@stud.fbi.fh-darmstadt.de

"all software sucks equally, but some software is more equal"

--Boundary-02=_rjO69F63G0jKgSL
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA96OjqANO+fpRuZ2IRAm+QAKCvyb8mGpaX1n71ECBwK9f20J0/3wCgsWe7
tBHneUhAmiYc+cVso7l3J1w=
=dcHH
-----END PGP SIGNATURE-----

--Boundary-02=_rjO69F63G0jKgSL--