Gentoo Archives: gentoo-dev

From: "Steven J. Long" <slong@××××××××××××××××××.uk>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC
Date: Thu, 25 Jul 2013 21:20:42
Message-Id: 20130725212058.GB8481@rathaus.eclipse.co.uk
In Reply to: Re: [gentoo-dev] Re: [gentoo-dev-announce] Council constituent meeting 30 July 2013 at 19:00 UTC by Rich Freeman
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 ;-)