Re: How we make decisions... [Fwd: Re: Proposal: replacing esound with polypaudio in 2.10]
- From: Sri Ramkrishna <sri aracnet com>
- To: Mark McLoughlin <markmc redhat com>
- Cc: Davyd Madeley <davyd madeley id au>, Desktop Devel <desktop-devel-list gnome org>
- Subject: Re: How we make decisions... [Fwd: Re: Proposal: replacing esound with polypaudio in 2.10]
- Date: Thu, 18 Nov 2004 23:15:53 -0800
Sorry, I have not responded to this. Evo is broken on Hoary, and I've
been having a hard time keeping up with my mail since. :/
On Fri, 2004-11-12 at 12:19 +0000, Mark McLoughlin wrote:
<snip>
>
> I'd encourage people who are complaining about our decision making
> process to go back and consider the GEP process:
>
> http://developer.gnome.org/gep/gep-0.html
>
> Now, everybody hated the GEP process because it felt way too
> heavyweight and GEPs were, by and large, never concluded. The former
> problem is certainly solvable, but I'm not sure about the latter.
> Possibly have an number of people who own the overall job of making
> people bring GEPs to a conclusion, any conclusion.
Indeed. The problem with too formal of a process is that it takes away
the fun of working on a project. If I wanted formal process I'd get it
at work. We got plenty of that crap there. It doesn't necessarily help
making decision making.
What we're looking for is a pragmatic approach to technology. We tend
to get bogged down by details (eg does it work for non MMU? etc etc) of
either the implementation or what? What it boils down to I think is
this:
* Do we need this technology?
* Is the architecture sane. Can we extend it if we want to in case we
have more requirements?
* Does it have good documentation? If the module goes unmaintained is
there enough information in there for someone to pick it up?
* Does it meet 80% of our requirements and can the other 20% be
implemented in a reasonable timeframe? (this might be redundant with
point 1)
* If it ends up being broken, how do you back out of it?
I prefer to make decision making as simple as we can. The easier the
better.
>
> The process did have some nice properties, though:
>
> - It made people think about what they were trying to achieve:
>
> + Why do we need a new sound server?
> + What do we really need to be better in our new sound server?
> + What worked well with the old one?
>
Thats good stuff.
> - It defined a group of people who were going to voluntarily take
> on the responsibility of co-ordinating the discussion
That still needs to be done. I tend to believe that the people who need
to make decisions are the maintainers of the modules who are most
affected (if any is affected at all). If no maintainers, it should go
to ddl or maybe a seperate mailing list of people who care to
participate in such things. I don't know. Something worth discussing.
>
> - It documented the discussion
Yes, something we miss doing everytime. If you look at the history, you
never actually see a decision made. After a discussion nobody comes
back saying "we decided to do this". Magically, later something starts
showing up. I'm actually cool with that; prior warning though would be
nice.
> I think I'd be happy to try and resurrect the GEP process in a much
> more lightweight form if I thought there would be any enthusiasm for it.
That would be great if you could do that!
sri
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]