Re: GNOME Enhancement Procedure

[Havoc Pennington <hp redhat com>]

Hi,

Tim has a good point I've also been thinking about for a couple of
days.

An RFP on an issue where many people have already tried implementing
stuff (e.g. config system, or sound API) should go pretty well.

But an RFP on something more hypothetical or not-yet-implemented might
not correspond well to the end result, because as you implement you
realize you hadn't thought about all the issues.

It might be nice to have some way to "amend" an RFP as implementation
work goes on.

Or perhaps we should say that you can't really post an RFP for
nonexistent code, or that an RFP for nonexistent code can only
establish a vague "yeah we would like a solution in that area" and a
further RFP is required to adopt a solution after implementation.
That might chill out the kooky RFPs about GnomeLamp or pie menus or
Berlin ports as well.

(Though those things aren't really requirements - requirements would
be for a "better menu system" not pie menus, pie menus would be one
solution and presumably a rejected one ;-)

Anyone have good ideas for addressing this issue of a) can you decide
on a solution prior to implementation and b) if how can the RFP be
amended to reflect new thoughts while implementing?

Havoc


_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers