Rune Morling <gentoo@...> said:
> 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.
that's right. We should add something here. I'll add : - talk with the devs
that are the most concern with the issue, get additional infos, ask if there is
a good reason not to handle it, inform them that plan to address a GLEP
>> * _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 firstname.lastname@example.org 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.
ok I add this too.
email@example.com mailing list