Re: gep-2, Desktop Theme Sets - process ...

[Michael Meeks <michael ximian com>]

Hi Bill,

	Ah - missed this before replying; bother.

On Fri, 2002-08-30 at 14:59, Bill Haneman wrote:
> Yes, I expect to be something of a guinea pig here. 

	Great; you're doing good.

> On the other hand I am very concerned about going the long way around on
> something which is really not that enormous a project and which is
> needed sooner rather than later.

	Well - make the approval time for the requirements short, and the time
for the maintainers to decide on a solution long; it's fine. The process
of separating requirements from implementation is a really, really vital
part of good design. Even if both are happening in parallel.

> I have no problem making this a 'requirements' gep, provided such geps
> can also cover the proposed implementation/solution path.  Using two
> separate geps for this seems like excess process to me.

	We don't use 2 geps; we archive the discussion on the solution on the
mailing lists pointed to by the GEP - we codify the requirements in the
GEP itself, along with the eventual end-result of the decision making
process after the GEP is approved.

> I do hope that this doesn't turn into fuel for fears of process
> stultifying GNOME :-/

	Hopefully not; there's no need for the process to be slow, but it's
best to have it rigorous.

> Sigh.  I agree with your suggestions below but hate to just remove stuff
> after having put it into the document.  Restructuring and editing the
> doc is another matter, I expect to do plenty of that.

	Yes; sure - but ruthlessly killing your children is good discipline.
Ultimately, the discussion is intended to happen on the mailing list,
and that of it that pertains to requirements is to be written up in the
GEP. Discussion as to precise GUI layout etc. is different and shouldn't
appear there, but on the list / in the hacking on a solution to fit the
requirements.

	Ultimately the requirements / action split saves people time and allows
a clear headed evaluation of what we want in the abstract and then the
concrete - instead of crippling an excelent idea - by discarding a
combined proposal on the grounds of various minor controversial
implementation details.

> That sounds like a good starting point, thanks.  I see that gep-3  has a
> "Requirements" section in 2.1; I can follow that format.

	Great.

> > <p>Here the responsible maintainers write rationale for
> > approving/rejecting the proposal and respond to each issue raised.
> > </p>
> 
> Sounded like an ongoing process section to me; that's how I interpreted
> it.  Since discussion was well under way when I started the gep I tried
> to capture a little of it.

	Ah - well; this is for the responsible maintainers to write up after
the GEP is approved / discarded.

> Do you suggest that the discussion occur entirely outside of the gep
> itself?  That's OK but it seems nonconducive to capturing the
> discussion; nobody likes writing up docs after things have been decided

	Well - that's the duty of the maintainers in part; the discussion is to
be about the requirements - which of these are controversial etc. ?
beyond the security issue I just pointed out eg. ;-)

> > 	Lastly - I think it's best to limit the list of responsible maintainers
> > to people that are existing maintainers of core Gnome modules, since
> > this will be a new module to add into the core; and those are the people
> > who have to deal with the result in perpetuity.
> 
> Hmm, I don't see that in gep-0, what I see is a requirement that 3 of
> the listed people meet that or a similar criterion.  (cf paragraph 2 of
> 2.3.2 in gep-0).  The other people whom I included are either impacted
> in other ways or volunteers who have expressed interest/willingness to
> work on implementation; I certainly think such persons should be
> included in the list :-)

	Ah; I believe that's possibly an unduly lax requirement; one that
should be discussed, but fair enough.

	Thanks again for the work putting this into order,

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot