1 |
Rich Freeman wrote: |
2 |
> Roy Bamford wrote: |
3 |
> > The open floor is a part of the openness and approachability of the |
4 |
> > council. Its 60 seconds well spent, even if nobody says anything. |
5 |
> |
6 |
> The concern that was raised was that when it does get used it is rare |
7 |
> for anything to get accomplished. The desire is to have issues raised |
8 |
> and debated on the lists first. |
9 |
> |
10 |
> I don't have a big problem with open floor - I just think it is a bit |
11 |
> of a waste of time. If somebody wants to raise an issue they need |
12 |
> only ask. |
13 |
|
14 |
It's the "only ask" bit that isn't so easy: emailing someone you don't know, or |
15 |
raising a bug when you're used to it, or are unsure what kind of response you'll |
16 |
get, can be tricky; but you may still have something you'd like to bring to the |
17 |
Council. It's only 60 seconds, and I think it keeps the idea of openness and |
18 |
approachability in the forefront. |
19 |
I'd keep it, and expect it to be used for last-minute messages, or reading-up on |
20 |
late-breaking info on agenda items. |
21 |
|
22 |
> >> - vote on meeting format 2: "shift council votes to mail instead of |
23 |
> >> IRC" |
24 |
> > |
25 |
> > Please keep voting in public. Its good for accountability. |
26 |
> > If not in IRC, find a way to publish who voted and now. |
27 |
> > Council do not get a secret ballot. |
28 |
> |
29 |
> Agreed. I don't think the intent of that item was ever to REPLACE |
30 |
> in-person voting with email. I think the intent was to allow for it |
31 |
> so that when a critical issue comes up a week after the agenda is |
32 |
> already set that everybody doesn't have to wait 5 weeks for the |
33 |
> following council meeting. It seems really odd to have a 100-post |
34 |
> flamewar with no immediate action, and then to dredge up the topic a |
35 |
> month later and vote, and then have another 100-post flameware to talk |
36 |
> about the outcome. I don't think we need off-the-cuff decisions, but |
37 |
> if a topic is ripe for a decision we should have a way to actually |
38 |
> take care of it. |
39 |
|
40 |
That seems to me more a function of the ML, than the decisions themselves. It's |
41 |
dumb to have a flamewar when the decision has already been made. The only thing |
42 |
to discuss thereafter is implementation and support for the "minority" be that via |
43 |
USE-flags, in overlay, or none, ie: forums/-user ML. |
44 |
If Council members are going to be more involved in the mailing-list, as suggested, |
45 |
I think that will take a lot of the sting out of it. The discussion will have some of |
46 |
you involved, so it will be kept less flammable, and there will be more of a feeling |
47 |
that it is leading to a conclusion, rather than a feeling that it can be kick-started |
48 |
again at any point, and thus more focus. |
49 |
|
50 |
> Public debate and votes only make sense. Bugs might be a useful way |
51 |
> to record this (much as is done with the trustees). |
52 |
|
53 |
If you do have something that must be done in-between times, then I agree that |
54 |
bugs are a much more transparent manner of recording it, even if they are locked |
55 |
for confidential matters. |
56 |
|
57 |
Regard, |
58 |
steveL |
59 |
-- |
60 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |