Decision making processes in KDE (?)

[Matthias Welwarsky]

--Boundary-02=_PEd69tUSOGX5fP8
Content-Type: text/plain;
  charset="windows-1252"
Content-Transfer-Encoding: 7bit
Content-Description: signed data
Content-Disposition: inline

On Sunday 01 December 2002 00:31, Waldo Bastian wrote:
> On Saturday 30 November 2002 17:35, Matthias Welwarsky wrote:
> > 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?
>

[snip]

> In fact peer-pressure works very good if a) a decision/rule is clearly
> documentated and b) there is evidence that the decision/rule is supported
> by a large (majority?) part of the (KDE) community.

Well, ok, but the main question is: How do you achieve this support?

> > 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.

> For that I think it is necassery to create some sort of criteria and then
> have some body (group of people) evaluating that criteria so that you get a
> well-defined group of eligible voters. I don't think having a @kde.org
> address or cvs account should be part of that criteria, that merily defers
> the decision to whoever gives out kde.org addresses / cvs accounts.

So the first thing to be established is some kind of "congress" of the KDE 
developers. How would we ligitimate this assembly? Probably just by choosing 
the right people to form the assembly. The other developers must trust these 
people enough to delegate this matter to them, without a formal legitimation.

> Now, if we call eligible voters "Registered KDE Contributors", then you can
> go from there and say that @kde.org addresses should only be given out to
> "Registered KDE Contributors".
>
> As a criteria I was thinking something like "must have made considerable
> contribution to KDE in terms of labor, must support KDE social guidelines,
> must have shown commitment to KDE". And then you should clearify
> "considerable" a bit (e.g. more than a single patch) and the commitment
> part (e.g. made contributions over a period of at least 3 months)

If you attribute the "KDE social guidelines", you'd have to have them first. 
Maybe we have some document on some website, but I think it is void because 
it has never been executed in public. The social guidelines will therefore 
have to be set in place by the "KDE congress", or "The Kongress" ;) at the 
same time as the "Definition of the KDE Developer".

Well, let's assume that at this point we have "The people". We probably also 
need somebody who decides what should be voted on. We cannot start voting on 
every matter, that would be the end :). I doubt that we can find a generic 
rule for that, so there have to be people who decide. Of course, we still 
need some rules to support these people.

So, it's rules, and rules, and rules. Bureaucracy, in the end. I guess the 
hardest part will be convincing people that we need all that.

At some point I was thinking that this will not fit "the KDE way". I thought 
that the best way would be to let the project go its own way, and only 
instantiate some instance that settles conflicts quickly where they hinder 
progress of development. I thought of something like a court that developers 
can appeal to if they feel that they cannot arbitrate a conflict on their 
own. This court would never act on its own, only if called to action. This 
"court" would have no fixed group of "judges", they would be well-accepted 
members of the "KDE core group" that are assigned on a case by case basis by 
the rivaling parties themselves - this would also mean that anyone who wants 
to appeal to the court must find someone willing to act as a judge. If the 
matter was not important, nobody would be willing so there would also be some 
sort of self-regulation ;)

However, this idea also needs a defined "KDE core group", which we have not.

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=_PEd69tUSOGX5fP8
Content-Type: application/pgp-signature
Content-Description: signature

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

iD8DBQA96dEPANO+fpRuZ2IRAjTkAJ4rwIF/wf0clwxwU1yzN0vjFXJ8YgCfe8YM
1q8uqhskl26TLIm+EzIbtSI=
=/sgb
-----END PGP SIGNATURE-----

--Boundary-02=_PEd69tUSOGX5fP8--