couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: [REMINDER] IRC meeting - 2013-04-24 19:00 UTC
Date Wed, 24 Apr 2013 18:34:19 GMT
Also, if something comes up for discussion regularly / predictably, that
indicates to me that we have a lack of consensus, and/or lack of structured
decision making. Both easily fixable.

On Wednesday, 24 April 2013, Jan Lehnardt wrote:

>
> On Apr 24, 2013, at 16:58 , Noah Slater <nslater@apache.org <javascript:;>>
> wrote:
>
> > Well, I don't like the idea of alternating times. I think it will become
> > confusing and hard to plan for, and I think we will see less
> participation
> > as a result. I also think that meetings held at 13:00 UTC will have very
> > few participants. This becomes a problem when the meeting is important
> > because of its proximity to another event (such as a release) because we
> > have a bunch of people in the US that cannot possibly be expected to
> attend
> > at that time.
> >
> > The current situation is:
> >
> > Meeting at 20:00 UTC, the optimal amount of people are able to
> participate.
> >
> > We're proposing:
> >
> > Meeting occasionally at 20:00 UTC and occasionally at 13:00 UTC. Many
> > people unable to participate half the time. Meeting times become
> irregular
> > and hard to plan for in general.
>
> The status-quo is actually that we alternate 14:00 UTC and 20:00 UTC on a
> weekly
> basis. It is predictable and easy to plan. In practice this only has
> happened
> twice. I don’t understand why we stick to what was agreed to in the past
> and
> instead discuss this every month or so without actually giving the plan a
> shot.
>
> Jan
> --
>
>
>
>
>
> >
> > This is a sub-optimal solution.
> >
> > What is the problem we are trying to solve?
> >
> > I don't think it's "how can we organise an IRC meeting so that everyone
> can
> > attend?" (That pre-supposes the solution.)
> >
> > I think it is more like "how do we get input from everyone?"
> >
> > I think another avenue for us to explore might be to consider that when
> we
> > post the minutes to the list, that's not the end of the conversation.
> >
> > There are two points at which you can contribute to the meeting, without
> > actually being there:
> >
> > 1) In reply to the meeting reminder. We have invited this every time, but
> > only a few people so far have actually added things to the agenda via
> this
> > method. I would suggest that if people can't make the 20:00 UTC time, but
> > they have something they want to add to the agenda, or they have some
> > information to share with the group (like a status update), then they
> post
> > it at this point.
> >
> > 2) In reply to the minutes. As we saw with the action item Benoit brought
> > up a week or so ago, I jumped right in, and started having a discussion
> > about it on the mailing list. I had missed that particular meeting, but
> > read the minutes, and started a discussion.
> >
> > In my mind, this should be sufficient to ensure that everybody can input
> > into the meetings.
> >
> > Perhaps the 20:00 UTC time is not the most optimal solution. (i.e. The
> time
> > when most people in the project can participate.) I note that the board
> > meets at 17:30 UTC. I think that's a valid question, and one we
> > should examine if it looks like there might be a better time. But I
> believe
> > that we should pick one, single optimal time for everybody, and then work
> > on ways to ensure that people who miss the meeting (either because of
> life
> > getting in the way, or timezones) can contribute without impediment.
> >
> >
> > On 24 April 2013 15:14, Dave Cottlehuber <dch@jsonified.com<javascript:;>>
> wrote:
> >
> >> On 24 April 2013 16:02, Noah Slater <nslater@apache.org <javascript:;>>
> wrote:
> >>> What about having two meetings?
> >>
> >> Hi Noah,
> >>
> >> We previously said we would alternate times "regularly" but I think
> >> we've only done that twice. For all the obvious reasons I'd prefer not
> >> to double up. What's the constraint?
> >>
> >> A+
> >> Dave
> >>
> >
> >
> >
> > --
> > NS
>
>

-- 
NS

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message