Gentoo Archives: gentoo-project

From: "Jorge Manuel B. S. Vicetto" <jmbsvicetto@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Council appointed leaders for QA and DevRel
Date: Thu, 18 Aug 2011 02:18:53
Message-Id: 4E4C765A.5060409@gentoo.org
In Reply to: [gentoo-project] Council appointed leaders for QA and DevRel by Markos Chandras
1 -----BEGIN PGP SIGNED MESSAGE-----
2 Hash: SHA1
3
4 On 14-08-2011 11:06, Markos Chandras wrote:
5 > Some time ago, few people proposed to have Council appointed leaders
6 > for QA and DevRel. I like the idea because this way the Council can
7 > ensure that the team is active or either force some activity in case
8 > the current leader slacks big time. Furthermore, right now there is
9 > the potential problem for the leader to only allow new members that
10 > he likes so they can vote for him on next elections. Membership and
11 > voting actions should not be related in these teams. The leader will
12 > still have control over the new members but Council will do the
13 > voting ( community will provide feedback ofc )
14
15 As I've expressed already a few times before, I strongly object to this
16 idea. My reasons are the following:
17
18 * I like and agree with the way GLEP39 keeps projects separate from the
19 council and how it allows for open, competing and independent projects.
20 * As such, I disagree with the idea the council may nominate leads for
21 whatever projects - this doesn't apply to council sponsored teams
22 created to deal with specific issues (a GLEP39 reform team would be an
23 example).
24 * I know it's controversial, but I don't think all Gentoo teams and
25 projects were born "equal". I have the same respect for all, but some
26 teams should not have open membership as they require a certain level of
27 "trust" and or "authority". Getting ops on an IRC channel, getting root
28 on our infra, having access to sensitive information through our
29 security alias, dealing with personnel issues, working on a particular
30 team's ebuilds and or having oversight through QA, as a few examples,
31 do not all require the same level of "trust" nor do they convey the same
32 level of "authority".
33 * The list of teams in the above point, their relation to council and
34 what type of oversight and or intervention the council may have should
35 in my view be part of the discussion about GLEP39 reform.
36 * To have strong and independent teams, they should be responsible to
37 choose their leads. In the GLEP39 reform debate, I think we should allow
38 a system of checks and balances that should allow the council to
39 intervene when a team / project fails or disintegrates, but it should
40 not grant it "carte blanche".
41 * Both DevRel and QA teams, as some others, should not become
42 "popularity" teams. Their role may and can frequently lead to some
43 conflicts, but they should act in the best interest of Gentoo and not on
44 what is the "popular opinion" of the moment.
45
46 Lastly, I'm worried to see this debate "fueled" by particular incidents
47 and the opinion of some people about the current "state" of some teams,
48 when this should be a debate about ideas and "theoretical models".
49 I also object to some of the qualifications about the state of DevRel or
50 QA and don't think they convey a "fair" image of how both teams and
51 individual members act or have acted in the past.
52
53 - --
54 Regards,
55
56 Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
57 Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
58 -----BEGIN PGP SIGNATURE-----
59 Version: GnuPG v2.0.18 (GNU/Linux)
60 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
61
62 iQIcBAEBAgAGBQJOTHZaAAoJEC8ZTXQF1qEPxLgP/0GM5qah3mpuMDZxqBzOP0c4
63 poTSZhCiwlrCynwkcnCaEuP7x4mRgWKtObwF4tuITD4ok/ssJRijjQ0QGLZnQIDL
64 Vo7XCN401oAYwje+HGDNLnJRGB1Yyv0fc1aNFS5IuyvJpUoiWyyAwcyveXYK9rrx
65 +MCeXrzXKYzrH/AX6ZJu7d3b2kDWERKKOW+LWXmbKjSYBUm+HjCS4PRFc0n8APVz
66 WT22fhm+bSOFJN6QVLumrrdOR7mrbo6QGjzyBzN6XblqkMhpFprrg5WDAOJSpGTz
67 Aki2QAV8mGF+DmVIRHbdUNwwgwKs+r4btHigwkNDaGqn8/o2Qkhen9KI034gg9R+
68 EN0jpc7A36T3KrSlIJIsQYBS5Yt/SHbVSbjjRJ1qE0Y7MXPZHNyCtbA0tj3NXI1j
69 XGpogf/VXY1SGapMJ3siQ3QH8e/xaamgV0E+d3QvooFK8Q4YCRMr4qxTNAT/iaS7
70 S9odwyILcIM9bvY5oSdvvTuLMgJkMvta1KWmiyxYykw+7P69suOzD/2JbTCT1QYP
71 qgwo2d2FltkjKeHSx7CRI16MruOmWXu0E8sXFvLzzoeiFQyoxyJJZZE/ducUNf8q
72 5mIB+E22WtIkdhMMAUAs5kZzw/RvshBA4HukmR+8dF7p/NNIw50gW9s7XCSNIG2o
73 M4cs+r9YwbPyWSPkehZb
74 =BwQv
75 -----END PGP SIGNATURE-----