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 |