Decision making processes in KDE (?)

[Zack Rusin]

On Saturday 30 November 2002 11:35, Matthias Welwarsky wrote:
> 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.

Excuse me? You just couldn't pick a worse example :) In the conflict 
between Don and Michael both parties had very good arguments. Don was 
completely ready to fork at any moment. Now you're saying that it would 
be good if people not related to KMail development would come by and 
say "Hey, Don we do not like what you're doing and we have to remove 
your KDE CVS access". Don forks KMail outside KDE, some developers go 
with him, some stay. For one I'd be extremely unhappy, to say the 
least, if a group of people from outside the KMail team would cause 
such a fork. The other problem would be whether the cvs accounts of 
people who joined him should also be deleted.

I very much liked how Dirk resolved the problem for 3.1. KMail 
developers were voting. Simple as that. Now you say that conflict 
wasn't resolved then. I say it was. It was resolved because if you look 
at KDE 3.1 you'll notice that KMail in there is working great and if 
you look at the code in CVS you'll notice that just days after 3.1 
KMail has already a mindboggling amount of new code features and 
architectural cleanups. And, for me at least, you measure the success  
by the quality of the application. 

The fact that the problem "reemerged" as you put it, had nothing to do 
with the fact that it wasn't resolved. Michael stopped being the 
maintainer. We needed a new maintainer. During the 
3.1/make_it_cool/kroupware branches we argued because we couldn't agree 
on how the future of KMail should look like. We all had our visions. We 
resolved those problems, as can be seen by reading the maintainer 
thread. All KMail developers agreed that Ingo should be the maintainer. 
Also in many of those emails one can spot smileys and notice the 
overall better atmosphere following our replies to each other. Ingo 
showed that he's going to be a great leader by allowing Don to be the 
co-maintainer and making sure KMail is not going to be forked and 
that's it. 

Now imagine what would happen if you'd take a poll among KDE developers 
what should happen. KMail developers wouldn't solve anything. The 
conflict would just escalate. 

There just can't be one way of resolving conflicts. Meaning you can't go 
and say "OK, we take a poll among KDE developers who's going to be the 
new KSomeApp maintainer, Bob or John". Half of the people would go 
"What's KSomeApp?", others would pick Bob because they knew him from 
IRC, some would go with John because they tried KSomeApp and didn't 
like it so they'd figure that Bob is doing a bad job as the current 
maintainer, etc. None of the above is a good reason in itself to vote 
for either of them, but that's how a vote between people not related to 
the main development team of KSomeApp would look like.

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

What we regulate? I think it's quite simple, we regulate when an app in 
our CVS goes against 
http://developer.kde.org/documentation/licensing/policy.html . We email 
the author saying that it's a requirement that his/hers app obeys those 
rules and there's no exceptions for it. If the author refuses his app 
is removed from the CVS and possible, depending on the author behavior 
his/hers account is removed. Period.
I don't think anything else should be regulated by KDE itself. Conflicts 
should be resolved by the teams themselves.
Now the question is how do we protect our CVS users. I'd propose 
imitating court rules here. (Stay with me here :) )
The KDE Release Coordinator acts as a judge. Now lets say team of the 
KSomeApp divides itself and they just can't and don't want to resolve 
the conflict between themselves and it's a mess. We have two sides one 
supporting John the other Bob. Both sides are required to present their 
case to the release coordinator. The email send by both defendants have 
to be signed by at least one other developer with KDE cvs commit 
privilidges. If one of the defendants is unable to find a developer 
supporting his claims, he automatically looses. 
In the email to the release coordinator both sides have to include a 
name of another KDE developer who is going to act a supporting judge. 
That developer can not be the one who signed the message and can't be 
one of the developers of KSomeApp. 
Now we have three judges (release coordinator, and supporting judges 
picked by both sides). If release coordinator doesn't understand 
anything from the emails sent by either of the sides. He/She can ask 
either side to clarify. The three judges take a vote. One of the sides 
wins. That's it.

Zack

-- 
The word "woman" is no longer politically correct.
You should use "Female-American" instead.