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



Michael said:

> Hi Bill,
> 
> On Thu, 2002-08-29 at 19:00, Bill Haneman wrote:
> > gep-2, a proposal for "Desktop Theme Set" support, is now in GNOME cvs. 
> 
> 	It's really great that you're using the GEP for this change; but I
> think there are a few technicalities that it's really well worth getting
> right in the first few of these - such that other people don't get
> confused later.

Yes, I expect to be something of a guinea pig here. 

> 	It seems to me the very best tenets of design revolve around first
> accumulating design requirements, then evaluating solutions, [ then
> writing a spec ].
> 
> 	It strikes me that an 'Action' GEP is inappropriate for this change;
> whereas it might be appropriate for say "Switch CVS to sourceforge" or
> some ancient chestnut ;-)

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.

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.

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

> 	Indeed - I'm fairly firmly convinced that gep-2 is far, far too
> concrete I'd like to see it dramatically updated; removing the vast
> substance of implementation detail, esp. 'proposed screenshots' - and
> substitute harder requirements such as:

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.
 
> 	* must theme at least [5 vital things for a11y]
> 	* (optional) configures [ mozilla ... ]
> 	* must conform to HIG guide on instant apply
> 	* themes must be installable from local and remote sources

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.

> 
> 	And so on - thus we can dispasionately describe what we wish - and give
> yardsticks as to how to evaluate solutions. As such I think it's
> reasonable to have a short period to evaluate the requirements, and then
> get on to the arguing about which button goes where later ;-)
> 
> 	It also concerns me that section 4 is populated; this is tagged:
> 
> <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.
 
> 	I believe this is intended to be done by all the responsible
> maintainers, and that after their discussion / decision.

OK, that was not at all clear.  Where does one put the rationale then,
in the meantime?  Certainly one shouldn't just come up with rationales
"after the fact", the discussion period is when they are most needed. 
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
;-)
 
> 	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 :-)

> > If you have been placed in the interested/guilty parties list for this
> > GEP, that's because I or someone else thinks you either are interested
> > or were in the past... if you wish to be removed please email me.
> 
> 	Of course - it's intended the discussion be public, so all interested
> parties can be heard.
> 
> 	Sorry if any of that was unclear; I'll update the templates.

regards,

Bill
 
> 	Regards,
> 
> 		Michael.
> 
> -- 
>  mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]