1 |
ABSTRACT |
2 |
This GLEP details a possible enhancement to the GLEP process to aid the Gentoo |
3 |
council in voting on GLEPs as well Gentoo developers in the creation of GLEPs. |
4 |
|
5 |
|
6 |
MOTIVATION |
7 |
Whenever a developer or user wants to request a significant enhancement to |
8 |
Gentoo the GLEP process can be used to capture the request. Unfortunately |
9 |
all the council can do with GLEPs are either |
10 |
|
11 |
1) Vote to accept the GLEP |
12 |
2) Vote to reject the GLEP |
13 |
3) Defer voting on the GLEP |
14 |
|
15 |
For the majority of GLEPs this process is adequate. This process however |
16 |
becomes a hindrance if a GLEP is submitted that is either incomplete, fairly |
17 |
complex or a general consensus on the best way forward isn't reached. |
18 |
|
19 |
What ends up happening with GLEPs like this is they linger around being |
20 |
tweaked and repeatedly discussed, so much so that eventually nothing new is |
21 |
being discussed and no further constructive discussions occur. |
22 |
|
23 |
|
24 |
SPECIFICATION |
25 |
Rather then having a process of: GLEP editing -> Council voting -> back to |
26 |
editing until a YES/NO vote. If the GLEP is determined to not describe the |
27 |
problem/enhancement/solution enough it should be suspended and a more |
28 |
structured work flow utilised. |
29 |
|
30 |
1) Capture specification of problem or enhancement. |
31 |
The GLEP shall be re-written such that it ONLY details the problems being |
32 |
faced or details the requested enhancement. Actual details are required, |
33 |
"how foo is presently done" is useless in a years time if someone needs to |
34 |
examine an old GLEP. |
35 |
|
36 |
Details on possible solutions or implementations are not to be included |
37 |
in this section. |
38 |
|
39 |
|
40 |
2) Specification Approval |
41 |
Once the actual scope of the problem has been defined the council can vote on |
42 |
freezing the scope of the GLEP. |
43 |
|
44 |
|
45 |
3) Submission of concepts. |
46 |
With the actual scope of the problem detailed and frozen, developers can |
47 |
discuss what concepts should be added to the GLEP. One or more concepts shall |
48 |
be added to the GLEP with enough detail to show how each falls within the scope |
49 |
of the GLEP. Likewise criticisms of each concept shall be added to provide its |
50 |
pros and cons (if more then one solution is to be submitted). Any required |
51 |
modification to the scope needs to be approved by the council. |
52 |
|
53 |
|
54 |
4) Concept Design Review |
55 |
Once each concept has been detailed enough, the council can then vote to |
56 |
either accept one of the suggested concepts or reject the GLEP. Details of |
57 |
council decision (ie which concept excepted, if any) to be recorded in the GLEP |
58 |
|
59 |
5) Detailed Design Review. |
60 |
An optional step can be utilised to capture the implementation. A final |
61 |
signoff by individuals actually implementing the concept to confirm the scope |
62 |
of the GLEP has been met. |
63 |
|
64 |
|
65 |
How is this beneficial? |
66 |
By having actual stages to the GLEP process, stages that do not get polluted |
67 |
by discussion/details belonging in a subsequent stage, the content of each stage |
68 |
can be clearly defined so all parties are aware of what is being discussed. |
69 |
|
70 |
This also provides the additional benefit of traceability, so that as old |
71 |
developers leave and new developers arrive, the GLEP is a complete package |
72 |
detailing the problems, the solutions as well as the justification. This removes |
73 |
the reliance on distilling mailing list posts or irc logs after the fact. |
74 |
|
75 |
Likewise it provides a mechanism for individuals to submit a GLEP who may not |
76 |
be fully aware of the best method to implement such an enhancement. Others can |
77 |
then propose concepts that meet this proposal (if such an enhancement is valid). |
78 |
|
79 |
The actual structure of the GLEP template remains largely the same, additions |
80 |
headings would need to be added after the SPECIFICATION heading to provide |
81 |
documentation for the different stages. |
82 |
|
83 |
SPECIFICATION: full breakdown of the problem |
84 |
|
85 |
COUNCIL COMMENTS ON SPECIFICATION: Capture council’s verdict on GLEP |
86 |
preliminary details capturing any additional information on what the council |
87 |
would like to see in concepts or if it should be rejected |
88 |
|
89 |
CONCEPT DESIGNS: Each concept to have its own subheading capturing details of |
90 |
how it plans to solve what has been detailed in the SCOPE of the GLEP |
91 |
|
92 |
CONCEPT_1: |
93 |
DETAILS: |
94 |
CRITIQUE: |
95 |
CONCEPT_2: |
96 |
DETAILS: |
97 |
CRITIQUE: |
98 |
|
99 |
COUNCIL COMMENTS ON CONCEPT: Result of council vote on what the council have |
100 |
chosen, if the council requires additional metrics if there is no clear |
101 |
advantage between different concepts, or if GLEP is rejected. |
102 |
|
103 |
(Optional) DETAILED DESIGN SIGNOFF: A final closing point to the GLEP to capture |
104 |
who fulfilled what and where with respect to the SCOPE |
105 |
Requirement #1 from the SCOPE implement by foo in bar |
106 |
|
107 |
RATIONALE: ... |