[haiku] Re: How Haiku makes decisions

  • From: hudsonco1@xxxxxxx
  • To: haiku@xxxxxxxxxxxxx
  • Date: Thu, 02 Sep 2010 10:35:07 -0400

<kit said>




I agree that the decision process should be laid out somewhere outside the 
mailing list. There should be a page on the Haiku official site where we can 
point people to.

That said, I should remind readers that We Are Not A Democracy (tm).

The big decisions in the project are usually made by developers inside a small 
group, and sometimes one developer counts as several, and can have veto powers.

However, most of us are ok with that. We have a community obsessed with 
bikesheds [1], just like most communities, so  the current model keeps the 
project reasonably productive.

We do use the voting process for many decisions. This process does not always 
end up in a choice made by popular vote, but sometimes it is. Other times, it 
at least allows decision makers to discuss and weigh the benefits of each 
option.

Andrew, please do not be discouraged by this. In a way, being like this can be 
vital to the survival of an open source project.

On one side, this means that you will be burned many times, just like many of 
us. However, overall, you'll end up with a mostly nice tan. :)


Now that this has been cleared up, and if you are ok with this, but you still 
believe this process can be streamlined, then please tell us more.
Personally, I think that the biggest flaw in the current process is that we 
don't always get to the part where an outcome is announced. 

How could we improve that? A special "[Decision Made]" message? A "[Solved]" 
thread?

Cheers,
- Kit

</kit said>


Let me be the first to say that discussing procedural voting issues is not the 
most exciting thing I can think of. But it is necessary for good functioning. 
It doesn't matter to me whether one person gets one vote like a democracy, or 
whether only the core developers vote like an oligarchy. 
I think what is important is that the process is known, documented, 
transparent, and repeatable. Like a Capability Maturity Model, only for making 
decisions. 


I bring this up because I see the issues coming up, I see the discussions going 
quite long, but I don't see the decision at the end of the discussion. 
I assume the discussion goes on until a core developer is convinced something 
should happen then does it. Otherwise nothing happens. 
That is my impression of the process. 


I personally am not discouraged by this, but I am not impressed either. If and 
when the Haiku project attracts many more people, 
disorganization and disunity can cause really big problems. Better to avoid 
them earlier. It's like writing good code, you do a little planning first and 
prevent more debugging, right?


How can this process be improved? I would humbly recommend that we come to 
agreement on what the current process is first.
Is the process documented somewhere? If not perhaps a core developer can please 
step forward and describe the process? 


Regards,
Andrew
 

Other related posts: