1 |
I would like to propose some changes to GLEP-48 as discussed in the |
2 |
most recent Council meeting. |
3 |
|
4 |
I proposed 3 different revisions with increasing degrees of change. |
5 |
These would be on the agenda for the December meeting (not the one |
6 |
next week). |
7 |
|
8 |
Before I justify my changes, I want to first say that none of this is |
9 |
intended to cast blame/etc on any individual or team (members of QA, |
10 |
QA leads, previous councils, etc). I just think that the current |
11 |
state has some dysfunctions and I think that they are structural in |
12 |
origin and thus prone to come up regardless of who holds the various |
13 |
posts. |
14 |
|
15 |
Also, I'm VERY interested in feedback or outright disagreement with |
16 |
anything I say here, whether from the community or especially from |
17 |
those who have been associated with QA up until now. I'm happy to |
18 |
accept it in public forums (preferred) or in private, and anything |
19 |
said in private will be held in confidence. |
20 |
|
21 |
Here is my personal sense of the problems I've seen: |
22 |
1. Complaints that QA is overbearing by devs in general. |
23 |
2. Complaints that QA is ignored. |
24 |
3. Complaints that QA has not been backed up by the Council, being |
25 |
reversed on appeal excessively. |
26 |
4. Complaints that QA is too closed. |
27 |
|
28 |
I think the root cause of this is that the QA team does not really |
29 |
have a "mandate." It was constituted in the distant past, and |
30 |
membership has been passed down over the years. There is nothing that |
31 |
guarantees that QA is aligned with the direction the larger community |
32 |
wants to move in. I'll say that again - there is nothing that |
33 |
GUARANTEES that QA is aligned by the nature of the process by which QA |
34 |
is constituted - I'm not saying that the individuals involved haven't |
35 |
made a good effort to do what they felt was best for the community. |
36 |
|
37 |
I think the solution is therefore to give QA a mandate. The council |
38 |
has a mandate because it is elected by the developer community and is |
39 |
accountable to them annually. As such the council can confirm the |
40 |
lead of QA and confer their mandate upon them. In doing so the |
41 |
council and QA will be structurally aligned, and the council can be |
42 |
held accountable for failing to properly support the lead that they |
43 |
themselves confirmed. That said, the team should be self-governing to |
44 |
the greatest extent possible so the team will be given the opportunity |
45 |
of recommending a lead to the council. |
46 |
|
47 |
I have three drafts. |
48 |
|
49 |
1 - merely adds wording to the selection of the lead to indicate that |
50 |
the lead is confirmed by the council - I wanted to have this option as |
51 |
it came up as a suggestion during the last meeting. |
52 |
|
53 |
2 - additionally gives the council the power to appoint an interim |
54 |
lead until a permanent one is selected. This makes the council |
55 |
responsible/accountable for the operations of QA until they can work |
56 |
things out with the team, or if the team becomes inactive/etc. |
57 |
|
58 |
3 - Adds some explanation and minor corrections to the document. The |
59 |
corrections should probably be considered no matter what version is |
60 |
chosen (a typo, s/Devrel/Comrel). |
61 |
|
62 |
A final thought: |
63 |
Some discussion came up in the council meeting regarding activities |
64 |
like running the tinderbox, filing bugs, etc. I think the |
65 |
policy/enforcement side of QA needs to have a mandate as it exercises |
66 |
power over all developers. However, the more "informational/advisory" |
67 |
side of QA does not need one. I see things like running a tinderbox |
68 |
as being a more traditional Gentoo project which does not need so much |
69 |
oversight - it might be a QA subproject but I think anybody who wants |
70 |
to provide helpful information to developers should be encouraged to |
71 |
do so. Any bugs they log would only have authority insofar as they |
72 |
align with the policy/enforcement side of QA (however, even when not |
73 |
required by policy developers are always encouraged to do what they |
74 |
can to fix bugs). |
75 |
|
76 |
Rich |