Gentoo Archives: gentoo-dev

From: "Jorge Manuel B. S. Vicetto" <jmbsvicetto@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Proposing fundamental changes to DevRel
Date: Thu, 17 Jun 2010 00:34:11
In Reply to: [gentoo-dev] Proposing fundamental changes to DevRel by Sebastian Pipping
Hash: SHA1

On 17-06-2010 00:00, Sebastian Pipping wrote:
> Hello! > > > yngwin's devaway message still reads > > "inactive, pending resolution of devrel issue". > > yngwin retired. I woudn't go as far as saying that his case made him > retire but I definitely say that _DevRel failed on his case_. > I believe I had enough insight to be able to say.
Sebastian, not being in the Developer Relations team means you don't have a complete picture about what happened.
> I would like to propose these fundamental changes to DevRel: > > 1) Make the list of subscribers to the devrel alias public > > Idea: If you share private information you have a right > to know with whom you share.
I don't know what gave you the idea that the list of the Developer Relations project members is private. You can check the alias members directly by running "grep devrel /var/mail/master.aliases" on woodpecker and you can check the project members at
> 2) Clearly split DevRel into groups for recruiting and conflict > resolution with distinct aliases.
There are subgroups in the DevRel team, including recruiters and undertakers, and there are specific aliases for those - recruiters and retirement. The conflict resolution is handled through the devrel alias as the Ombudsman project was dissolved 1 or 2 years ago. You can check the membership to the subgroups in the DevRel page.
> 3) Let Gentoo developers vote on who's in the conflict resolution > team just like we do with the council.
AFAIK this never happened before and in my opinion choosing conflict resolution members by "popularity" is a very bad idea.
> 4) Disallow membership with both the conflict resolution group > and the council at the same time (as the council is where issues > with devrel are taken to).
The reason the elections page clearly identifies members of devrel is to alert developers to possible conflicts. To clarify your above statement, I read it as being about the fact that disciplinary actions of DevRel can be appealed to the Council. If it were meant globally, I'd have to note that whenever you cannot reach an agreement with any project or their lead, you'll have to "appeal" to the council.
> Idea: From insight on cases of DevRel versus members of RevRel > I can tell this dossn't work well. I suppose that > Council against Council-DevRel doesn't work better. > > Problem: Both betelgeuse and jmbsvicetto are DevRel members > nominated for the upcoming council election. > As I am also nominated proposing such rule could be > understood aiming at decreasing their chances on the > council and increasing mine as a result. However, as I > propose to start over with a developer voted conflict > resolution team this is not the case. The only > implication is that if they make it to the council > they cannot be elected for the conflict resolution team.
My response to your email has nothing to do with the above and to make it crystal clear, this is my personal opinion and doesn't represent the global view of the DevRel team or any other team I am a member of.
> DevRel is one of the most important things in Gentoo - we dependend on > that working well. If you care about this please make yourself heard. > > Thanks, > > > > Sebastian
- -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - iQIcBAEBAgAGBQJMGW1pAAoJEC8ZTXQF1qEP4bAQAL1da+zyT//dvMdmv4cxaTth DzU5R0/NYOFnqlRKSUuRoSu63mPyL9XshAUZsdzY71qhYYtCzdhbqbIDNV84C5fm vdOTmV0dQyEbqvV0jI6rrsevyvuQ0g40IjuMFH8kkXmpD982OFAb22l3BZWE5Evh sk+LYnRWuzXLsptsJj2gumvsf7MrjdpwYmU65W6kJutKYovB9otrqwea75yGObnA /21TmNOm8UAYIFHndxu7iC93yy2obMxbPy/XLuKAavsr5kU/kyJGIsRq8oWnrBwN pX2lmyDIPdSM41k+HZtM0Rs4kCYW1WgMT8Ntq6I4dvHdL1WlHiIGrDWal1hGhHhM smh1Exrjk8FJ4hjjD6O99VSa1JY7AVurGbPHOOaQxAIhb/tKqrdaQxG9bypTQhqD uV2QmeSilv0cSxyTtUxmISIb3z2+Xez+lD/ZPmmPnmhaEhieudR7X/K3lXQVk1GF lBY11QjNmJ4zubIyty2edHDuxT0wvNFdDNH9gv6nxmPEZmjn6ApNfB3/lu+QWkQM 4WHINu+eXGyAzkLKxcpOgNOFw5IJyHsz3OBhs8y7YXSWNbZrIrkbnW7zrx0hkGOV kv1L25u6rVCdvLZvRvYMRnhh+AkxLdIfqDcc7H5cQDvRveWVLM5yRf2071XiZjWE c5S8QMNGCcAVo/60fL5S =1QFB -----END PGP SIGNATURE-----