Denis Dupeyron wrote:
> I also propose that we go back to moderating the council channel
> during meetings, and that we give +v very carefully. In order to still
> allow everybody to participate though, I suggest council members keep
> an eye on another channel (#gentoo-dev or else) where anybody can
> discuss, and that they bring any idea they think is valuable to the
> council channel where the meeting is occurring. This way everybody can
> get a voice and we can keep the council channel tidy during meetings.

It needs some strong and active moderation to go with -v - therefore I'm
ok with +v.

> The main drawback of a monthly meeting is certainly the decrease in
> reactivity and productivity. I was pleased to see an increase in both
> when meetings went bi-weekly and wouldn't want to lose this.

If meetings are a tad more organized and prepared we won't loose and
productivity. 

> So what I
> 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
> mailing-list. This was already done in the past but we need to
> formalize the process a bit and make it more common. The easiest is we
> do the same as we should do in a live meeting, i.e. give time limits
> for discussions, for wrap-up (or vote), and make sure that all
> discussions end up in what-who-when (What is to be done exactly? Who
> will do it? By when does this person/group agree to get it done?). And
> since when nobody's in charge nothing happens, each topic should be
> pushed and followed-up by one volunteer council member. Let's take an
> example.
> 
>  - User/dev X wants the the council to discuss a particular issue and
> decide on a solution.
> 
>  - Council member Y picks up the proposition and volunteers to push it
> to discussion.
> 
>  - Y decides it's a fairly simple topic which can be discussed on the
> mailing-list in one week, after which all council members will be
> given 2 days to vote if necessary (this answers "What?").
> 
>  - If the decision requires an implementation then Y looks actively
> for a volunteer to do it ("who?"), and finds Z. If there's more than
> one volunteer it's a good idea to have them work together, but in case
> it's not possible (or the issue or persons are controversial) Y may go
> back to the council members to discuss who will actually do it.
> 
>  - Y works out a schedule and action list with Z. It's important to
> make sure that Z is confident that it can be done.
> 
> That's just an example. What actually matters is that somebody makes
> sure that things are progressing. Note that if X is a council member
> then (s)he becomes a natural candidate to push the idea and lead the
> effort. In other words, it's nice to talk but it's even nicer to act.
> 
> I strongly believe that if we can't make that process work efficiently
> enough then we should consider going back to biweekly meetings.

In an ideal case I'd like to see all (or most) discussion going on
on-list and our meetings are only used to sum up opinions and voting. If
we need a formal process for that - guess not. We just need to do it.

> We should also get rid of both the slacker rule and proxies. They're
> good examples of over-engineering.

In general I do agree, but that should require a general vote of all
developers.

- Tobias