1 |
On Tue, Jul 7, 2009 at 11:58 AM, Roy Bamford<neddyseagoon@g.o> wrote: |
2 |
> That splits the log and makes collecting a summary much harder as the |
3 |
> discussion in the unmoderated channel needs to be logged and included |
4 |
> in the summary somehow. After all, it is clearly relevant to the |
5 |
> councils decision making process if the council members read it during |
6 |
> a meeting. A new channel would make the recording process easier. |
7 |
|
8 |
The other channel (if any) doesn't need to be logged. If a council |
9 |
member thinks there's a valid point made in there, then (s)he can copy |
10 |
it to the council channel or voice the user/dev. Then it can be |
11 |
discussed with other members and it's automatically logged. |
12 |
|
13 |
> I've never been a fan of +m for council meetings. By the time a meeting |
14 |
> happens, everyone on the council should have made up their minds, their |
15 |
> should be little to discuss. Even progress reports on topics can be |
16 |
> obtained by email and 'read' to the meeting and hence into the meeting |
17 |
> record. |
18 |
|
19 |
Unfortunately the amount of trouble during a meeting doesn't depend on |
20 |
how well people are prepared but on who you allow to talk. And since |
21 |
we can't single out a few annoying individuals because they would |
22 |
almost certainly not understand why we're doing this, the other simple |
23 |
alternative is to only allow council members and as few as possible |
24 |
guests to talk. I proposed to let everybody else participate in |
25 |
another channel but I don't believe it's necessary. I just thought it |
26 |
would be nice if we allowed the mess to occur on another channel while |
27 |
at the same time being able to extract an idea that would emerge out |
28 |
of it. |
29 |
|
30 |
> I think the increase in productivity was due to council members being |
31 |
> better prepared, rather than the increased meeting frequency. Maybe one |
32 |
> was the result of the other ? |
33 |
|
34 |
What usually happens (and I believe it was the case here) is that if |
35 |
you allow people to slack less then they do more. It sounds trivial |
36 |
but sometimes it needs to be said. ;o) |
37 |
|
38 |
>> propose in exchange is we don't wait for the live meeting to discuss, |
39 |
>> take decisions, vote, etc... Apart from unusually important votes or |
40 |
>> decisions, nothing prevents us from doing all these on the |
41 |
>> mailing-list. |
42 |
> Which mailing list? |
43 |
> There needs to be a public record of the path leading to a decision. |
44 |
|
45 |
I meant this one, i.e. gentoo-council@g.o. |
46 |
|
47 |
>> We should also get rid of both the slacker rule and proxies. They're |
48 |
>> good examples of over-engineering. |
49 |
>> |
50 |
> [snip] |
51 |
> Yes. Council decisions should require an absolute majority of council |
52 |
> members. That is 4 votes for or against with our present 7 member |
53 |
> council |
54 |
|
55 |
At some point we'll need to discuss the process of changing GLEP39. |
56 |
And maybe we should wait for that before we tackle the slacker and |
57 |
proxy issues. |
58 |
|
59 |
Denis. |