1 |
Denis Dupeyron wrote: |
2 |
> I also propose that we go back to moderating the council channel |
3 |
> during meetings, and that we give +v very carefully. In order to still |
4 |
> allow everybody to participate though, I suggest council members keep |
5 |
> an eye on another channel (#gentoo-dev or else) where anybody can |
6 |
> discuss, and that they bring any idea they think is valuable to the |
7 |
> council channel where the meeting is occurring. This way everybody can |
8 |
> get a voice and we can keep the council channel tidy during meetings. |
9 |
|
10 |
It needs some strong and active moderation to go with -v - therefore I'm |
11 |
ok with +v. |
12 |
|
13 |
> The main drawback of a monthly meeting is certainly the decrease in |
14 |
> reactivity and productivity. I was pleased to see an increase in both |
15 |
> when meetings went bi-weekly and wouldn't want to lose this. |
16 |
|
17 |
If meetings are a tad more organized and prepared we won't loose and |
18 |
productivity. |
19 |
|
20 |
> So what I |
21 |
> propose in exchange is we don't wait for the live meeting to discuss, |
22 |
> take decisions, vote, etc... Apart from unusually important votes or |
23 |
> decisions, nothing prevents us from doing all these on the |
24 |
> mailing-list. This was already done in the past but we need to |
25 |
> formalize the process a bit and make it more common. The easiest is we |
26 |
> do the same as we should do in a live meeting, i.e. give time limits |
27 |
> for discussions, for wrap-up (or vote), and make sure that all |
28 |
> discussions end up in what-who-when (What is to be done exactly? Who |
29 |
> will do it? By when does this person/group agree to get it done?). And |
30 |
> since when nobody's in charge nothing happens, each topic should be |
31 |
> pushed and followed-up by one volunteer council member. Let's take an |
32 |
> example. |
33 |
> |
34 |
> - User/dev X wants the the council to discuss a particular issue and |
35 |
> decide on a solution. |
36 |
> |
37 |
> - Council member Y picks up the proposition and volunteers to push it |
38 |
> to discussion. |
39 |
> |
40 |
> - Y decides it's a fairly simple topic which can be discussed on the |
41 |
> mailing-list in one week, after which all council members will be |
42 |
> given 2 days to vote if necessary (this answers "What?"). |
43 |
> |
44 |
> - If the decision requires an implementation then Y looks actively |
45 |
> for a volunteer to do it ("who?"), and finds Z. If there's more than |
46 |
> one volunteer it's a good idea to have them work together, but in case |
47 |
> it's not possible (or the issue or persons are controversial) Y may go |
48 |
> back to the council members to discuss who will actually do it. |
49 |
> |
50 |
> - Y works out a schedule and action list with Z. It's important to |
51 |
> make sure that Z is confident that it can be done. |
52 |
> |
53 |
> That's just an example. What actually matters is that somebody makes |
54 |
> sure that things are progressing. Note that if X is a council member |
55 |
> then (s)he becomes a natural candidate to push the idea and lead the |
56 |
> effort. In other words, it's nice to talk but it's even nicer to act. |
57 |
> |
58 |
> I strongly believe that if we can't make that process work efficiently |
59 |
> enough then we should consider going back to biweekly meetings. |
60 |
|
61 |
In an ideal case I'd like to see all (or most) discussion going on |
62 |
on-list and our meetings are only used to sum up opinions and voting. If |
63 |
we need a formal process for that - guess not. We just need to do it. |
64 |
|
65 |
> We should also get rid of both the slacker rule and proxies. They're |
66 |
> good examples of over-engineering. |
67 |
|
68 |
In general I do agree, but that should require a general vote of all |
69 |
developers. |
70 |
|
71 |
- Tobias |