List Archive: gentoo-council
Note: Due to technical difficulties, the Archives are currently not up to date.
provides an alternative service for most mailing lists.c.f. bug 424647
On Tue, Jul 7, 2009 at 11:58 AM, Roy Bamford<firstname.lastname@example.org> wrote:
> That splits the log and makes collecting a summary much harder as the
> discussion in the unmoderated channel needs to be logged and included
> in the summary somehow. After all, it is clearly relevant to the
> councils decision making process if the council members read it during
> a meeting. A new channel would make the recording process easier.
The other channel (if any) doesn't need to be logged. If a council
member thinks there's a valid point made in there, then (s)he can copy
it to the council channel or voice the user/dev. Then it can be
discussed with other members and it's automatically logged.
> I've never been a fan of +m for council meetings. By the time a meeting
> happens, everyone on the council should have made up their minds, their
> should be little to discuss. Even progress reports on topics can be
> obtained by email and 'read' to the meeting and hence into the meeting
Unfortunately the amount of trouble during a meeting doesn't depend on
how well people are prepared but on who you allow to talk. And since
we can't single out a few annoying individuals because they would
almost certainly not understand why we're doing this, the other simple
alternative is to only allow council members and as few as possible
guests to talk. I proposed to let everybody else participate in
another channel but I don't believe it's necessary. I just thought it
would be nice if we allowed the mess to occur on another channel while
at the same time being able to extract an idea that would emerge out
> I think the increase in productivity was due to council members being
> better prepared, rather than the increased meeting frequency. Maybe one
> was the result of the other ?
What usually happens (and I believe it was the case here) is that if
you allow people to slack less then they do more. It sounds trivial
but sometimes it needs to be said. ;o)
>> propose in exchange is we don't wait for the live meeting to discuss,
>> take decisions, vote, etc... Apart from unusually important votes or
>> decisions, nothing prevents us from doing all these on the
> Which mailing list?
> There needs to be a public record of the path leading to a decision.
I meant this one, i.e. email@example.com.
>> We should also get rid of both the slacker rule and proxies. They're
>> good examples of over-engineering.
> Yes. Council decisions should require an absolute majority of council
> members. That is 4 votes for or against with our present 7 member
At some point we'll need to discuss the process of changing GLEP39.
And maybe we should wait for that before we tackle the slacker and