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.
> 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 email@example.com and/or the Gentoo Linux forums 
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
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.
firstname.lastname@example.org mailing list