| 1 |
On Sat, 2008-04-19 at 01:15 +0100, Roy Bamford wrote: |
| 2 |
> > Perhaps if it were worded more so that it allowed for someone to |
| 3 |
> > retain |
| 4 |
> > their status only if they vote. That should be close enough to the |
| 5 |
> > current way things are without forcing people out. |
| 6 |
> |
| 7 |
> I'm a little uncomfortable with that as it would mean identifying votes |
| 8 |
> with individuals. Not publicly but that information would have to be |
| 9 |
> knowable if membership were tied to voting. |
| 10 |
|
| 11 |
Well, we already track who voted today for Foundation membership. |
| 12 |
Remember, all we need to know is if someone voted, not what their vote |
| 13 |
*was* per se. |
| 14 |
|
| 15 |
> What about having retired devs apply for membership annually ? |
| 16 |
|
| 17 |
I wouldn't have a problem with it. Perhaps if we sent out something |
| 18 |
basically like: |
| 19 |
|
| 20 |
- Check if Foundation member |
| 21 |
- Check if retired in LDAP |
| 22 |
- If so, send a reminder email a week or so before nominations start/the |
| 23 |
initial meeting |
| 24 |
- If the person doesn't vote, they're out |
| 25 |
|
| 26 |
> The idea here being able to keep individual votes secret. |
| 27 |
|
| 28 |
Indeed. |
| 29 |
|
| 30 |
> I certainly don't want to forcibly retire active foundation members. |
| 31 |
|
| 32 |
Agreed. I just see that there are certain people that I am sure would |
| 33 |
love to have their voices heard in the Foundation, without devoting so |
| 34 |
much time directly to Gentoo development. I bet guys like drobbins and |
| 35 |
seemant would love to still have some input, without having to rejoin |
| 36 |
the development staff or run as a trustee. After all, if we increase |
| 37 |
the member -> trustee communications, which I think you guys have done a |
| 38 |
decent job trying to do so far, we could see good changes coming from |
| 39 |
the Foundation side. |
| 40 |
|
| 41 |
Here's a good example. I've been to several shows and conferences. |
| 42 |
Once of the major things that people seem really interested in Gentoo |
| 43 |
for is embedded work. We don't really have a lot of embedded people |
| 44 |
within Gentoo. Now, let's say that the Foundation decided that its |
| 45 |
membership thinks embedded is somewhere we should focus some resources. |
| 46 |
The Foundation could go and purchase some developer hardware, either to |
| 47 |
be hosted or to be sent to individuals. They could also recruit |
| 48 |
specifically for embedded positions. The new developers would be |
| 49 |
accountable to the Council and general Gentoo policy, but the person |
| 50 |
could, if desired, bypass some of the normal "Gentoo developer" |
| 51 |
recruitment. Let's say the person was going to be a coder, and not do |
| 52 |
anything with ebuilds. The Foundation could even have its own |
| 53 |
repositories, allowing non-Gentoo developers to commit code without |
| 54 |
having to become a "Gentoo developer" and deal with Gentoo |
| 55 |
policy/politics. We have countless examples on nearly every list of |
| 56 |
people who would like to contribute, have the skills and the time |
| 57 |
necessary, but don't want to deal with the day-to-day of Gentoo. We |
| 58 |
should cater to these people. |
| 59 |
|
| 60 |
Of course, I also think that Gentoo should "splinter" a bit more. I |
| 61 |
think that we've grown beyond the scope of a single vision and single |
| 62 |
goals, so some internal "forking" might be helpful. What I mean is |
| 63 |
create multiple "levels" of developer, without necessarily creating a |
| 64 |
closed environment. We already somewhat have this with the herds, but |
| 65 |
this would be extending it a bit further. Basically, we'd have "Gentoo |
| 66 |
developers" and "Gentoo staff" and finally "Gentoo contributors" who |
| 67 |
would have access to certain resources, but not the main infrastructure. |
| 68 |
A contributor would get access to what he needs, without getting things |
| 69 |
like a Gentoo email address or being subscribed to -core. As overlays |
| 70 |
become more and more common, this seems like a good way to go. I also |
| 71 |
think that we should start using overlays more. New projects should get |
| 72 |
an overlay "for free" essentially. This would allow them to recruit |
| 73 |
people to work without having to make them become developers. Code |
| 74 |
moves from the overlays to the main tree would still happen via a |
| 75 |
"Gentoo developer" and would be checked. This is essentially proxy |
| 76 |
maintaining, but with the external maintainer getting direct access to a |
| 77 |
revision control system to do their work. |
| 78 |
|
| 79 |
Stealing a (rather good, honestly) idea from Sunrise, we could even |
| 80 |
recruit some people in a more "overlay wranglers" role. Basically, they |
| 81 |
would be the people to check and verify ebuilds from the overlays and |
| 82 |
move them to the main tree. We really should push and legitimize |
| 83 |
overlays. They're a very powerful tool. |
| 84 |
|
| 85 |
Anyway, I apologize for going so off-topic. I just wanted to get my |
| 86 |
ideas out while they were still fresh in my head so I could have time to |
| 87 |
respond to anything prior to the meeting, since I won't be in |
| 88 |
attendance. |
| 89 |
|
| 90 |
-- |
| 91 |
Chris Gianelloni |
| 92 |
Release Engineering Strategic Lead |
| 93 |
Games Developer |
Archives