1 |
On Thu, Jul 2, 2009 at 7:54 AM, Tobias Scherbaum<dertobi123@g.o> wrote: |
2 |
> Ned Ludd wrote: |
3 |
>> The devs have a voice one time of the year: when it comes time to vote. |
4 |
>> But what about the rest of the year? What happens when the person you |
5 |
>> voted for sucks? You are mostly powerless to do anything other than be |
6 |
>> really vocal in what seems like a never ending battle. That needs to |
7 |
>> change. I'm not quite sure how. But I'd like to see the dev body have a |
8 |
>> year-round voice in the council. Either via quick votes year-round |
9 |
>> on topics or simply by having discussion in the channel. Devs should have |
10 |
>> a right to voice their concerns to the council and engage in interactive |
11 |
>> conversations without being labeled troll. |
12 |
> |
13 |
> I'm not sure about that, but we can easily give it a try. |
14 |
> |
15 |
> What I'd like to see for sure is a formal rule on who can decide to |
16 |
> modify or change parts of glep 39. As it's the council's constitution |
17 |
> somehow, we have two options from my pov (besides that a former council |
18 |
> did decide the council itself can change it's rules): |
19 |
> - a large majority (at least 5 out of 7) of council members needs to ack |
20 |
> the change |
21 |
> - changes to glep 39 require a vote with all developers participating |
22 |
> and a large majority (2/3 or 3/4) needs to ack the suggested change |
23 |
|
24 |
Just FYI, Gentoo is lucky if 1/2 of the devs vote; so I assume here |
25 |
you mean large majority of the people who actually voted. |
26 |
|
27 |
> |
28 |
> Also I'd like to require commit messages to gleps (and especially glep |
29 |
> 39) being useful and denote based on which decision by whom that change |
30 |
> got made. For example the following commit message I'd consider quite |
31 |
> useless (at least two or three years ago): |
32 |
> |
33 |
> "Add the one person one vote clause to GLEP 39 as agreed." [1] |
34 |
> |
35 |
> Who did agree? Where is that noted down? ... and so on. |
36 |
> |
37 |
>> An EAPI review committee could work well also. As long as we could get |
38 |
>> non bias people in there. |
39 |
> |
40 |
> I was thinking about that for quite some time and as long as we get some |
41 |
> non-biased people in there we should try that as well. |
42 |
> |
43 |
>> The council should be more about community vs technical issues only. |
44 |
>> We have lots of top level projects within Gentoo which have simply given |
45 |
>> up on the council as being an outlet to accomplish anything useful. |
46 |
>> It should be our job to look at the projects in Gentoo. Look at the ones |
47 |
>> that have a healthy community and encourage and promote them in ways. |
48 |
> |
49 |
> ack |
50 |
> |
51 |
>> For example prefix comes to mind. It was a project I did not like at |
52 |
>> first. I'm not even a user. And there are things I surely don't like |
53 |
>> about it as is. But there is community support and it's the icing on the |
54 |
>> cake for some. So I'll back the fsck up and give credit where it's due. |
55 |
>> This is a perfectly good example of a project/fork that needs to come |
56 |
>> back home. Perhaps it's time to cherry pick some more stuff/people out |
57 |
>> of Sunrise? |
58 |
> |
59 |
> prefix is a really good example, yeah. Nearly noone knows it, but it's |
60 |
> really cool to have for example a virtualized windows machine running on |
61 |
> a linux host. The windows box then runs prefix in interix. Not that it's |
62 |
> really useful at all (hey, it's slow as hell) - but it's very |
63 |
> interesting that such things are possible and it's definitively an |
64 |
> eyecatcher on expos. prefix is one of Gentoo's most underrated projects. |
65 |
> |
66 |
> As for Sunrise I do think that's what we already do - but: getting users |
67 |
> more actively involved in Sunrise makes them happy, plus it's easier for |
68 |
> us to recruit new developers. Therefore: push Sunrise! I very much |
69 |
> disliked how the Sunrise project has been started some years ago, but in |
70 |
> the end we do need to integrate it a tad better to make it even more |
71 |
> useful for both users and developers. |
72 |
> |
73 |
>> desultory points out any two council members can decide to approve anything, |
74 |
>> and that decision is considered to be equivalent to a full council vote |
75 |
>> until the next meeting. I vaguely recall that rule. I'm not sure about you, |
76 |
>> but I think that is a little to much power to put in the hands of a few. |
77 |
>> Any dev mind if we dump that power? |
78 |
> |
79 |
> It's quite much power in quite a few hands, but in the end that's some |
80 |
> kind of "last resort rule". All council members should be smart enough |
81 |
> (and i do consider all of us being smart enough) to know when that "last |
82 |
> resort" becomes active. Therefore I think it doesn't hurt to have such a |
83 |
> rule in place. |
84 |
> |
85 |
>> Meetings will likely go back to one time per month and be +m with +v be |
86 |
>> handed out per request with open chat pre/post meetings. The reason for |
87 |
>> this is to keep the meetings on-track. I won't engage in endless |
88 |
>> discussions. Facts can be presented. They will be reviewed on merit, |
89 |
>> technical and social. |
90 |
>> |
91 |
>> The reason the meetings should go back to monthly is to allow those who |
92 |
>> are council members in Gentoo to accomplish things other than the |
93 |
>> council only. We all have personal lives and we all have our respective |
94 |
>> roles we play outside of the council. Another note on meetings. The time |
95 |
>> they are held currently don't fit well with my work schedule. |
96 |
> |
97 |
> I'm all for going back to monthly meetings and make them a tad more |
98 |
> organized. As I summarized in the last few minutes of our last council |
99 |
> meeting - we do have rules in place to keep our meetings organized, we |
100 |
> just need to follow them. |
101 |
> |
102 |
> As for meeting times we can (that was mentioned somewhere?) move to 21 |
103 |
> or 22 utc - if we're going to monthly meetings and restrict meetings to |
104 |
> say 60 or 90 minutes. If we have an agenda sent out a week ago everyone |
105 |
> should be able to be well prepared for the meeting so a restriction on |
106 |
> length of meetings wouldn't hurt. |
107 |
> |
108 |
> If council@g.o is updated we can quickly vote on meeting times. |
109 |
> |
110 |
>> Thank you all and I will try not to let you down. Unless you were one of |
111 |
>> the ones who wanted to me lose. Then sorry, but I'm going to have fun |
112 |
>> disappointing you, by doing what is best for Gentoo. |
113 |
> |
114 |
> And that's basically our job: taking care of Gentoo. |
115 |
> |
116 |
>> So lets have some damn fun again !@#$ |
117 |
> |
118 |
> yay! |
119 |
> |
120 |
> - Tobias |
121 |
> |
122 |
> |
123 |
> [1] |
124 |
> http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/glep-0039.txt?r1=1.1&r2=1.2 |
125 |
> |