Open Stack

On 18 August 2014 11:18, Thierry Carrez <thierry at openstack.org> wrote:
> Doug Hellmann wrote:
>> On Aug 13, 2014, at 4:42 PM, Russell Bryant <rbryant at redhat.com> wrote:
>>> Let me try to say it another way.  You seemed to say that it wasn't much
>>> to ask given the rate at which things happen in OpenStack.  I would
>>> argue that given the rate, we should not try to ask more of individuals
>>> (like this proposal) and risk burnout.  Instead, we should be doing our
>>> best to be more open an inclusive to give the project the best chance to
>>> grow, as that's the best way to get more done.
>>>
>>> I think an increased travel expectation is a raised bar that will hinder
>>> team growth, not help it.
>>
>> +1, well said.
>
> Sorry, I was away for a few days. This is a topic I have a few strong
> opinions on :)

Same here, sorry for posting so high up in the tread.

> There is no denial that the meetup format is working well, comparatively
> better than the design summit format. There is also no denial that that
> requiring 4 travels per year for a "core" dev is unreasonable. Where is
> the limit ? Wouldn't we be more productive and aligned if we did one per
> month ? No, the question is how to reach a sufficient level of focus and
> alignment while keeping the number of "mandatory" travel at 2 per year.

I think its important we try to get everyone together as often as
possible, it seems like 2 per year is the best compromise.

I prefer "expected" rather than "mandatory", but thats a detail. Some
times there are more important family things, and thats totally fine.
But lack of budget seems like a fairly poor excuse for something thats
"expected".

> I don't think our issue comes from not having enough F2F time. Our issue
> is that the design summit no longer reaches its objectives of aligning
> key contributors on a common plan, and we need to fix it.
>
>
> Why are design summits less productive that mid-cycle meetups those days
> ? Is it because there are too many non-contributors in the design summit
> rooms ? Is it the 40-min format ? Is it the distractions (having talks
> to give somewhere else, booths to attend, parties and dinners to be at)
> ? Is it that beginning of cycle is not the best moment ? Once we know
> WHY the design summit fails its main objective, maybe we can fix it.

What I remember about why we needed the mid-cycles:

In Hong Kong:
* we were missing some key people
* so the midcycle in the US was very useful to catch up those people
* but it was great to meet some new contributors

In Atlanta, although we have fairly good core attendance, but:
* done badly on tracking and following on what was discussed
* we had quite a few information and mentoring sessions, that were not
a great use of group time
* had some big debates that needed more time, but we didn't have any slack
* quite burnt out towards the end (after two previous days of ops and
cross project sessions)

> My gut feeling is that having a restricted audience and a smaller group
> lets people get to the bottom of an issue and reach consensus. And that
> you need at least half a day or a full day of open discussion to reach
> such alignment. And that it's not particularly great to get such
> alignment in the middle of the cycle, getting it at the start is still
> the right way to align with the release cycle.

It feels a bit exclusive. I think saying we prefer ATLs attending seems OK.

Maybe for Paris would could try out some of these things:

1) Get rid of sessions that can be replaced by the spec process:
* this was a popular idea at the mid-cycle
* Feature session, we should try write the spec first, to see if we
really need a session
* Also use the spec process to help mentor people
* maybe have more targeted face to face mentor meetings, where a
summit session is "wasteful"

2) Schedule an afternoon of "freestyle big picture debates" later in the week
* quite often come up with "but we must fix X first" discussions, can
follow through on those here
* maybe after lunch on the last day?
* doesn't mean we don't have other "big picture" sessions explicitly scheduled

3) Schedule a slot to discuss, and propose some release priorities
* it would be good to generate a release priority "statement" in the
last session
* sum up the key "big issues" that have come up and need resolving, etc

> If we manage to have alignment at the "design summit", then it doesn't
> spell the end of the mid-cycle things. But then, ideally the extra
> mid-cycle gatherings should be focused on getting specific stuff done,
> rather than general team alignment. Think workshop/hackathon rather than
> private gathering. The goal of the workshop would be published in
> advance, and people could opt to join that. It would be totally optional.

+1

Cheers,
John