GEP discussion

[Havoc Pennington <hp redhat com>]

Hi,

Moving to foundation-list since that's marked as where gep issues will
be discussed.

Alexander Larsson <alexl redhat com> writes: 
> So, nobody is commenting on this, I'm blocking on the silly gep, jwillcox 
> is blocking on me moving the code into libgnomeui for panel recent 
> files changes, campd is blocking on jwillcox for the panel changes to do 
> recent files from nautilus.
> 
> Basically, shit is not happening, and people get irritated. Can someone 
> PLEASE explain to me why doing a gep for thing like this is good?
> 

I think your GEP as written, and for this specific situation, is
clearly pointless. This is a combination of a) the particular changes
aren't very controversial b) the GEP itself contains very little
information.  Probably other issues as well.

However just putting a largish API in libgnomeui with no public
announce or rfc is not great.

For this concrete case I think the right sort of GEP would be just the
content of your original mail on the subject - "here is the API" and
basically ask "any objections?" on the announce-only gep list, give
people some time to object, and then record the change with rationale
in the gep archive. Same thing you'd do on a mailing list, but commit
it to CVS also.

That is, what we'd want from a GEP here is:

 - getting changes on gep-announce so people don't miss them
 - giving people _some_ time to respond
 - resolving objections _if_ they arise
 - archiving the change and rationale

I don't think we want:

 - to do a heavy outline-all-requirements then design-the-solution 
   process when realistically there's only one patch or solution 
   that's going to be worth considering
 - to _expect_ a lot of discussion on GEPs, many will just be "any
   objections?"
 - to have GEPs that are pretty much content-free as this one is

Thinking about how to improve the process, I think we should be
looking at some of the following:

 - merging requirements/action GEPs, _but_ somehow still encouraging
   people to write down requirements before they start quibbling about
   code. I don't think we want two geps for everything. It's too
   heavy.

 - allow a GEP which is basically "here is the detailed
   proposal/patch, any objections?"

 - allow a GEP to contain links to list archives, to save 
   people rewriting stuff if there are already some good 
   specific writeups in the archives

 - people need to be careful to discuss things a bit _first_, iron out
   some of the obvious stuff, thus making the "any objections?" gep
   more likely to go through fine.

 - discussion also gives you a good way to pick the "responsible
   parties" for the GEP (people who seemed interested in the
   discussion)

 - making it easy to have a long-term GEP that evolves over time,
   e.g. I think the "toolbar" GEP should pretty much remain active
   until we actually finish implementing the widget, and keep getting
   updated to match reality.

The original idea was to have GEP 0 and two or three sample GEPs to
try and figure out what GEPs should be like and how they should work -
we have a lot of GEPs right away here, while the process itself is
still experimental.

Havoc