From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Re: Proposing fundamental changes to DevRel
Date: Thu, 17 Jun 2010 07:56:46 +0000 (UTC) [thread overview]
Message-ID: <pan.2010.06.17.07.56.46@cox.net> (raw)
In-Reply-To: AANLkTinoLP9VF8QGkkQtNHfZ6VZB7b__Sx3jnz0rAbb0@mail.gmail.com
Mike Frysinger posted on Wed, 16 Jun 2010 20:41:21 -0400 as excerpted:
> On Wed, Jun 16, 2010 at 8:00 PM, Sebastian Pipping wrote:
>> 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).
>
> i have yet to see this being necessary. the one or two times there was
> a conflict of interest, there was a minor discussion ahead of time and
> cleanly resolved.
>
> i.e. it isnt a problem
There's also a practical problem in such a restriction. DevRel is
understaffed. I've seen observations to the effect that most developers
aren't interested in getting involved in that area, particularly in
reference to the conflict resolution subgroup, and by the nature of the
problem, this isn't likely to change.
It's also quite true that those interested in the admin aspects including
conflict resolution are likely to be drawn to both devrel and council.
Based on the above, we're already picking from a limited subset. Do we
/really/ want to restrict it further? /Can/ we restrict it further,
without severe practical effects due to restricting the number of folks
willing to run for either council or devrel, if not both? Will the result
be a drop in the quality of candidates willing to run for either team? If
there's five slots and only six people running, how much of a choice is
there, really? What about if only three accept their nominations? Will
that be the result, particularly if the other suggestions are implemented
as well, and people are elected for devrel-conflictres directly?
In an infinitely large group, with an infinite number of potential
candidates and thus an infinite number willing to run, the idea has
merit. As the group gets smaller, dangers appear. Is the group of Gentoo
devels small enough, and self-selected enough against interest in this
area, that the dangers cancel out or worse the positives? That I don't
know, as I'm not a dev and certainly not on devrel or council, with the
experience to say, but from various comments I've read over the years from
those qualified to know, it's at minimum, a close call.
Would anybody with better insight into these things care to comment?
Perhaps I read into the various comments something that wasn't there, or
maybe those making the comments were ill-informed themselves, or it may be
that the problems are already corrected and it'd be fine now. I don't
know, but I'm worried about it, thus this post.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2010-06-17 7:57 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-17 0:00 [gentoo-dev] Proposing fundamental changes to DevRel Sebastian Pipping
2010-06-17 0:33 ` Jorge Manuel B. S. Vicetto
2010-06-17 1:05 ` Ben de Groot
2010-06-17 14:37 ` Sebastian Pipping
2010-06-17 22:46 ` Sebastian Pipping
2010-06-17 23:36 ` Alec Warner
2010-06-17 23:36 ` Richard Freeman
2010-06-17 0:41 ` Mike Frysinger
2010-06-17 7:56 ` Duncan [this message]
2010-06-17 15:10 ` [gentoo-dev] " Sebastian Pipping
2010-06-17 15:52 ` Petteri Räty
2010-06-18 2:38 ` Duncan
2010-06-17 0:41 ` [gentoo-dev] " Jeremy Olexa
2010-06-17 7:52 ` Petteri Räty
2010-06-17 15:00 ` Sebastian Pipping
2010-06-17 15:45 ` Petteri Räty
2010-06-17 16:20 ` Ben de Groot
2010-06-17 16:33 ` Petteri Räty
2010-06-17 16:21 ` Patrick Lauer
2010-06-17 20:09 ` Sebastian Pipping
2010-06-17 20:39 ` Patrick Lauer
2010-06-17 20:29 ` Sebastian Pipping
2010-06-21 15:44 ` Petteri Räty
2010-06-17 11:16 ` Markos Chandras
2010-06-17 18:28 ` Roy Bamford
2010-06-17 18:47 ` Roy Bamford
2010-06-18 4:06 ` Jeroen Roovers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=pan.2010.06.17.07.56.46@cox.net \
--to=1i5t5.duncan@cox.net \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox