Meeting format

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

Meeting format

Denis Dupeyron
Solar has proposed that we go back to monthly meetings. Scheduling a
live meeting is difficult due to the council members being spread over
different time zones. Someone even had to take time off from work to
participate to council meetings, and Gentoo should not be allowed to
require such a sacrifice from our professional or, worse, personal
schedules. Multiplying live meetings only makes things more
complicated and hence going back to once a month makes sense. We
should not get rid of the live meetings altogether though, because
some decisions require the legitimacy and symbolism of a good
old-fashioned live meeting to be better perceived and accepted by the
target audience. Not having any live meeting could also weaken the
relationships between the members.

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.

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. 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.

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

The slacker rule was introduced in different times to avoid a
particular type of behavior, and I think this doesn't apply anymore.
We're volunteers, we're doing our best to participate to meetings and
fulfill our obligations, so there's no point in punishing ourselves
with such a rule. In all the places I've worked I've never seen
anybody being fired because (s)he couldn't attend a meeting. Hell,
I've never seen anybody blatantly skipping meetings or
sleeping/texting/etc being fired either. When people know they can't
attend a meeting they usually email a note giving their thoughts and
votes for each topic on the agenda. If the missing person
couldn't/didn't warn then (s)he is simply marked "missing" in the
meeting minutes. And you know what? The earth never stopped turning.
In case the discussions drift off the agenda (which shouldn't happen
in a perfect world) and if the quorum isn't reached to decide/vote on
that unexpected item then the discussion is adjourned to a later
meeting (that could be the mailing list in our case). If and when it
becomes obvious that a council member has lost interest or can't
afford the time anymore to be on the council, then it's his/her
responsibility to resign, and it's the other members' responsibility
to discuss resignation with him/her if it does not happen.

As for proxies, I have no problem with them but it seems controversial
and I do agree that there may be latent issues with the concept. All
fixes to it or alternatives I've seen seem more complicated to deal
with than the actual problem itself. See above for my thoughts on what
to do in case of a council member missing a meeting.

If you agree I propose that we discuss the meeting format on this
mailing-list, more specifically:
 - Live-meeting periodicity (plus date/time of the first meeting)
 - Channel moderated during meetings? Another channel for people to
discuss at the same time?
 - Off-line meetings / decision process (see example above)
 - Do we keep the slacker rule and proxies?

I also suggest we discuss until Monday July 13th at 0600UTC, and vote
no later than Tuesday July 14th at 0600 UTC (and as early as you
want). Vote is informal and means just say as clearly and concisely as
possible what you prefer of all the discussed alternatives. Feel free
to propose another schedule but in that case please do so ASAP.

Denis.

Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

solar-4
On Mon, 2009-07-06 at 18:52 -0600, Denis Dupeyron wrote:
> We should also get rid of both the slacker rule and proxies. They're
> good examples of over-engineering.

This is not within the councils power to get rid of. The users voted for
GLEP-39 http://www.gentoo.org/proj/en/glep/glep-0039.html which states
our requirements. Should it not be up to them to change it?

Note personally I think the mark is childish as written for the most
part and got rushed in some 5 years ago. But it does have some validity
in that it seems to yield council members to stepping down from the
council before returning to the slack nature that we all need from time
to time.

Re: Best times for meetings..
Ok so I generally am employed from the hours of 9-5 M-F PST (GMT-7). The
company I work for can have official meetings any day of the week any
hour of the day with not much more than an hours notice. I've been in
the meeting/council channel for over 5 years now. So I clearly have an
interest in what we are doing as a meta distribution, but If I'm unable
to make a meeting and it's scheduled in the time-frame of my work hours
then I can guaranty nothing. It's more likely that I'd have to be in/out
for the duration of the meeting. If proxy is required then I'd call for
a semi perm proxy of the next in line on the vote rankings. At least
till it causes a personal conflict of interest.

We can vote on the +m/+v thing if you want to make it official. But it
seems we had a general consensus from everybody that this is what would
be best.


Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Luca Barbato
Ned Ludd wrote:
> On Mon, 2009-07-06 at 18:52 -0600, Denis Dupeyron wrote:
>> We should also get rid of both the slacker rule and proxies. They're
>> good examples of over-engineering.
>
> This is not within the councils power to get rid of. The users voted for
> GLEP-39 http://www.gentoo.org/proj/en/glep/glep-0039.html which states
> our requirements. Should it not be up to them to change it?

