Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project@l.g.o
Cc: glep@g.o
Subject: [gentoo-project] Proposed Revisions to QA GLEP-48
Date: Wed, 13 Nov 2013 14:47:21
Message-Id: CAGfcS_kX71eiJbtFSJ3UN4tHotvt8iYawHR+rBZPr6avf86vBQ@mail.gmail.com
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

Attachments

File name MIME type
glep-0048.txt text/plain
glep-0048.txt.1 application/octet-stream
glep-0048.txt.1.diff text/plain
glep-0048.txt.2 application/octet-stream
glep-0048.txt.2.diff text/plain
glep-0048.txt.3 application/octet-stream
glep-0048.txt.3.diff text/plain

Replies