[openstack-dev] [nova][core] Expectations of core reviewers

Joe Gordon joe.gordon0 at gmail.com
Thu Aug 21 22:53:42 UTC 2014


On Aug 20, 2014 10:56 AM, "John Garbutt" <john at johngarbutt.com> wrote:
>
> 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"

Yes!

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

Interesting idea, I like it.

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

++, although I think we need to have a draft of this list when planning the
summit to help pick what to talk about.

>
> > 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140821/bafcd2d2/attachment.html>


More information about the OpenStack-dev mailing list