Dams,

I have a few comments. I've added a few words to your
writeup - they are marked with _underscores_

On 10/29/03 09:44:24, dams@... wrote:
> 
> 
> I agree with GLEP integration. What about :
> 
> 
> 
> * Exploration phase  -  GOAL : describe and decide
> - throw a description here, verify validity
> - preliminary discussion here and/or irc
> - Optional : Prepare a prototype, testcase or a little code snippet    
> to let everybody play.
> *** we put it here, it should be done only if usefull, and should
> not take time. A lot of problems won't be compatible with prototypes  
> ***
> - APPROVAL 1 : does it worth it to handle it (see below). The result
> should be written to the mailing list and on the xml project page if  
> we decide to handle the case.

I definitely think the devs who are responsible or directly involved
in whatever problem we're trying to tackle should be consulted during
this phase. They may provide valuable insight on how *NOT* to address
the problem, thereby perhaps shaving off unnecessary discussions.

> 
> * _Draft_ phase [strict deadline]  -  GOAL : have a GLEP _draft_
> - add new tasks : at least some time to research further (with a
>   milestone), and some time to find a solution (with milestone).
> - one of the tak should be GLEP writing. Possibly one people should
> take care that the _draft_ is conforming to GLEP standard
> - assign people to the task, set up deadlines
> - all this should be well written in the xml project pages, and  
> should end with a new and shiny GLEP _draft_
> - APPROVAL 2 (see below)
> 
> xml project pages precisions : their main goal is to organize the
> work, and archive what's been done. They should be the canva to the  
> GLEP and development production.
> 
> GLEP precision : should contain contain the key parts of the
> discussions of the discussion phase, problem identification (what is  
> the problem), problem acceptation (is this really a problem),
> problem exploration (what are the causes and possible solutions to  
> the problem) , proposed solution and the merrits of this particular  
> solution. The latter of course from later discussions.
> 
> Decisions
> ---------
> We'll try to work together in a friendly manner, so no use to be
> strict for every points. Nevertheless, rules are still usefull for  
> extreme situations.
> 
> APPROVAL 1 : at the end of the Revision phase, we should try to come
> to an agreement that we should handle the case.
> 
> APPROVAL 2 : I think it'd good to warn people outside of
> -desktop-research at this point, like leaders and other devs. They  
> should decide if they approve the GLEP. Maybe we should warn/inform  
> them before the GLEP

To quote the GLEP draft itself:

"GLEP authors are responsible for collecting community feedback on a  
GLEP before submitting it for review. A GLEP that has not been  
discussed on gentoo-dev@g.o and/or the Gentoo Linux forums [7]  
will not be accepted. However, wherever possible, long open-ended  
discussions on public mailing lists should be avoided. Strategies to  
keep the discussions efficient include setting up a specific forums  
thread for the topic, having the GLEP author accept private comments in  
the early design phases, etc. GLEP authors should use their discretion  
here."

Hence, the above point that we should probably try to pull in the dev  
responsible of whatever it is we're trying to address in a GLEP, before  
moving to APPROVAL 1.

Also, APPROVAL 2 is only *OUR* approval of the GLEP draft. The official  
GLEP approval is actually a third and separate approval and thus  
strictly speaking, is no longer in our hands alone. The GLEP will only  
be supported if we have included a wider audience in typing up the  
draft during PHASE2 and before APPROVAL 2.

Good job!

/Rune (ermo)

--
gentoo-desktop-research@g.o mailing list