Re: How we make decisions... [Fwd: Re: Proposal: replacing esound with polypaudio in 2.10]
- From: aigiskos <aigiskos yahoo com>
- To: sri aracnet com, 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: Fri, 19 Nov 2004 21:16:54 -0800 (PST)
Besides the formality of it, the worst flaw of the GEP
process was that it was not clear who made the final
decision. So, much as in the mailing lists, people
would argue about a topic, the topic would die, and,
unless a clear consensus had been reached, people
would think, "Now what?"
Especially as the GNOME community/project grows
larger, it will become necessary to delegate certain
decisions to a decision-making body or have some sort
of referendum of registered voters, so to speak. It
seems we have the groundwork laid for such a process
throught the GNOME foundation, which has members who
can vote. We even have a voting system in place.
~Andrew
--- Sri Ramkrishna <sri aracnet com> wrote:
> 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
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
>
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>
=====
~~~~~~~~~
dissertus scribendo latine videri volo.
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]