So we could just use votify to ask if they are ok to remove them or not.

> Re: Best times for meetings..
> Ok so I generally am employed from the hours of 9-5 M-F PST (GMT-7). The
> company I work for can have official meetings any day of the week any
> hour of the day with not much more than an hours notice. I've been in
> the meeting/council channel for over 5 years now. So I clearly have an
> interest in what we are doing as a meta distribution, but If I'm unable
> to make a meeting and it's scheduled in the time-frame of my work hours
> then I can guaranty nothing. It's more likely that I'd have to be in/out
> for the duration of the meeting. If proxy is required then I'd call for
> a semi perm proxy of the next in line on the vote rankings. At least
> till it causes a personal conflict of interest.

Ok...

> We can vote on the +m/+v thing if you want to make it official. But it
> seems we had a general consensus from everybody that this is what would
> be best.

Well, to make it simpler we could just reply in this thread, I'm in favor.

lu

--

Luca Barbato
Gentoo Council Member
Gentoo/linux Gentoo/PPC
http://dev.gentoo.org/~lu_zero


Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Lukasz Damentko-2
In reply to this post by Denis Dupeyron
2009/7/7 Denis Dupeyron <[hidden email]>:
> Scheduling a live meeting is difficult due to the council members
> being spread over different time zones.

Let's create a Council sub-forum on f.g.o:

- "Council" forum, main place where people would discuss issues
concerning Gentoo as a whole.
- "Proposals" sub-forum where everyone could start a thread with an
issue Council should in his opinion discuss.
- "Council Chambers" subforum where council would discuss between
themselves and start threads in which votes would be collected. Only
Council Members would be able to post there.

- #gentoo-council channel should stay where it is as a secondary way
of communication between Council Members and wide community but should
be replaced in decision-making by the forum.

Advantages:

- No need to be in one place at one time, you can comment when you
have time. Just start a poll with a time-out (7 days, 3 days?) and
wait for council members to vote.
- Ability to moderate. Lock threads when they go too wild, delete
unwanted posts, edit your previous posts, edit thread titles, sticky
important things. All the things you can't do on IRC or on mailing
lists. Just imagine the possibilities.
- You could copy half a thread and move it to another place to discuss
there separately. Something that would prevent derailing discussion
which happens on regular basis on mailings lists.
- You can "watch" threads you consider important and receive e-mails
with information about new posts in them.
- You can open a sub-forum for bigger issues (like EAPI stuff for
example which is currently spread over many meeting summaries and
posts on mailing lists) to keep them organised and in order.
- No dependance on Freenode team (with all due respect and
appreciation to their hard work they put into providing best IRC
service there is to our project). Forum would be on a machine
belonging to Gentoo, run by Gentoo Infra and moderated only be people
named by Gentoo.
- All other features that made civilised world to abandon mailing
lists and switch to forums.

And most importantly.
- People put more thought into what they write to forums than they do
when they use IRC. There would be less chit-chat and even if some
appears it'll be easy enough to move it somewhere else.

Disadvantages:

- Would need edits in the GLEP, like for example rethinking whole
"slacker" and "proxy" concepts.
- Forum project would have to agree to hand a forum over to where
Council would be sole moderators and rule makers. This issue is
probably not a big problem but since no-one asked them yet, I wouldn't
take it for granted.
- Would need moderators. There's one secretary already and I think it
could be a start for a future moderating team.
- "Disappearing posts" aka censorship - when people post something and
moderators just delete it without trace. Could be dodge by creating a
dustbin/hydepark sub-forum where moderators would copy/move threads
and posts instead of deleting them so they don't disappear even if
they are considered garbage.
- No archives. Well, forum is an archive itself so no need to archive
it elsewhere.
- "Forum is down, council can't proceed" - it applies to mailing lists
and IRC as well and can be easily dodged by moving back to lists and
IRC once it happens. I don't think our forum goes down more often than
Freenode...
- "My issue with forums is that I don't use them" - reason why my idea
won't be implemented most probably, some people just won't use forums
and that's it. Just think about how much easier it would be to
organize your work on a forum compared to what happens now. Maybe it's
worth trying?

Opinions, counter-ideas and bashing most welcome.

Regards,

Lukasz Damentko

Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Roy Bamford-2
In reply to this post by Denis Dupeyron
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.07.07 01:52, Denis Dupeyron wrote:
[snip]

