[gentoo-dev] [GLEP] Improvements to the GLEP workflow

[gentoo-dev] [GLEP] Improvements to the GLEP workflow

[Mark Bateman]

ABSTRACT
  This GLEP details a possible enhancement to the GLEP process to aid the Gentoo
council in voting on GLEPs as well Gentoo developers in the creation of GLEPs.


MOTIVATION
  Whenever a developer or user wants to request a significant enhancement to 
Gentoo the GLEP process can be used to capture the request. Unfortunately 
all the council can do with GLEPs are either

1) Vote to accept the GLEP 
2) Vote to reject the GLEP
3) Defer voting on the GLEP 

  For the majority of GLEPs this process is adequate. This process however 
becomes a hindrance if a GLEP is submitted that is either incomplete, fairly 
complex or a general consensus on the best way forward isn't reached. 

  What ends up happening with GLEPs like this is they linger around being 
tweaked and repeatedly discussed, so much so that eventually nothing new is 
being discussed and no further constructive discussions occur. 


SPECIFICATION
  Rather then having a process of: GLEP editing -> Council voting -> back to 
editing until a YES/NO vote. If the GLEP is determined to not describe the 
problem/enhancement/solution enough it should be suspended and a more 
structured work flow utilised.

1) Capture specification of problem or enhancement. 
  The GLEP shall be re-written such that it ONLY details the problems being 
faced or details the requested enhancement. Actual details are required, 
"how foo is presently done" is useless in a years time if someone needs to 
examine an old GLEP.
  
  Details on possible solutions or implementations are not to be included 
in this section.


2) Specification Approval
  Once the actual scope of the problem has been defined the council can vote on 
freezing the scope of the GLEP. 


3) Submission of concepts.
  With the actual scope of the problem detailed and frozen, developers can 
discuss what concepts should be added to the GLEP. One or more concepts shall 
be added to the GLEP with enough detail to show how each falls within the scope
of the GLEP. Likewise criticisms of each concept shall be added to provide its 
pros and cons (if more then one solution is to be submitted). Any required 
modification to the scope needs to be approved by the council.


4) Concept Design Review
  Once each concept has been detailed enough, the council can then vote to 
either accept one of the suggested concepts or reject the GLEP. Details of 
council decision (ie which concept excepted, if any) to be recorded in the GLEP

5) Detailed Design Review.
  An optional step can be utilised to capture the implementation. A final 
signoff by individuals actually implementing the concept to confirm the scope 
of the GLEP has been met.


How is this beneficial?
  By having actual stages to the GLEP process, stages that do not get polluted 
by discussion/details belonging in a subsequent stage, the content of each stage 
can be clearly defined so all parties are aware of what is being discussed. 
  
  This also provides the additional benefit of traceability, so that as old 
developers leave and new developers arrive, the GLEP is a complete package 
detailing the problems, the solutions as well as the justification. This removes
the reliance on distilling mailing list posts or irc logs after the fact. 

  Likewise it provides a mechanism for individuals to submit a GLEP who may not
be fully aware of the best method to implement such an enhancement. Others can 
then propose concepts that meet this proposal (if such an enhancement is valid).

The actual structure of the GLEP template remains largely the same, additions 
headings would need to be added after the SPECIFICATION heading to provide
documentation for the different stages.

SPECIFICATION: full breakdown of the problem

COUNCIL COMMENTS ON SPECIFICATION: Capture council’s verdict on GLEP 
preliminary details capturing any additional information on what the council 
would like to see in concepts or if it should be rejected

CONCEPT DESIGNS: Each concept to have its own subheading capturing details of 
how it plans to solve what has been detailed in the SCOPE of the GLEP

    CONCEPT_1:
        DETAILS:
        CRITIQUE:
    CONCEPT_2:
        DETAILS:
        CRITIQUE:

COUNCIL COMMENTS ON CONCEPT: Result of council vote on what the council have 
chosen, if the council requires additional metrics if there is no clear 
advantage between different concepts, or if GLEP is rejected.

(Optional) DETAILED DESIGN SIGNOFF: A final closing point to the GLEP to capture
who fulfilled what and where with respect to the SCOPE
    Requirement #1 from the SCOPE implement by foo in bar

RATIONALE: ...

Re: [gentoo-dev] [GLEP] Improvements to the GLEP workflow

[Roy Bamford]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.06.09 22:49, Mark Bateman wrote:
> ABSTRACT
>   This GLEP details a possible enhancement to the GLEP process to aid
> the Gentoo
> council in voting on GLEPs as well Gentoo developers in the creation
> of GLEPs.
> 
>
[snip]

Mark,

Sounds good to me. There are signs the council is already moving 
this way. e.g. the feature freeze on EAPI 3 and the acknowledgement of 
the problem described by GLEP55 are two examples of the stepwise 
approach to problem solving. 

- -- 
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAkowFFYACgkQTE4/y7nJvau84gCdFOLQgnOc6SyBn631cecGHqeC
YdMAn0VWPtk0JFFW87CpVw7nAr9mo7vn
=lztM
-----END PGP SIGNATURE-----