1 |
Would anyone be interested in improving the GLEP process? |
2 |
Some thoughts: |
3 |
|
4 |
A GLEP should have three parts |
5 |
|
6 |
1. A case for the problem. |
7 |
This document will discuss the problem. |
8 |
* Is there a problem? |
9 |
* What is the nature of the problem? |
10 |
* Who is affected by the problem? |
11 |
* Should the problem be solved? |
12 |
|
13 |
2. Solution requirement analysis. |
14 |
This document will declare the requirements that a proposed solution |
15 |
will be tested against. |
16 |
|
17 |
3. Solution |
18 |
A document describing the solution. |
19 |
|
20 |
Each document should be accepted before the next part is worked on. A |
21 |
document MUST have a version history. A solution(3) MUST link to a |
22 |
particular version of the SRA(2) which MUST link to a particular version |
23 |
of problem(1). |
24 |
|
25 |
I also suggest a wiki-like development model for documents. |
26 |
|
27 |
-John |
28 |
|
29 |
On Mon, 2004-05-03 at 18:36, Stuart Herbert wrote: |
30 |
> On Monday 03 May 2004 16:15, Nathaniel McCallum wrote: |
31 |
> > However, its just a Proposal. And if devs get this |
32 |
> > much negative "your idea can't work" criticism from a simple GLEP, how |
33 |
> > do you think a Gentoo user would ever feel comfortable filing a GLEP |
34 |
> > (which is what they were intended for!). |
35 |
> |
36 |
> I think any submitted proposal needs to be able to stand up to rigorous |
37 |
> technical scrutiny. If the idea has merit, or a groundswell of support, then |
38 |
> the proposal will be the better for it. If the idea is weak, flawed, or |
39 |
> substantially incomplete - it's important we catch these things now before |
40 |
> it's our users catching the results ;-) |
41 |
> |
42 |
> A commonly-taught method of evaluating any proposal is de Bono's hats - where |
43 |
> you look at a proposal from a specific viewpoint. Look it up, and you'll see |
44 |
> where I'm coming from. |
45 |
> |
46 |
> > In the same way as not bashing a user for contributing an ebuild |
47 |
> > (remember, they could be a future contributer to Gentoo), we should, |
48 |
> > when faced with a GLEP, stop and think if there is anything posative |
49 |
> > about it, then try to come up with working scenarios. Remember, devs |
50 |
> > are contributers to Gentoo. |
51 |
> |
52 |
> Yes they are. And you're right - anyone should be able to put forward a GLEP |
53 |
> without fear. |
54 |
> |
55 |
> > Thats also fine with me. I don't want the GLEP approved right away, I |
56 |
> > just wanted it to be a sounding board for discussion to develop a good |
57 |
> > prototype. Isn't that what a GLEP is for? |
58 |
> |
59 |
> Maybe it would help if that discussion happened first, and the results were |
60 |
> written up into a GLEP for approval. That's happened in the past, and seems |
61 |
> a successful model to reproduce. |
62 |
> |
63 |
> Best regards, |
64 |
> Stu |