Re: [gentoo-dev] Proposing fundamental changes to DevRel

["Jorge Manuel B. S. Vicetto" <jmbsvicetto@gentoo.org>]

-----BEGIN PGP SIGNED MESSAGE-----
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 http://www.gentoo.org/proj/en/devrel/

>  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 - http://enigmail.mozdev.org/

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-----