>
> 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.
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.

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
record.

Meetings are then little more than the public recording of council
decisions.  

>
> 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. So what

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 ?  

> 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.
Which mailing list?
There needs to be a public record of the path leading to a decision.
 
[snip good stuff]

>
> We should also get rid of both the slacker rule and proxies. They're
> good examples of over-engineering.
>
[snip]
Yes. Council decisions should require an absolute majority of council
members. That is 4 votes for or against with our present 7 member
council

>
> Denis.
>
>
>
>

- --
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAkpTjLsACgkQTE4/y7nJvavuBgCg7B47tda7F0qVGEeait2LybYv
LXYAoPxQH75nKf461rHiwvhTRav/4HE7
=FUxp
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Roy Bamford-2
In reply to this post by solar-4
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.07.07 04:20, Ned Ludd wrote:

> On Mon, 2009-07-06 at 18:52 -0600, Denis Dupeyron wrote:
> > We should also get rid of both the slacker rule and proxies.
> They're
> > good examples of over-engineering.
>
> This is not within the councils power to get rid of. The users voted
> for
> GLEP-39 http://www.gentoo.org/proj/en/glep/glep-0039.html which
> states
> our requirements. Should it not be up to them to change it?
>
[snip]
I think you mean developers not users but that's a bye the way.
Authority comes to the council in two forms, that which is delegated
(by glep39) and that which they assume.

The limits of the latter are only determined by trial and error. If the
council deceided to get rid of slacker marks and proxies I doubt there
would be a backlash from the electorate. The council is supposed to be
representative of the developers they represent.

>
>

- --
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAkpTjnIACgkQTE4/y7nJvat9NQCgqQEfr24uf1W3mWT9RVa0ep9G
kU0An2+Mc/WzHBGQ6Jad9Av6W4PbaI9r
=QuCf
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Roy Bamford-2
In reply to this post by Lukasz Damentko-2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2009.07.07 18:30, Lukasz Damentko wrote:
> 2009/7/7 Denis Dupeyron <[hidden email]>:
> > Scheduling a live meeting is difficult due to the council members
> > being spread over different time zones.
>
> Let's create a Council sub-forum on f.g.o:
[snip]
> Opinions, counter-ideas and bashing most welcome.
>
> Regards,
>
> Lukasz Damentko
>
>
>
Moderation and reorganising posts is a not trivial task (I do it now)  
and would add to the councils workload and only council members would
be able to moderate as only they could deceide what was relevant.

There is also the case where moderators do not agree on the action to
take. That happens now too.

On the whole, I suggest that the extra work outweighs the advantage of
extra flexibility.

- --
Regards,

Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.12 (GNU/Linux)

iEYEARECAAYFAkpTkUcACgkQTE4/y7nJvassRgCfXck81MV0nGSvMV0iyDu4yHng
ktcAnjnGFOZliRQ1G/ZRKm1Eyk4oAQQS
=UZgk
-----END PGP SIGNATURE-----


Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Denis Dupeyron
In reply to this post by Roy Bamford-2
On Tue, Jul 7, 2009 at 11:58 AM, Roy Bamford<[hidden email]> 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
> record.

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
of it.

> 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
>> mailing-list.
> Which mailing list?
> There needs to be a public record of the path leading to a decision.

I meant this one, i.e. [hidden email].

>> We should also get rid of both the slacker rule and proxies. They're
>> good examples of over-engineering.
>>
> [snip]
> Yes. Council decisions should require an absolute majority of council
> members. That is 4 votes for or against with our present 7 member
> council

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
proxy issues.

Denis.

Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Tobias Scherbaum
In reply to this post by Denis Dupeyron
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



signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Tobias Scherbaum
In reply to this post by Roy Bamford-2
Roy Bamford wrote:
> On the whole, I suggest that the extra work outweighs the advantage of
> extra flexibility.

I tend to agree ...

- Tobias


signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Doug Goldstein
In reply to this post by Tobias Scherbaum
On Wed, Jul 8, 2009 at 1:41 PM, Tobias Scherbaum<[hidden email]> wrote:

> 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.
>

Glad to see this actually happening after the last council voted this down 4-3.

--
Doug Goldstein

Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Doug Goldstein
In reply to this post by solar-4
On Mon, Jul 6, 2009 at 10:20 PM, Ned Ludd<[hidden email]> wrote:

