On Sat, 2008-04-19 at 01:15 +0100, Roy Bamford wrote:
> > Perhaps if it were worded more so that it allowed for someone to
> > retain
> > their status only if they vote. That should be close enough to the
> > current way things are without forcing people out.
> I'm a little uncomfortable with that as it would mean identifying votes
> with individuals. Not publicly but that information would have to be
> knowable if membership were tied to voting.
Well, we already track who voted today for Foundation membership.
Remember, all we need to know is if someone voted, not what their vote
*was* per se.
> What about having retired devs apply for membership annually ?
I wouldn't have a problem with it. Perhaps if we sent out something
- Check if Foundation member
- Check if retired in LDAP
- If so, send a reminder email a week or so before nominations start/the
- If the person doesn't vote, they're out
> The idea here being able to keep individual votes secret.
> I certainly don't want to forcibly retire active foundation members.
Agreed. I just see that there are certain people that I am sure would
love to have their voices heard in the Foundation, without devoting so
much time directly to Gentoo development. I bet guys like drobbins and
seemant would love to still have some input, without having to rejoin
the development staff or run as a trustee. After all, if we increase
the member -> trustee communications, which I think you guys have done a
decent job trying to do so far, we could see good changes coming from
the Foundation side.
Here's a good example. I've been to several shows and conferences.
Once of the major things that people seem really interested in Gentoo
for is embedded work. We don't really have a lot of embedded people
within Gentoo. Now, let's say that the Foundation decided that its
membership thinks embedded is somewhere we should focus some resources.
The Foundation could go and purchase some developer hardware, either to
be hosted or to be sent to individuals. They could also recruit
specifically for embedded positions. The new developers would be
accountable to the Council and general Gentoo policy, but the person
could, if desired, bypass some of the normal "Gentoo developer"
recruitment. Let's say the person was going to be a coder, and not do
anything with ebuilds. The Foundation could even have its own
repositories, allowing non-Gentoo developers to commit code without
having to become a "Gentoo developer" and deal with Gentoo
policy/politics. We have countless examples on nearly every list of
people who would like to contribute, have the skills and the time
necessary, but don't want to deal with the day-to-day of Gentoo. We
should cater to these people.
Of course, I also think that Gentoo should "splinter" a bit more. I
think that we've grown beyond the scope of a single vision and single
goals, so some internal "forking" might be helpful. What I mean is
create multiple "levels" of developer, without necessarily creating a
closed environment. We already somewhat have this with the herds, but
this would be extending it a bit further. Basically, we'd have "Gentoo
developers" and "Gentoo staff" and finally "Gentoo contributors" who
would have access to certain resources, but not the main infrastructure.
A contributor would get access to what he needs, without getting things
like a Gentoo email address or being subscribed to -core. As overlays
become more and more common, this seems like a good way to go. I also
think that we should start using overlays more. New projects should get
an overlay "for free" essentially. This would allow them to recruit
people to work without having to make them become developers. Code
moves from the overlays to the main tree would still happen via a
"Gentoo developer" and would be checked. This is essentially proxy
maintaining, but with the external maintainer getting direct access to a
revision control system to do their work.
Stealing a (rather good, honestly) idea from Sunrise, we could even
recruit some people in a more "overlay wranglers" role. Basically, they
would be the people to check and verify ebuilds from the overlays and
move them to the main tree. We really should push and legitimize
overlays. They're a very powerful tool.
Anyway, I apologize for going so off-topic. I just wanted to get my
ideas out while they were still fresh in my head so I could have time to
respond to anything prior to the meeting, since I won't be in
Release Engineering Strategic Lead