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
In Reply to: [gentoo-project] Council appointed leaders for QA and DevRel by Markos Chandras
Hash: SHA1

On 14-08-2011 11:06, Markos Chandras wrote:
> Some time ago, few people proposed to have Council appointed leaders > for QA and DevRel. I like the idea because this way the Council can > ensure that the team is active or either force some activity in case > the current leader slacks big time. Furthermore, right now there is > the potential problem for the leader to only allow new members that > he likes so they can vote for him on next elections. Membership and > voting actions should not be related in these teams. The leader will > still have control over the new members but Council will do the > voting ( community will provide feedback ofc )
As I've expressed already a few times before, I strongly object to this idea. My reasons are the following: * I like and agree with the way GLEP39 keeps projects separate from the council and how it allows for open, competing and independent projects. * As such, I disagree with the idea the council may nominate leads for whatever projects - this doesn't apply to council sponsored teams created to deal with specific issues (a GLEP39 reform team would be an example). * I know it's controversial, but I don't think all Gentoo teams and projects were born "equal". I have the same respect for all, but some teams should not have open membership as they require a certain level of "trust" and or "authority". Getting ops on an IRC channel, getting root on our infra, having access to sensitive information through our security alias, dealing with personnel issues, working on a particular team's ebuilds and or having oversight through QA, as a few examples, do not all require the same level of "trust" nor do they convey the same level of "authority". * The list of teams in the above point, their relation to council and what type of oversight and or intervention the council may have should in my view be part of the discussion about GLEP39 reform. * To have strong and independent teams, they should be responsible to choose their leads. In the GLEP39 reform debate, I think we should allow a system of checks and balances that should allow the council to intervene when a team / project fails or disintegrates, but it should not grant it "carte blanche". * Both DevRel and QA teams, as some others, should not become "popularity" teams. Their role may and can frequently lead to some conflicts, but they should act in the best interest of Gentoo and not on what is the "popular opinion" of the moment. Lastly, I'm worried to see this debate "fueled" by particular incidents and the opinion of some people about the current "state" of some teams, when this should be a debate about ideas and "theoretical models". I also object to some of the qualifications about the state of DevRel or QA and don't think they convey a "fair" image of how both teams and individual members act or have acted in the past. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - iQIcBAEBAgAGBQJOTHZaAAoJEC8ZTXQF1qEPxLgP/0GM5qah3mpuMDZxqBzOP0c4 poTSZhCiwlrCynwkcnCaEuP7x4mRgWKtObwF4tuITD4ok/ssJRijjQ0QGLZnQIDL Vo7XCN401oAYwje+HGDNLnJRGB1Yyv0fc1aNFS5IuyvJpUoiWyyAwcyveXYK9rrx +MCeXrzXKYzrH/AX6ZJu7d3b2kDWERKKOW+LWXmbKjSYBUm+HjCS4PRFc0n8APVz WT22fhm+bSOFJN6QVLumrrdOR7mrbo6QGjzyBzN6XblqkMhpFprrg5WDAOJSpGTz Aki2QAV8mGF+DmVIRHbdUNwwgwKs+r4btHigwkNDaGqn8/o2Qkhen9KI034gg9R+ EN0jpc7A36T3KrSlIJIsQYBS5Yt/SHbVSbjjRJ1qE0Y7MXPZHNyCtbA0tj3NXI1j XGpogf/VXY1SGapMJ3siQ3QH8e/xaamgV0E+d3QvooFK8Q4YCRMr4qxTNAT/iaS7 S9odwyILcIM9bvY5oSdvvTuLMgJkMvta1KWmiyxYykw+7P69suOzD/2JbTCT1QYP qgwo2d2FltkjKeHSx7CRI16MruOmWXu0E8sXFvLzzoeiFQyoxyJJZZE/ducUNf8q 5mIB+E22WtIkdhMMAUAs5kZzw/RvshBA4HukmR+8dF7p/NNIw50gW9s7XCSNIG2o M4cs+r9YwbPyWSPkehZb =BwQv -----END PGP SIGNATURE-----