> On Mon, 2009-07-06 at 18:52 -0600, Denis Dupeyron wrote:
>> We should also get rid of both the slacker rule and proxies. They're
>> good examples of over-engineering.
>
> This is not within the councils power to get rid of. The users voted for
> GLEP-39 http://www.gentoo.org/proj/en/glep/glep-0039.html which states
> our requirements. Should it not be up to them to change it?
>
> Note personally I think the mark is childish as written for the most
> part and got rushed in some 5 years ago. But it does have some validity
> in that it seems to yield council members to stepping down from the
> council before returning to the slack nature that we all need from time
> to time.
>
> Re: Best times for meetings..
> Ok so I generally am employed from the hours of 9-5 M-F PST (GMT-7). The
> company I work for can have official meetings any day of the week any
> hour of the day with not much more than an hours notice. I've been in
> the meeting/council channel for over 5 years now. So I clearly have an
> interest in what we are doing as a meta distribution, but If I'm unable
> to make a meeting and it's scheduled in the time-frame of my work hours
> then I can guaranty nothing. It's more likely that I'd have to be in/out
> for the duration of the meeting. If proxy is required then I'd call for
> a semi perm proxy of the next in line on the vote rankings. At least
> till it causes a personal conflict of interest.

This will be the truth for most US based Gentoo developers/council
members. So this is something that really needs to be addressed
properly because obviously changing the times back to where it worked
the best for US based Gentoo council members didn't work in the past
and resulted in the change to work for the EU based people. The
constant push and pull just won't work.

--
Doug Goldstein

Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Rich Freeman
In reply to this post by Denis Dupeyron
Denis Dupeyron wrote:
> I also propose that we go back to moderating the council channel
> during meetings, and that we give +v very carefully.

I like some of the suggestions to have forum polls in place of scheduled
council meetings.  If you do want to have a scheduled meeting, why not aim
to have 10-15 minute meetings.  The channel would be moderated, the
moderator would present the next agenda item, and council members would
vote.  Council members could read items into the minutes if desired.  

When I've read council minutes in the past they seem like they tend to
ramble on.  Sometimes I see a minute pass between posts.  It seems like the
fact that the meetings are so long means that people end up having the
council on in the background while they do real life in the foreground.
Maybe when they pull up to a traffic light they type in another line on
their smartphone or something.

Why not try to have most of the content/discussion happen on mailing lists,
or irc as needed.  The formal meeting time would be the time to formalize
the decisions that effectively have already been made.

After the conclusion of official business those who are able to could stick
around to chat/discuss more items, and moderation could be opened up at
some point.  However, council members who have pressing matters would be
free to leave at the conclusion of official business.

I do like the idea of having a place where council members can "hang out"
and be available to devs for discussion.  Certainly this doen't need to be
an on-duty assignment - just a place where people can go and be likely to
find council members.  That could be email/irc/forums or whatever.

I'm also in favor of getting rid of slacker marks (by all means publish
attendence records - but don't take automatic action).  The whole re-elect
the council after two months because the meeting times weren't clear thing
last year was a real waste of time/mandate.  By all means have some
mechanism for recall if a council member suddenly stops showing up to
meetings.  Maybe a petition signed by x developers, or a majority vote of
the council to start a votify poll for a recall.  Any recall decision
should be ratified by the developer population of course, and council
members remain in office until kicked out.  


Reply | Threaded
Open this post in threaded view
|

Re: Meeting format

Denis Dupeyron
In reply to this post by Doug Goldstein
On Thu, Jul 9, 2009 at 11:39 PM, Doug Goldstein<[hidden email]> wrote:
> This will be the truth for most US based Gentoo developers/council
> members. So this is something that really needs to be addressed
> properly because obviously changing the times back to where it worked
> the best for US based Gentoo council members didn't work in the past
> and resulted in the change to work for the EU based people. The
> constant push and pull just won't work.

Although it is desirable there is no reason why the meeting time has
to be at a specific and constant time. We can adjust based on council
members' availability. I'm sure though that we'll select a meeting
time that won't change much if at all during the whole term. That said
we are working on this and it looks like early evening CET and lunch
time MDT/PDT looks like the best time. Right now the majority of EU
based members makes that US based members aren't really in a position
to set the time (and fortunately I moved recently or poor solar would
be alone ;o) ), but I'm sure we'll find a solution which satisfies
everybody.

Denis.