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

2014-08-21 Thread Joe Gordon
On Aug 20, 2014 10:56 AM, John Garbutt j...@johngarbutt.com wrote:

 On 18 August 2014 11:18, Thierry Carrez thie...@openstack.org wrote:
  Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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

 

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

2014-08-20 Thread John Garbutt
On 18 August 2014 11:18, Thierry Carrez thie...@openstack.org wrote:
 Doug Hellmann wrote:
 On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-19 Thread Gary Kotton


From: Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com
Reply-To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Monday, August 18, 2014 at 9:31 PM
To: OpenStack List 
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Subject: Re: [openstack-dev] [nova][core] Expectations of core reviewers




On Mon, Aug 18, 2014 at 8:18 AM, Russell Bryant 
rbry...@redhat.commailto:rbry...@redhat.com wrote:
On 08/18/2014 06:18 AM, Thierry Carrez wrote:
 Doug Hellmann wrote:
 On Aug 13, 2014, at 4:42 PM, Russell Bryant 
 rbry...@redhat.commailto:rbry...@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 :)

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

 We established the design summit as the once-per-cycle opportunity to
 have face-to-face time and get alignment across the main contributors to
 a project. That used to be completely sufficient, but now it doesn't
 work as well... which resulted in alignment and team discussions to be
 discussed at mid-cycle meetups instead. Why ? And what could we change
 to have those alignment discussions at the design summit again ?

 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.

 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.

 Nothing prevents us from changing part of the design summit format (even
 the Paris one!), and restrict attendance to some of the sessions. And if
 the main issue is the distraction from the conference colocation, we
 might have to discuss the future of co-location again. In that 2 events
 per year objective, we could make the conference the optional cycle
 thing, and a developer-oriented specific event the mandatory one.

 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.

Great response ... I agree with everything you've said here.  Let's
figure out how to improve the design summit to better achieve team
alignment.

Of the things you mentioned, I think the biggest limit to alignment has
been the 40 minute format.  There are some topics that need more time.
It may be that we just need to take more advantage of the ability to
give a single topic multiple time slots to ensure enough time is
available.  As Dan discussed, there are some topics that we could stand
to turn down and distribute information another way that is just as
effective.

I would also say that the number of things going on at one time is also
problematic.  Not only are there several design summit sessions going
once, but there are conference sessions and customer meetings.  The
rapid rate of jumping around and context switching is exhausting.  It
also makes it a bit harder to get critical mass for an extended period
of time around a topic.  In mid-cycle

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

2014-08-19 Thread Avishay Traeger
I think to make the Summit sessions more effective:
1. The presenter to put in more effort beforehand - implement a rough POC,
write up a detailed etherpad, etc. where everything is ready say 2-3 weeks
before the Summit.  Maybe even require a reviewed spec for sessions which
introduce new features?
2. The active members of the project (core and otherwise) to put in more
effort beforehand - review the POC and/or etherpad, digest the information,
maybe even start a preliminary discussion on IRC to sharpen the proposal
3. Rather than the presenter giving a lecture and the project members
trying to digest what is being said, with no time to think of implications,
design options, etc., there should just be that debate to refine the idea
(I think this is what usually happens at the mid-cycle meetup).
4. Community members who did not do their homework should be discouraged
from actively participating in that session (i.e., asking basic questions
or taking the discussion on tangents).  Anyone who has questions or
off-topic comments can take it up with the presenter or anyone else during
the breaks.

Of course this requires a lot discipline on everyone's part, but I think it
would not only make the Summit sessions more valuable, but also help
developers who present to get their code in quicker and thereby help the
project to meet its objectives for that release.

Thanks,
Avishay


On Mon, Aug 18, 2014 at 6:40 PM, John Griffith john.griff...@solidfire.com
wrote:




 On Mon, Aug 18, 2014 at 9:18 AM, Russell Bryant rbry...@redhat.com
 wrote:

 On 08/18/2014 06:18 AM, Thierry Carrez wrote:
  Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)
 
  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 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.
 
  We established the design summit as the once-per-cycle opportunity to
  have face-to-face time and get alignment across the main contributors to
  a project. That used to be completely sufficient, but now it doesn't
  work as well... which resulted in alignment and team discussions to be
  discussed at mid-cycle meetups instead. Why ? And what could we change
  to have those alignment discussions at the design summit again ?
 
  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.
 
  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.
 
  Nothing prevents us from changing part of the design summit format (even
  the Paris one!), and restrict attendance to some of the sessions. And if
  the main issue is the distraction from the conference colocation, we
  might have to discuss the future of co-location again. In that 2 events
  per year objective, we could make the conference the optional cycle
  thing, and a developer-oriented specific event the mandatory one.
 
  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 

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

2014-08-18 Thread Thierry Carrez
Doug Hellmann wrote:
 On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)

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

We established the design summit as the once-per-cycle opportunity to
have face-to-face time and get alignment across the main contributors to
a project. That used to be completely sufficient, but now it doesn't
work as well... which resulted in alignment and team discussions to be
discussed at mid-cycle meetups instead. Why ? And what could we change
to have those alignment discussions at the design summit again ?

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.

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.

Nothing prevents us from changing part of the design summit format (even
the Paris one!), and restrict attendance to some of the sessions. And if
the main issue is the distraction from the conference colocation, we
might have to discuss the future of co-location again. In that 2 events
per year objective, we could make the conference the optional cycle
thing, and a developer-oriented specific event the mandatory one.

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.

Cheers,

-- 
Thierry Carrez (ttx)

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-18 Thread Daniel P. Berrange
On Mon, Aug 18, 2014 at 12:18:16PM +0200, Thierry Carrez wrote:
 Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)
 
 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 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.
 
 We established the design summit as the once-per-cycle opportunity to
 have face-to-face time and get alignment across the main contributors to
 a project. That used to be completely sufficient, but now it doesn't
 work as well... which resulted in alignment and team discussions to be
 discussed at mid-cycle meetups instead. Why ? And what could we change
 to have those alignment discussions at the design summit again ?
 
 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.

 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.
 
 Nothing prevents us from changing part of the design summit format (even
 the Paris one!), and restrict attendance to some of the sessions. And if
 the main issue is the distraction from the conference colocation, we
 might have to discuss the future of co-location again. In that 2 events
 per year objective, we could make the conference the optional cycle
 thing, and a developer-oriented specific event the mandatory one.
 
 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.

This pretty much all aligns with my thoughts on the matter. The key point
is that the design summit is the right place from a cycle timing POV to
have the critical f2f discussions  debates, and we need to figure out
what we can do to make it a more effective venue than it currently is.

IME I'd probably say the design summit sessions I've been to fall into
two broad camps. 

 - Information dissemination - just talk through proposal(s) to let
   everyone know what's being planned / thought. Some questions and
   debate, but mostly a one-way presentation.

 - Technical debates - the topic is just a high level hook, around
   which, a lively argument  debate was planned  took place. 

I think that the number of the information dissemination sessions could
be cut back on by encouraging people to take advantage of other equally
as effective methods of communication. In many cases it would suffice to
just have a more extensive blueprint / spec created, or a detailed wiki
page or similar doc to outline the problem space. If we had some regular
slot where people could do online presentations (Technical talks) that
could be a good way to push the information, out of band from the main
summits. If those online talks led to significant questions, then those
questions could then justify design summit sessions for f2f debate.

As an example, much as it is nice that we give every hypervisor driver
in Nova a slot at the design 

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

2014-08-18 Thread Salvatore Orlando
As the conversation has drifted away from a discussion pertaining the nova
core team, I have some comments inline as well.


On 18 August 2014 12:18, Thierry Carrez thie...@openstack.org wrote:

 Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)

 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 honestly think that it is simply not possible to require a minimum travel
from core team members.
This might sound naive, but I reckon the various core teams could just use
a bit of common sense here.
A core member that goes to every summit and meetup just for doing pub
crawling in yet another city is definetely less productive than another
team members which tries to collaborate remotely via
etherpad/IRC/gerrit/etc. (ok this example was a bit extreme but I hope it
clarifies my thoughts).



 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.


I totally agree on this point. I would be suprised if I were the first one
that in conversation (off and on the record) has mentioned that it is very
hard to achieve any form of consensus on anything at the design summit. And
it is pretty much impossible to move from a declarations of intent to the
definition of an architecture and/or actionable work items for the
subsequent release cycle.
Disclaimer: I spend 90% of my design summit time in the networking room, so
my judgment might be skewed.


 We established the design summit as the once-per-cycle opportunity to
 have face-to-face time and get alignment across the main contributors to
 a project. That used to be completely sufficient, but now it doesn't
 work as well... which resulted in alignment and team discussions to be
 discussed at mid-cycle meetups instead. Why ? And what could we change
 to have those alignment discussions at the design summit again ?


I suggested in the past to decouple the summit from the main conference.
This alone, in my opinion, would allow us to do the design summit at a
point where it's best for the upcoming release cycle, and reduce the
inevitable increased noise from rooms filled with over 150 people.



 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.


I think all of them apply and possibly other reasons, but probably we are a
going a bit off-topic.


 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.

 Nothing prevents us from changing part of the design summit format (even
 the Paris one!), and restrict attendance to some of the sessions. And if
 the main issue is the distraction from the conference colocation, we
 might have to discuss the future of co-location again. In that 2 events
 per year objective, we could make the conference the optional cycle
 thing, and a developer-oriented specific event the mandatory one.


While I agree that restricted attendance would increase productivity, it
might also be perceived as a barrier for new contributors and a reduction
of the overall democracy of the project. Maybe this could be achieved
naturally by decoupling conference and summit.



 If we manage to have alignment at the design summit, then it doesn't
 spell the end 

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

2014-08-18 Thread Sylvain Bauza
Le 18 août 2014 14:36, Salvatore Orlando sorla...@nicira.com a écrit :

 As the conversation has drifted away from a discussion pertaining the
nova core team, I have some comments inline as well.


 On 18 August 2014 12:18, Thierry Carrez thie...@openstack.org wrote:

 Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)

 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 honestly think that it is simply not possible to require a minimum
travel from core team members.
 This might sound naive, but I reckon the various core teams could just
use a bit of common sense here.
 A core member that goes to every summit and meetup just for doing pub
crawling in yet another city is definetely less productive than another
team members which tries to collaborate remotely via
etherpad/IRC/gerrit/etc. (ok this example was a bit extreme but I hope it
clarifies my thoughts).



 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.


 I totally agree on this point. I would be suprised if I were the first
one that in conversation (off and on the record) has mentioned that it is
very hard to achieve any form of consensus on anything at the design
summit. And it is pretty much impossible to move from a declarations of
intent to the definition of an architecture and/or actionable work items
for the subsequent release cycle.
 Disclaimer: I spend 90% of my design summit time in the networking room,
so my judgment might be skewed.


 We established the design summit as the once-per-cycle opportunity to
 have face-to-face time and get alignment across the main contributors to
 a project. That used to be completely sufficient, but now it doesn't
 work as well... which resulted in alignment and team discussions to be
 discussed at mid-cycle meetups instead. Why ? And what could we change
 to have those alignment discussions at the design summit again ?


 I suggested in the past to decouple the summit from the main conference.
 This alone, in my opinion, would allow us to do the design summit at a
point where it's best for the upcoming release cycle, and reduce the
inevitable increased noise from rooms filled with over 150 people.

Strong -1 here.
Having design sessions happening in the same time than conference is cool
for having :
- mixup of operators, developers and users in the same area, enjoying the
atmosphere, creating a same view and team spirit within Openstack
- newcomers able to join their first developers sessions (we lower the bar)
- same budget for contributors able to propose good proposals for regular
conference

I had the chance to attend both Icehouse and Juno summits. IIRC, Icehouse
design summit was restricted to ATCs while Juno one was open to everyone.
That thing plus the fact that the audio quality of the Juno sessions was
poor (cf. last design session about feedback) makes me think that the
problem is rather a problem of having good sessions than more an overall
problem.

I'm pro restricting access to only ATCs and impose access to rooms only
before the session starts, that would improve dramatically the quality
without sending a bad signal to the community that now design discussions
are a matter of only engineers.

-Sylvain




 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.


 I think all of them apply and possibly other reasons, but probably we are
a going a bit off-topic.


 My gut feeling is that having a restricted audience and a 

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

2014-08-18 Thread Russell Bryant
On 08/18/2014 06:18 AM, Thierry Carrez wrote:
 Doug Hellmann wrote:
 On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)
 
 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 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.
 
 We established the design summit as the once-per-cycle opportunity to
 have face-to-face time and get alignment across the main contributors to
 a project. That used to be completely sufficient, but now it doesn't
 work as well... which resulted in alignment and team discussions to be
 discussed at mid-cycle meetups instead. Why ? And what could we change
 to have those alignment discussions at the design summit again ?
 
 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.
 
 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.
 
 Nothing prevents us from changing part of the design summit format (even
 the Paris one!), and restrict attendance to some of the sessions. And if
 the main issue is the distraction from the conference colocation, we
 might have to discuss the future of co-location again. In that 2 events
 per year objective, we could make the conference the optional cycle
 thing, and a developer-oriented specific event the mandatory one.
 
 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.

Great response ... I agree with everything you've said here.  Let's
figure out how to improve the design summit to better achieve team
alignment.

Of the things you mentioned, I think the biggest limit to alignment has
been the 40 minute format.  There are some topics that need more time.
It may be that we just need to take more advantage of the ability to
give a single topic multiple time slots to ensure enough time is
available.  As Dan discussed, there are some topics that we could stand
to turn down and distribute information another way that is just as
effective.

I would also say that the number of things going on at one time is also
problematic.  Not only are there several design summit sessions going
once, but there are conference sessions and customer meetings.  The
rapid rate of jumping around and context switching is exhausting.  It
also makes it a bit harder to get critical mass for an extended period
of time around a topic.  In mid-cycle meetups, there is one track and no
other things competing for time and attention.

I don't have a good suggestion for fixing this issue with so many things
competing for time and attention.  I used to be a big proponent of
splitting the event out completely, but I don't feel the same way
anymore.  In theory we could call the conference the optional event, but
in practice it's going to be required for many folks anyway.  I can't
speak for everyone, but I suspect if you're a senior engineer at your

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

2014-08-18 Thread John Griffith
On Mon, Aug 18, 2014 at 9:18 AM, Russell Bryant rbry...@redhat.com wrote:

 On 08/18/2014 06:18 AM, Thierry Carrez wrote:
  Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)
 
  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 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.
 
  We established the design summit as the once-per-cycle opportunity to
  have face-to-face time and get alignment across the main contributors to
  a project. That used to be completely sufficient, but now it doesn't
  work as well... which resulted in alignment and team discussions to be
  discussed at mid-cycle meetups instead. Why ? And what could we change
  to have those alignment discussions at the design summit again ?
 
  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.
 
  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.
 
  Nothing prevents us from changing part of the design summit format (even
  the Paris one!), and restrict attendance to some of the sessions. And if
  the main issue is the distraction from the conference colocation, we
  might have to discuss the future of co-location again. In that 2 events
  per year objective, we could make the conference the optional cycle
  thing, and a developer-oriented specific event the mandatory one.
 
  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.

 Great response ... I agree with everything you've said here.  Let's
 figure out how to improve the design summit to better achieve team
 alignment.

 Of the things you mentioned, I think the biggest limit to alignment has
 been the 40 minute format.  There are some topics that need more time.
 It may be that we just need to take more advantage of the ability to
 give a single topic multiple time slots to ensure enough time is
 available.  As Dan discussed, there are some topics that we could stand
 to turn down and distribute information another way that is just as
 effective.

 I would also say that the number of things going on at one time is also
 problematic.  Not only are there several design summit sessions going
 once, but there are conference sessions and customer meetings.  The
 rapid rate of jumping around and context switching is exhausting.  It
 also makes it a bit harder to get critical mass for an extended period
 of time around a topic.  In mid-cycle meetups, there is one track and no
 other things competing for time and attention.

 I don't have a good suggestion for fixing this issue with so many things
 competing for time and attention.  I used to be a big proponent of
 splitting the event out completely, but I don't feel the same way
 anymore.  In theory we could call the conference the 

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

2014-08-18 Thread Daniel P. Berrange
On Mon, Aug 18, 2014 at 11:18:52AM -0400, Russell Bryant wrote:
 On 08/18/2014 06:18 AM, Thierry Carrez wrote:
  Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)
  
  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 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.
  
  We established the design summit as the once-per-cycle opportunity to
  have face-to-face time and get alignment across the main contributors to
  a project. That used to be completely sufficient, but now it doesn't
  work as well... which resulted in alignment and team discussions to be
  discussed at mid-cycle meetups instead. Why ? And what could we change
  to have those alignment discussions at the design summit again ?
  
  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.
  
  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.
  
  Nothing prevents us from changing part of the design summit format (even
  the Paris one!), and restrict attendance to some of the sessions. And if
  the main issue is the distraction from the conference colocation, we
  might have to discuss the future of co-location again. In that 2 events
  per year objective, we could make the conference the optional cycle
  thing, and a developer-oriented specific event the mandatory one.
  
  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.
 
 Great response ... I agree with everything you've said here.  Let's
 figure out how to improve the design summit to better achieve team
 alignment.
 
 Of the things you mentioned, I think the biggest limit to alignment has
 been the 40 minute format.  There are some topics that need more time.
 It may be that we just need to take more advantage of the ability to
 give a single topic multiple time slots to ensure enough time is
 available.  As Dan discussed, there are some topics that we could stand
 to turn down and distribute information another way that is just as
 effective.
 
 I would also say that the number of things going on at one time is also
 problematic.  Not only are there several design summit sessions going
 once, but there are conference sessions and customer meetings.  The
 rapid rate of jumping around and context switching is exhausting.  It
 also makes it a bit harder to get critical mass for an extended period
 of time around a topic.  In mid-cycle meetups, there is one track and no
 other things competing for time and attention.
 
 I don't have a good suggestion for fixing this issue with so many things
 competing for time and attention.  I used to be a big proponent of
 splitting the event out completely, but I don't feel the same way
 anymore.  In theory we could call the conference the optional 

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

2014-08-18 Thread Maru Newby

On Aug 14, 2014, at 8:52 AM, Russell Bryant rbry...@redhat.com wrote:

 On 08/14/2014 11:40 AM, David Kranz wrote:
 On 08/14/2014 10:54 AM, Matt Riedemann wrote:
 
 
 On 8/14/2014 3:47 AM, Daniel P. Berrange wrote:
 On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:
 On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote:
 I'm not questioning the value of f2f - I'm questioning the idea of
 doing f2f meetings sooo many times a year. OpenStack is very much
 the outlier here among open source projects - the vast majority of
 projects get along very well with much less f2f time and a far
 smaller % of their contributors attend those f2f meetings that do
 happen. So I really do question what is missing from OpenStack's
 community interaction that makes us believe that having 4 f2f
 meetings a year is critical to our success.
 
 How many is too many? So far, I have found the midcycles to be
 extremely
 productive -- productive in a way that we don't see at the summits,
 and
 I think other attendees agree. Obviously if budgets start limiting
 them,
 then we'll have to deal with it, but I don't want to stop meeting
 preemptively.
 
 I agree they're very productive. Let's pick on the nova v3 API case as
 an example... We had failed as a community to reach a consensus using
 our existing discussion mechanisms (hundreds of emails, at least three
 specs, phone calls between the various parties, et cetera), yet at the
 summit and then a midcycle meetup we managed to nail down an agreement
 on a very contentious and complicated topic.
 
 We thought we had agreement on v3 API after Atlanta f2f summit and
 after Hong Kong f2f too. So I wouldn't neccessarily say that we
 needed another f2f meeting to resolve that, but rather than this is
 a very complex topic that takes a long time to resolve no matter
 how we discuss it and the discussions had just happened to reach
 a natural conclusion this time around. But lets see if this agreement
 actually sticks this time
 
 I can see the argument that travel cost is an issue, but I think its
 also not a very strong argument. We have companies spending millions
 of dollars on OpenStack -- surely spending a relatively small amount
 on travel to keep the development team as efficient as possible isn't
 a big deal? I wouldn't be at all surprised if the financial costs of
 the v3 API debate (staff time mainly) were much higher than the travel
 costs of those involved in the summit and midcycle discussions which
 sorted it out.
 
 I think the travel cost really is a big issue. Due to the number of
 people who had to travel to the many mid-cycle meetups, a good number
 of people I work with no longer have the ability to go to the Paris
 design summit. This is going to make it harder for them to feel a
 proper engaged part of our community. I can only see this situation
 get worse over time if greater emphasis is placed on attending the
 mid-cycle meetups.
 
 Travelling to places to talk to people isn't a great solution, but it
 is the most effective one we've found so far. We should continue to
 experiment with other options, but until we find something that works
 as well as meetups, I think we need to keep having them.
 
 IMHO, the reasons to cut back would be:
 
 - People leaving with a well, that was useless... feeling
 - Not enough people able to travel to make it worthwhile
 
 So far, neither of those have been outcomes of the midcycles we've
 had,
 so I think we're doing okay.
 
 The design summits are structured differently, where we see a lot more
 diverse attendance because of the colocation with the user summit. It
 doesn't lend itself well to long and in-depth discussions about
 specific
 things, but it's very useful for what it gives us in the way of
 exposure. We could try to have less of that at the summit and more
 midcycle-ish time, but I think it's unlikely to achieve the same level
 of usefulness in that environment.
 
 Specifically, the lack of colocation with too many other projects has
 been a benefit. This time, Mark and Maru where there from Neutron.
 Last
 time, Mark from Neutron and the other Mark from Glance were there. If
 they were having meetups in other rooms (like at summit) they wouldn't
 have been there exposed to discussions that didn't seem like they'd
 have
 a component for their participation, but did after all (re: nova and
 glance and who should own flavors).
 
 I agree. The ability to focus on the issues that were blocking nova
 was very important. That's hard to do at a design summit when there is
 so much happening at the same time.
 
 Maybe we should change the way we structure the design summit to
 improve that. If there are critical issues blocking nova, it feels
 like it is better to be able to discuss and resolve as much as possible
 at the start of the dev cycle rather than in the middle of the dev
 cycle because I feel that means we are causing ourselves pain during
 milestone 1/2.
 
 Just speaking from 

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

2014-08-18 Thread Maru Newby

On Aug 13, 2014, at 10:32 PM, Michael Still mi...@stillhq.com wrote:

 On Thu, Aug 14, 2014 at 2:48 PM, Joe Gordon joe.gord...@gmail.com wrote:
 On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com wrote:
 On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:
 
 Just wanted to quickly weigh in with my thoughts on this important
 topic. I
 very much valued the face-to-face interaction that came from the
 mid-cycle
 meetup in Beaverton (it was the only one I've ever been to).
 
 That said, I do not believe it should be a requirement that cores make
 it to
 the face-to-face meetings in-person. A number of folks have brought up
 very
 valid concerns about personal/family time, travel costs and burnout.
 
 I'm not proposing they be a requirement. I am proposing that they be
 strongly encouraged.
 
 I believe that the issue raised about furthering the divide between core
 and
 non-core folks is actually the biggest reason I don't support a mandate
 to
 have cores at the face-to-face meetings, and I think we should make our
 best
 efforts to support quality virtual meetings that can be done on a more
 frequent basis than the face-to-face meetings that would be optional.
 
 I am all for online meetings, but we don't have a practical way to do
 them at the moment apart from IRC. Until someone has a concrete
 proposal that's been shown to work, I feel its a straw man argument.
 
 What about making it easier for remote people to participate at the
 mid-cycle meetups? Set up some microphones and a Google hangout?  At least
 that way attending the mid-cycle is not all or nothing.
 
 We did something like this last cycle (IIRC we didn't have enough mics) and
 it worked pretty well.
 
 As I said, I'm open to experimenting, but I need someone other than me
 to own that. I'm simply too busy to get to it.
 
 However, I don't think we should throw away the thing that works for
 best for us now, until we have a working replacement. I'm very much in
 favour of work being done on a replacement though.

+1

I agree that that mid-cycles may not be sustainable over the long-term due to 
issues of travel cost (financial and otherwise) and a lack of inclusiveness, 
but I don't think they should stop happening until a suitably productive 
alternative has been found.


Maru



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-18 Thread Joe Gordon
On Mon, Aug 18, 2014 at 3:18 AM, Thierry Carrez thie...@openstack.org
wrote:

 Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)

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

 We established the design summit as the once-per-cycle opportunity to
 have face-to-face time and get alignment across the main contributors to
 a project. That used to be completely sufficient, but now it doesn't
 work as well... which resulted in alignment and team discussions to be
 discussed at mid-cycle meetups instead. Why ? And what could we change
 to have those alignment discussions at the design summit again ?

 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.


For my self, the issue with the design summits have been around the
duration and the number of sessions that I would like to attend that are
scheduled at the same time. I have rarely seen the issue be too many
non-contributors in the room, if they don't have anything to add they
usually just listen. The 40 minute format is a bit too restrictive, but if
all design summit tracks dropped the 40-min format it would be even harder
for me to attend sessions across tracks, one of the main benefits of the
design summit IMHO.


 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.

 Nothing prevents us from changing part of the design summit format (even
 the Paris one!), and restrict attendance to some of the sessions. And if
 the main issue is the distraction from the conference colocation, we
 might have to discuss the future of co-location again. In that 2 events
 per year objective, we could make the conference the optional cycle
 thing, and a developer-oriented specific event the mandatory one.

 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.

 Cheers,

 --
 Thierry Carrez (ttx)

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-18 Thread Joe Gordon
On Mon, Aug 18, 2014 at 8:18 AM, Russell Bryant rbry...@redhat.com wrote:

 On 08/18/2014 06:18 AM, Thierry Carrez wrote:
  Doug Hellmann wrote:
  On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)
 
  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 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.
 
  We established the design summit as the once-per-cycle opportunity to
  have face-to-face time and get alignment across the main contributors to
  a project. That used to be completely sufficient, but now it doesn't
  work as well... which resulted in alignment and team discussions to be
  discussed at mid-cycle meetups instead. Why ? And what could we change
  to have those alignment discussions at the design summit again ?
 
  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.
 
  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.
 
  Nothing prevents us from changing part of the design summit format (even
  the Paris one!), and restrict attendance to some of the sessions. And if
  the main issue is the distraction from the conference colocation, we
  might have to discuss the future of co-location again. In that 2 events
  per year objective, we could make the conference the optional cycle
  thing, and a developer-oriented specific event the mandatory one.
 
  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.

 Great response ... I agree with everything you've said here.  Let's
 figure out how to improve the design summit to better achieve team
 alignment.

 Of the things you mentioned, I think the biggest limit to alignment has
 been the 40 minute format.  There are some topics that need more time.
 It may be that we just need to take more advantage of the ability to
 give a single topic multiple time slots to ensure enough time is
 available.  As Dan discussed, there are some topics that we could stand
 to turn down and distribute information another way that is just as
 effective.

 I would also say that the number of things going on at one time is also
 problematic.  Not only are there several design summit sessions going
 once, but there are conference sessions and customer meetings.  The
 rapid rate of jumping around and context switching is exhausting.  It
 also makes it a bit harder to get critical mass for an extended period
 of time around a topic.  In mid-cycle meetups, there is one track and no
 other things competing for time and attention.

 I don't have a good suggestion for fixing this issue with so many things
 competing for time and attention.  I used to be a big proponent of
 splitting the event out completely, but I don't feel the same way
 anymore.  In theory we could call the conference the 

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

2014-08-18 Thread Joe Gordon
On Mon, Aug 18, 2014 at 5:22 AM, Daniel P. Berrange berra...@redhat.com
wrote:

 On Mon, Aug 18, 2014 at 12:18:16PM +0200, Thierry Carrez wrote:
  Doug Hellmann wrote:
   On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@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 :)
 
  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 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.
 
  We established the design summit as the once-per-cycle opportunity to
  have face-to-face time and get alignment across the main contributors to
  a project. That used to be completely sufficient, but now it doesn't
  work as well... which resulted in alignment and team discussions to be
  discussed at mid-cycle meetups instead. Why ? And what could we change
  to have those alignment discussions at the design summit again ?
 
  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.
 
  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.
 
  Nothing prevents us from changing part of the design summit format (even
  the Paris one!), and restrict attendance to some of the sessions. And if
  the main issue is the distraction from the conference colocation, we
  might have to discuss the future of co-location again. In that 2 events
  per year objective, we could make the conference the optional cycle
  thing, and a developer-oriented specific event the mandatory one.
 
  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.

 This pretty much all aligns with my thoughts on the matter. The key point
 is that the design summit is the right place from a cycle timing POV to
 have the critical f2f discussions  debates, and we need to figure out
 what we can do to make it a more effective venue than it currently is.

 IME I'd probably say the design summit sessions I've been to fall into
 two broad camps.

  - Information dissemination - just talk through proposal(s) to let
everyone know what's being planned / thought. Some questions and
debate, but mostly a one-way presentation.

  - Technical debates - the topic is just a high level hook, around
which, a lively argument  debate was planned  took place.

 I think that the number of the information dissemination sessions could
 be cut back on by encouraging people to take advantage of other equally
 as effective methods of communication. In many cases it would suffice to
 just have a more extensive blueprint / spec created, or a detailed wiki
 page or similar doc to outline the problem space. If we had some regular
 slot where people could do online presentations (Technical talks) that
 could be a good way to push the information, out of band from the main
 summits. If those online talks led to significant questions, then those
 questions 

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

2014-08-15 Thread Chris Jones
Hi

 On 14 Aug 2014, at 19:48, Dugger, Donald D donald.d.dug...@intel.com wrote:
 
 My experience with mics, no matter how good, In conference rooms is not good. 

+1

The ubuntu dev summits went through several iterations of trying to make remote 
participation effective, and I don't think we ever achieved it.

I think the reality that needs to be accepted is that not every IRL 
conversation is going to be accessible to everyone who wants to take part (even 
if you have superb remote access, maybe some particular discussion is happening 
at 3am in some developer's timezone).

I think we should be ok with that. So long as a quorum of cores can be present 
at any given event, progress can be made.

Cheers,
Chris

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-15 Thread Sandy Walsh
Maybe we need to think about this from a distributed software perspective?

* Divide and Conquer? 

Can we split the topics to create more manageable sub-groups? This way it's not 
core-vs-non-core but intererested-vs-moderately-interested.  (of course, this 
is much the way the mailing list works). Perhaps OnAir would work well for that?

How about geographic separation? Meetings per time-zone that roll up into 
larger meetings (see More Workers below). This is much the same way the 
regional openstack meetups work, but with specific topics. 

Of course, then we get replication latency :)

* More workers?

Can we assign topic owners? Cores might delegate a topic to a non-core member 
to gather consensus, concerns, suggestions and summarize the result to present 
during weekly IRC meetings.

*  Better threading?

Are there other tools than mailing lists for talking about these topics? Would 
mind-mapping software [1] work better for keeping the threads manageable? 

-Sandy
[1] http://en.wikipedia.org/wiki/Mind_map
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-15 Thread Jeremy Stanley
On 2014-08-14 09:33:20 -0400 (-0400), Russell Bryant wrote:
[...]
 Another issue is that some folks are just fundamentally opposed to
 using Google
[...]

I think that's a shallow depiction of the issue. I'm sure *some*
people really do just avoid Google specifically, but a bigger
concern should be around the statement our use of those services
presents to the rest of the World. By using commercial solutions
because the open alternatives aren't as useful/featureful/stable, we
rob those projects of a potential larger user community which could
help them achieve greater momentum and eventually dominate their
respective technologies.

Would we, as a community, rather see OpenStack used in production
and improved when it has bugs/lacks features? Or should users just
view it as a cheap lab platform instead, and then pay for solid
proprietary solutions to their production needs? I'm glad a lot of
people think using and improving OpenStack, even when there might
sometimes be easier/simpler closed alternatives, is worth the
long-term investment.

We, as visible leaders among the greater free software community,
should think very hard when making the choice not to extend this
same courtesy and consideration to other projects who may lack our
extraordinary base of resources. Through our example as a project,
we have the potential to improve things for open/free software
communities far beyond our own.

Of course I'm not a nova core reviewer and have never attended a
nova mid-cycle meetup, so I really have no say in how you conduct
your remote participation. But I do hope you'll consider,
collectively, that focusing on immediate convenience for your own
community can have negative longer-term consequences as you (whether
consciously or not) promote the use of proprietary solutions to your
needs rather than embracing less convenient free and open options
which may still require improvement.
-- 
Jeremy Stanley

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-15 Thread John Griffith
On Fri, Aug 15, 2014 at 8:20 AM, Jeremy Stanley fu...@yuggoth.org wrote:

 On 2014-08-14 09:33:20 -0400 (-0400), Russell Bryant wrote:
 [...]
  Another issue is that some folks are just fundamentally opposed to
  using Google
 [...]

 I think that's a shallow depiction of the issue. I'm sure *some*
 people really do just avoid Google specifically, but a bigger
 concern should be around the statement our use of those services
 presents to the rest of the World. By using commercial solutions
 because the open alternatives aren't as useful/featureful/stable, we
 rob those projects of a potential larger user community which could
 help them achieve greater momentum and eventually dominate their
 respective technologies.

 Would we, as a community, rather see OpenStack used in production
 and improved when it has bugs/lacks features? Or should users just
 view it as a cheap lab platform instead, and then pay for solid
 proprietary solutions to their production needs? I'm glad a lot of
 people think using and improving OpenStack, even when there might
 sometimes be easier/simpler closed alternatives, is worth the
 long-term investment.

 We, as visible leaders among the greater free software community,
 should think very hard when making the choice not to extend this
 same courtesy and consideration to other projects who may lack our
 extraordinary base of resources. Through our example as a project,
 we have the potential to improve things for open/free software
 communities far beyond our own.

 Of course I'm not a nova core reviewer and have never attended a
 nova mid-cycle meetup, so I really have no say in how you conduct
 your remote participation. But I do hope you'll consider,
 collectively, that focusing on immediate convenience for your own
 community can have negative longer-term consequences as you (whether
 consciously or not) promote the use of proprietary solutions to your
 needs rather than embracing less convenient free and open options
 which may still require improvement.
 --
 Jeremy Stanley

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


​Lots of stuff here, good points, bad points etc.

I just want to take the opportunity to state that I have ZERO intention of
ever pushing that if you're on core you must travel anywhere.  I think
it's completely alienating and unfair and frankly kinda surprised it was
actually raised.

For anybody that contributes, works hard and gives great reviews but can't
travel to the various Nova events around the world, feel free to check out
Cinder.  We don't care if you meet us in person and we love good
contributors regardless of where they live etc.

I could insert snarky comment about unable to work remotely using
technology and maybe should choose another project or career here but I
won't. ​
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-15 Thread Duncan Thomas
I've literally just finished the Cinder mid-cycle meetup (I'm still in
my hotel room), and the value was huge and undeniable.

Reading through this thread, I've just realised one massive advantage
of the mid-cycle meetup that improved our productivity massively: it
is in the middle of a cycle. We have actual implementations of the
things we are discussing, which is something we rarely have at the
summit - the sessions there are much more hand-waving and
aspirational. In the meetup we effectively treated the post-summit
work as a throw away prototype and redesigned things having learn
lessons. This is obvious unfortunate for the people who put the effort
into the code, but has I think let to a far better end result. I think
that requiring, or at least giving preferences to proposals that have
a working PoC before the summit might improve out productivity in a
similar way. Certainly worth thinking about...

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Daniel P. Berrange
On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:
 On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote:
  I'm not questioning the value of f2f - I'm questioning the idea of
  doing f2f meetings sooo many times a year. OpenStack is very much
  the outlier here among open source projects - the vast majority of
  projects get along very well with much less f2f time and a far
  smaller % of their contributors attend those f2f meetings that do
  happen. So I really do question what is missing from OpenStack's
  community interaction that makes us believe that having 4 f2f
  meetings a year is critical to our success.
 
  How many is too many? So far, I have found the midcycles to be extremely
  productive -- productive in a way that we don't see at the summits, and
  I think other attendees agree. Obviously if budgets start limiting them,
  then we'll have to deal with it, but I don't want to stop meeting
  preemptively.
 
 I agree they're very productive. Let's pick on the nova v3 API case as
 an example... We had failed as a community to reach a consensus using
 our existing discussion mechanisms (hundreds of emails, at least three
 specs, phone calls between the various parties, et cetera), yet at the
 summit and then a midcycle meetup we managed to nail down an agreement
 on a very contentious and complicated topic.

We thought we had agreement on v3 API after Atlanta f2f summit and 
after Hong Kong f2f too. So I wouldn't neccessarily say that we
needed another f2f meeting to resolve that, but rather than this is
a very complex topic that takes a long time to resolve no matter
how we discuss it and the discussions had just happened to reach
a natural conclusion this time around. But lets see if this agreement
actually sticks this time

 I can see the argument that travel cost is an issue, but I think its
 also not a very strong argument. We have companies spending millions
 of dollars on OpenStack -- surely spending a relatively small amount
 on travel to keep the development team as efficient as possible isn't
 a big deal? I wouldn't be at all surprised if the financial costs of
 the v3 API debate (staff time mainly) were much higher than the travel
 costs of those involved in the summit and midcycle discussions which
 sorted it out.

I think the travel cost really is a big issue. Due to the number of
people who had to travel to the many mid-cycle meetups, a good number
of people I work with no longer have the ability to go to the Paris
design summit. This is going to make it harder for them to feel a
proper engaged part of our community. I can only see this situation
get worse over time if greater emphasis is placed on attending the
mid-cycle meetups.

 Travelling to places to talk to people isn't a great solution, but it
 is the most effective one we've found so far. We should continue to
 experiment with other options, but until we find something that works
 as well as meetups, I think we need to keep having them.
 
  IMHO, the reasons to cut back would be:
 
  - People leaving with a well, that was useless... feeling
  - Not enough people able to travel to make it worthwhile
 
  So far, neither of those have been outcomes of the midcycles we've had,
  so I think we're doing okay.
 
  The design summits are structured differently, where we see a lot more
  diverse attendance because of the colocation with the user summit. It
  doesn't lend itself well to long and in-depth discussions about specific
  things, but it's very useful for what it gives us in the way of
  exposure. We could try to have less of that at the summit and more
  midcycle-ish time, but I think it's unlikely to achieve the same level
  of usefulness in that environment.
 
  Specifically, the lack of colocation with too many other projects has
  been a benefit. This time, Mark and Maru where there from Neutron. Last
  time, Mark from Neutron and the other Mark from Glance were there. If
  they were having meetups in other rooms (like at summit) they wouldn't
  have been there exposed to discussions that didn't seem like they'd have
  a component for their participation, but did after all (re: nova and
  glance and who should own flavors).
 
 I agree. The ability to focus on the issues that were blocking nova
 was very important. That's hard to do at a design summit when there is
 so much happening at the same time.

Maybe we should change the way we structure the design summit to
improve that. If there are critical issues blocking nova, it feels
like it is better to be able to discuss and resolve as much as possible
at the start of the dev cycle rather than in the middle of the dev
cycle because I feel that means we are causing ourselves pain during
milestone 1/2.

  As I explain in the rest of my email below I'm not advocating
  getting rid of mid-cycle events entirely. I'm suggesting that
  we can attain a reasonable % of the benefits of f2f meetings
  by doing more formal virtual meetups and so be 

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

2014-08-14 Thread Russell Bryant
On 08/13/2014 07:27 PM, Michael Still wrote:
 On Thu, Aug 14, 2014 at 3:44 AM, Russell Bryant rbry...@redhat.com wrote:
 On 08/13/2014 01:09 PM, Dan Smith wrote:
 Expecting cores to be at these sorts of things seems pretty reasonable
 to me, given the usefulness (and gravity) of the discussions we've been
 having so far. Companies with more cores will have to send more or make
 some hard decisions, but I don't want to cut back on the meetings until
 their value becomes unjustified.

 I disagree.  IMO, *expecting* people to travel, potentially across the
 globe, 4 times a year is an unreasonable expectation, and quite
 uncharacteristic of open source projects.  If we can't figure out a way
 to have the most important conversations in a way that is inclusive of
 everyone, we're failing with our processes.
 
 I am a bit confused by this stance to be honest. You yourself said
 when you were Icehouse PTL that you wanted cores to come to the
 summit. What changed?

Yes, I would love for core team members to come to the design summit
that's twice a year.  I still don't *expect* it for them to remain a
member of the team, and I certainly don't expect it 4 times a year.
It's a matter of frequency and requirement.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Russell Bryant
On 08/13/2014 11:31 PM, Michael Still wrote:
 On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:
 
 Just wanted to quickly weigh in with my thoughts on this important topic. I
 very much valued the face-to-face interaction that came from the mid-cycle
 meetup in Beaverton (it was the only one I've ever been to).

 That said, I do not believe it should be a requirement that cores make it to
 the face-to-face meetings in-person. A number of folks have brought up very
 valid concerns about personal/family time, travel costs and burnout.
 
 I'm not proposing they be a requirement. I am proposing that they be
 strongly encouraged.

I'm not sure that's much different in reality.

 I believe that the issue raised about furthering the divide between core and
 non-core folks is actually the biggest reason I don't support a mandate to
 have cores at the face-to-face meetings, and I think we should make our best
 efforts to support quality virtual meetings that can be done on a more
 frequent basis than the face-to-face meetings that would be optional.
 
 I am all for online meetings, but we don't have a practical way to do
 them at the moment apart from IRC. Until someone has a concrete
 proposal that's been shown to work, I feel its a straw man argument.

Yes, IRC is one option which we already use on a regular basis.  We can
also switch to voice communication for higher bandwidth when needed.  We
even have a conferencing server set up in OpenStack's infrastructure:

https://wiki.openstack.org/wiki/Infrastructure/Conferencing

In theory it even supports basic video conferencing, though I haven't
tested it on this server yet.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Russell Bryant
On 08/13/2014 07:27 PM, Michael Still wrote:
 The etherpad for the meetup has extensive notes. Any summary I write
 will basically be those notes in prose. What are you looking for in a
 summary that isn't in the etherpad? There also wasn't a summary of the
 Icehouse midcycle produced that I can find. Whilst I am happy to do
 one for Juno, its a requirement that I hadn't planned for, and is
 therefore taking me some time to retrofit.
 
 I think we should chalk the request for summaries up experience and
 talk through how to better provide such things at future meetups.

The summary from the Icehouse meetup is here:

http://lists.openstack.org/pipermail/openstack-dev/2014-February/027370.html

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Daniel P. Berrange
On Thu, Aug 14, 2014 at 08:31:48AM -0400, Russell Bryant wrote:
 On 08/13/2014 11:31 PM, Michael Still wrote:
  On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:
  
  Just wanted to quickly weigh in with my thoughts on this important topic. I
  very much valued the face-to-face interaction that came from the mid-cycle
  meetup in Beaverton (it was the only one I've ever been to).
 
  That said, I do not believe it should be a requirement that cores make it 
  to
  the face-to-face meetings in-person. A number of folks have brought up very
  valid concerns about personal/family time, travel costs and burnout.
  
  I'm not proposing they be a requirement. I am proposing that they be
  strongly encouraged.
 
 I'm not sure that's much different in reality.
 
  I believe that the issue raised about furthering the divide between core 
  and
  non-core folks is actually the biggest reason I don't support a mandate to
  have cores at the face-to-face meetings, and I think we should make our 
  best
  efforts to support quality virtual meetings that can be done on a more
  frequent basis than the face-to-face meetings that would be optional.
  
  I am all for online meetings, but we don't have a practical way to do
  them at the moment apart from IRC. Until someone has a concrete
  proposal that's been shown to work, I feel its a straw man argument.
 
 Yes, IRC is one option which we already use on a regular basis.  We can
 also switch to voice communication for higher bandwidth when needed.  We
 even have a conferencing server set up in OpenStack's infrastructure:
 
 https://wiki.openstack.org/wiki/Infrastructure/Conferencing
 
 In theory it even supports basic video conferencing, though I haven't
 tested it on this server yet.

Depending on the usage needs, I think Google hangouts is a quite useful
technology. For many-to-many session its limit of 10 participants can be
an issue, but for a few-to-many broadcast it could be practical. What I
find particularly appealing is the way it can live stream the session
over youtube which allows for unlimited number of viewers, as well as
being available offline for later catchup.

It could be useful in cases where one (or a handful) of people want to
present an idea / topic visually with slides / screencasts / etc and
then let the broader interactive discussion take place on IRC / mailing
list afterwards. I could see this being something that might let people
present proposals for new Nova features without having to wait (+try for
a limited) design summit slot in the 6 month cycle. One of the issues
I feel with the design summit is that it was the first time hearing about
many of the ideas, so there was not enough time to disgest the proposal
and so some of the thorny things to discuss only come to mind afterwards.
If we had to a approach for promoting features  knowledge in this way the
design summit could have more time to focus on areas of debate where the
f2f prescence is most valuable.

Regards,
Daniel
-- 
|: http://berrange.com  -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org  -o- http://virt-manager.org :|
|: http://autobuild.org   -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org   -o-   http://live.gnome.org/gtk-vnc :|

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread CARVER, PAUL
Daniel P. Berrange [mailto:berra...@redhat.com] wrote:

Depending on the usage needs, I think Google hangouts is a quite useful
technology. For many-to-many session its limit of 10 participants can be
an issue, but for a few-to-many broadcast it could be practical. What I
find particularly appealing is the way it can live stream the session
over youtube which allows for unlimited number of viewers, as well as
being available offline for later catchup.

I can't actually offer ATT resources without getting some level of
management approval first, but just for the sake of discussion here's
some info about the telepresence system we use.

-=-=-=-=-=-=-=-=-=-
ATS B2B Telepresence conferences can be conducted with an external company's
Telepresence room(s), which subscribe to the ATT Telepresence Solution,
or a limited number of other Telepresence service provider's networks.

Currently, the number of Telepresence rooms that can participate in a B2B
conference is limited to a combined total of 20 rooms (19 of which can be
ATT rooms, depending on the number of remote endpoints included).
-=-=-=-=-=-=-=-=-=-

We currently have B2B interconnect with over 100 companies and ATT has
telepresence rooms in many of our locations around the US and around
the world. If other large OpenStack companies also have telepresence
rooms that we could interconnect with I think it might be possible
to get management agreement to hold a couple OpenStack meetups per
year.

Most of our rooms are best suited for 6 people, but I know of at least
one 18 person telepresence room near me.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Russell Bryant
On 08/14/2014 10:04 AM, CARVER, PAUL wrote:
 Daniel P. Berrange [mailto:berra...@redhat.com] wrote:
 
 Depending on the usage needs, I think Google hangouts is a quite useful
 technology. For many-to-many session its limit of 10 participants can be
 an issue, but for a few-to-many broadcast it could be practical. What I
 find particularly appealing is the way it can live stream the session
 over youtube which allows for unlimited number of viewers, as well as
 being available offline for later catchup.
 
 I can't actually offer ATT resources without getting some level of
 management approval first, but just for the sake of discussion here's
 some info about the telepresence system we use.
 
 -=-=-=-=-=-=-=-=-=-
 ATS B2B Telepresence conferences can be conducted with an external company's
 Telepresence room(s), which subscribe to the ATT Telepresence Solution,
 or a limited number of other Telepresence service provider's networks.
 
 Currently, the number of Telepresence rooms that can participate in a B2B
 conference is limited to a combined total of 20 rooms (19 of which can be
 ATT rooms, depending on the number of remote endpoints included).
 -=-=-=-=-=-=-=-=-=-
 
 We currently have B2B interconnect with over 100 companies and ATT has
 telepresence rooms in many of our locations around the US and around
 the world. If other large OpenStack companies also have telepresence
 rooms that we could interconnect with I think it might be possible
 to get management agreement to hold a couple OpenStack meetups per
 year.
 
 Most of our rooms are best suited for 6 people, but I know of at least
 one 18 person telepresence room near me.

An ideal solution would allow attendees to join as individuals from
anywhere.  A lot of contributors work from home.  Is that sort of thing
compatible with your system?

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Matt Riedemann



On 8/14/2014 3:47 AM, Daniel P. Berrange wrote:

On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:

On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote:

I'm not questioning the value of f2f - I'm questioning the idea of
doing f2f meetings sooo many times a year. OpenStack is very much
the outlier here among open source projects - the vast majority of
projects get along very well with much less f2f time and a far
smaller % of their contributors attend those f2f meetings that do
happen. So I really do question what is missing from OpenStack's
community interaction that makes us believe that having 4 f2f
meetings a year is critical to our success.


How many is too many? So far, I have found the midcycles to be extremely
productive -- productive in a way that we don't see at the summits, and
I think other attendees agree. Obviously if budgets start limiting them,
then we'll have to deal with it, but I don't want to stop meeting
preemptively.


I agree they're very productive. Let's pick on the nova v3 API case as
an example... We had failed as a community to reach a consensus using
our existing discussion mechanisms (hundreds of emails, at least three
specs, phone calls between the various parties, et cetera), yet at the
summit and then a midcycle meetup we managed to nail down an agreement
on a very contentious and complicated topic.


We thought we had agreement on v3 API after Atlanta f2f summit and
after Hong Kong f2f too. So I wouldn't neccessarily say that we
needed another f2f meeting to resolve that, but rather than this is
a very complex topic that takes a long time to resolve no matter
how we discuss it and the discussions had just happened to reach
a natural conclusion this time around. But lets see if this agreement
actually sticks this time


I can see the argument that travel cost is an issue, but I think its
also not a very strong argument. We have companies spending millions
of dollars on OpenStack -- surely spending a relatively small amount
on travel to keep the development team as efficient as possible isn't
a big deal? I wouldn't be at all surprised if the financial costs of
the v3 API debate (staff time mainly) were much higher than the travel
costs of those involved in the summit and midcycle discussions which
sorted it out.


I think the travel cost really is a big issue. Due to the number of
people who had to travel to the many mid-cycle meetups, a good number
of people I work with no longer have the ability to go to the Paris
design summit. This is going to make it harder for them to feel a
proper engaged part of our community. I can only see this situation
get worse over time if greater emphasis is placed on attending the
mid-cycle meetups.


Travelling to places to talk to people isn't a great solution, but it
is the most effective one we've found so far. We should continue to
experiment with other options, but until we find something that works
as well as meetups, I think we need to keep having them.


IMHO, the reasons to cut back would be:

- People leaving with a well, that was useless... feeling
- Not enough people able to travel to make it worthwhile

So far, neither of those have been outcomes of the midcycles we've had,
so I think we're doing okay.

The design summits are structured differently, where we see a lot more
diverse attendance because of the colocation with the user summit. It
doesn't lend itself well to long and in-depth discussions about specific
things, but it's very useful for what it gives us in the way of
exposure. We could try to have less of that at the summit and more
midcycle-ish time, but I think it's unlikely to achieve the same level
of usefulness in that environment.

Specifically, the lack of colocation with too many other projects has
been a benefit. This time, Mark and Maru where there from Neutron. Last
time, Mark from Neutron and the other Mark from Glance were there. If
they were having meetups in other rooms (like at summit) they wouldn't
have been there exposed to discussions that didn't seem like they'd have
a component for their participation, but did after all (re: nova and
glance and who should own flavors).


I agree. The ability to focus on the issues that were blocking nova
was very important. That's hard to do at a design summit when there is
so much happening at the same time.


Maybe we should change the way we structure the design summit to
improve that. If there are critical issues blocking nova, it feels
like it is better to be able to discuss and resolve as much as possible
at the start of the dev cycle rather than in the middle of the dev
cycle because I feel that means we are causing ourselves pain during
milestone 1/2.


Just speaking from experience, I attended the Icehouse meetup before my 
first summit (Juno in ATL) and the design summit sessions for Juno were 
a big disappointment after the meetup sessions, basically because of the 
time constraints. The meetups are nice since there 

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

2014-08-14 Thread Sandy Walsh
On 8/14/2014 11:28 AM, Russell Bryant wrote:
 On 08/14/2014 10:04 AM, CARVER, PAUL wrote:
 Daniel P. Berrange [mailto:berra...@redhat.com] wrote:

 Depending on the usage needs, I think Google hangouts is a quite useful
 technology. For many-to-many session its limit of 10 participants can be
 an issue, but for a few-to-many broadcast it could be practical. What I
 find particularly appealing is the way it can live stream the session
 over youtube which allows for unlimited number of viewers, as well as
 being available offline for later catchup.
 I can't actually offer ATT resources without getting some level of
 management approval first, but just for the sake of discussion here's
 some info about the telepresence system we use.

 -=-=-=-=-=-=-=-=-=-
 ATS B2B Telepresence conferences can be conducted with an external company's
 Telepresence room(s), which subscribe to the ATT Telepresence Solution,
 or a limited number of other Telepresence service provider's networks.

 Currently, the number of Telepresence rooms that can participate in a B2B
 conference is limited to a combined total of 20 rooms (19 of which can be
 ATT rooms, depending on the number of remote endpoints included).
 -=-=-=-=-=-=-=-=-=-

 We currently have B2B interconnect with over 100 companies and ATT has
 telepresence rooms in many of our locations around the US and around
 the world. If other large OpenStack companies also have telepresence
 rooms that we could interconnect with I think it might be possible
 to get management agreement to hold a couple OpenStack meetups per
 year.

 Most of our rooms are best suited for 6 people, but I know of at least
 one 18 person telepresence room near me.
 An ideal solution would allow attendees to join as individuals from
 anywhere.  A lot of contributors work from home.  Is that sort of thing
 compatible with your system?

http://bluejeans.com/ was a good experience.

What about Google Hangout OnAir for the PTL and core, while others are
view-only with chat/irc questions?

http://www.google.com/+/learnmore/hangouts/onair.html



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Anne Gentle
On Thu, Aug 14, 2014 at 10:13 AM, Sandy Walsh sandy.wa...@rackspace.com
wrote:

 On 8/14/2014 11:28 AM, Russell Bryant wrote:
  On 08/14/2014 10:04 AM, CARVER, PAUL wrote:
  Daniel P. Berrange [mailto:berra...@redhat.com] wrote:
 
  Depending on the usage needs, I think Google hangouts is a quite useful
  technology. For many-to-many session its limit of 10 participants can
 be
  an issue, but for a few-to-many broadcast it could be practical. What I
  find particularly appealing is the way it can live stream the session
  over youtube which allows for unlimited number of viewers, as well as
  being available offline for later catchup.
  I can't actually offer ATT resources without getting some level of
  management approval first, but just for the sake of discussion here's
  some info about the telepresence system we use.
 
  -=-=-=-=-=-=-=-=-=-
  ATS B2B Telepresence conferences can be conducted with an external
 company's
  Telepresence room(s), which subscribe to the ATT Telepresence Solution,
  or a limited number of other Telepresence service provider's networks.
 
  Currently, the number of Telepresence rooms that can participate in a
 B2B
  conference is limited to a combined total of 20 rooms (19 of which can
 be
  ATT rooms, depending on the number of remote endpoints included).
  -=-=-=-=-=-=-=-=-=-
 
  We currently have B2B interconnect with over 100 companies and ATT has
  telepresence rooms in many of our locations around the US and around
  the world. If other large OpenStack companies also have telepresence
  rooms that we could interconnect with I think it might be possible
  to get management agreement to hold a couple OpenStack meetups per
  year.
 
  Most of our rooms are best suited for 6 people, but I know of at least
  one 18 person telepresence room near me.
  An ideal solution would allow attendees to join as individuals from
  anywhere.  A lot of contributors work from home.  Is that sort of thing
  compatible with your system?
 
 http://bluejeans.com/ was a good experience.

 What about Google Hangout OnAir for the PTL and core, while others are
 view-only with chat/irc questions?

 http://www.google.com/+/learnmore/hangouts/onair.html


We've done Google Hangout OnAir for the docs team with varied success due
to the oddities with calendaring and having to know everyone's preferred
Google identity. It's nice for high-fidelity conversations without
requiring travel. It also lets people tune in then or watch a recording
later.
Anne






 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Kyle Mestery
On Thu, Aug 14, 2014 at 10:13 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
 On 8/14/2014 11:28 AM, Russell Bryant wrote:
 On 08/14/2014 10:04 AM, CARVER, PAUL wrote:
 Daniel P. Berrange [mailto:berra...@redhat.com] wrote:

 Depending on the usage needs, I think Google hangouts is a quite useful
 technology. For many-to-many session its limit of 10 participants can be
 an issue, but for a few-to-many broadcast it could be practical. What I
 find particularly appealing is the way it can live stream the session
 over youtube which allows for unlimited number of viewers, as well as
 being available offline for later catchup.
 I can't actually offer ATT resources without getting some level of
 management approval first, but just for the sake of discussion here's
 some info about the telepresence system we use.

 -=-=-=-=-=-=-=-=-=-
 ATS B2B Telepresence conferences can be conducted with an external company's
 Telepresence room(s), which subscribe to the ATT Telepresence Solution,
 or a limited number of other Telepresence service provider's networks.

 Currently, the number of Telepresence rooms that can participate in a B2B
 conference is limited to a combined total of 20 rooms (19 of which can be
 ATT rooms, depending on the number of remote endpoints included).
 -=-=-=-=-=-=-=-=-=-

 We currently have B2B interconnect with over 100 companies and ATT has
 telepresence rooms in many of our locations around the US and around
 the world. If other large OpenStack companies also have telepresence
 rooms that we could interconnect with I think it might be possible
 to get management agreement to hold a couple OpenStack meetups per
 year.

 Most of our rooms are best suited for 6 people, but I know of at least
 one 18 person telepresence room near me.
 An ideal solution would allow attendees to join as individuals from
 anywhere.  A lot of contributors work from home.  Is that sort of thing
 compatible with your system?

 http://bluejeans.com/ was a good experience.

 What about Google Hangout OnAir for the PTL and core, while others are
 view-only with chat/irc questions?

This is a terrible idea, as it perpetuates the core vs. non-core
argument. We need equal participation for cores and non-cores alike.

 http://www.google.com/+/learnmore/hangouts/onair.html



 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread CARVER, PAUL
Russell Bryant [mailto:rbry...@redhat.com] wrote:

An ideal solution would allow attendees to join as individuals from
anywhere.  A lot of contributors work from home.  Is that sort of thing
compatible with your system?

In principle, yes, but that loses the immersive telepresence aspect
which is the next best thing to an in-person meetup (which is where
this thread started.)

ATT Employees live and breathe on ATT Connect which is our
teleconferencing (not telepresence) service. It supports webcam
video as well as desktop sharing, but I'm on the verge of making
a sales pitch here which was NOT my intent.

I'm on ATT Connect meetings 5+ times a day but I'm biased so I
won't offer any opinion on how it compares to WebEx, GotoMeeting,
and other services. None of them are really equivalent to the
purpose built telepresence rooms.

My point was that there may well be a telepresence room within
reasonable driving distance for a large number of OpenStack
contributors if we were able to get a number of the large
OpenStack participant companies to open their doors to an
occasional meet-up. Instead of asking participants around
the globe to converge on a single physical location for
a meet-up, perhaps they could converge on the closest of
20 different locations that are linked via telepresence.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Kyle Mestery
On Thu, Aug 14, 2014 at 10:31 AM, CARVER, PAUL pc2...@att.com wrote:
 Russell Bryant [mailto:rbry...@redhat.com] wrote:

An ideal solution would allow attendees to join as individuals from
anywhere.  A lot of contributors work from home.  Is that sort of thing
compatible with your system?

 In principle, yes, but that loses the immersive telepresence aspect
 which is the next best thing to an in-person meetup (which is where
 this thread started.)

 ATT Employees live and breathe on ATT Connect which is our
 teleconferencing (not telepresence) service. It supports webcam
 video as well as desktop sharing, but I'm on the verge of making
 a sales pitch here which was NOT my intent.

 I'm on ATT Connect meetings 5+ times a day but I'm biased so I
 won't offer any opinion on how it compares to WebEx, GotoMeeting,
 and other services. None of them are really equivalent to the
 purpose built telepresence rooms.

 My point was that there may well be a telepresence room within
 reasonable driving distance for a large number of OpenStack
 contributors if we were able to get a number of the large
 OpenStack participant companies to open their doors to an
 occasional meet-up. Instead of asking participants around
 the globe to converge on a single physical location for
 a meet-up, perhaps they could converge on the closest of
 20 different locations that are linked via telepresence.

If we could make this work, I'd be up for it. It's a great balance to
the travel and face-to-face argument here.

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-14 Thread Russell Bryant
On 08/14/2014 11:40 AM, David Kranz wrote:
 On 08/14/2014 10:54 AM, Matt Riedemann wrote:


 On 8/14/2014 3:47 AM, Daniel P. Berrange wrote:
 On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:
 On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote:
 I'm not questioning the value of f2f - I'm questioning the idea of
 doing f2f meetings sooo many times a year. OpenStack is very much
 the outlier here among open source projects - the vast majority of
 projects get along very well with much less f2f time and a far
 smaller % of their contributors attend those f2f meetings that do
 happen. So I really do question what is missing from OpenStack's
 community interaction that makes us believe that having 4 f2f
 meetings a year is critical to our success.

 How many is too many? So far, I have found the midcycles to be
 extremely
 productive -- productive in a way that we don't see at the summits,
 and
 I think other attendees agree. Obviously if budgets start limiting
 them,
 then we'll have to deal with it, but I don't want to stop meeting
 preemptively.

 I agree they're very productive. Let's pick on the nova v3 API case as
 an example... We had failed as a community to reach a consensus using
 our existing discussion mechanisms (hundreds of emails, at least three
 specs, phone calls between the various parties, et cetera), yet at the
 summit and then a midcycle meetup we managed to nail down an agreement
 on a very contentious and complicated topic.

 We thought we had agreement on v3 API after Atlanta f2f summit and
 after Hong Kong f2f too. So I wouldn't neccessarily say that we
 needed another f2f meeting to resolve that, but rather than this is
 a very complex topic that takes a long time to resolve no matter
 how we discuss it and the discussions had just happened to reach
 a natural conclusion this time around. But lets see if this agreement
 actually sticks this time

 I can see the argument that travel cost is an issue, but I think its
 also not a very strong argument. We have companies spending millions
 of dollars on OpenStack -- surely spending a relatively small amount
 on travel to keep the development team as efficient as possible isn't
 a big deal? I wouldn't be at all surprised if the financial costs of
 the v3 API debate (staff time mainly) were much higher than the travel
 costs of those involved in the summit and midcycle discussions which
 sorted it out.

 I think the travel cost really is a big issue. Due to the number of
 people who had to travel to the many mid-cycle meetups, a good number
 of people I work with no longer have the ability to go to the Paris
 design summit. This is going to make it harder for them to feel a
 proper engaged part of our community. I can only see this situation
 get worse over time if greater emphasis is placed on attending the
 mid-cycle meetups.

 Travelling to places to talk to people isn't a great solution, but it
 is the most effective one we've found so far. We should continue to
 experiment with other options, but until we find something that works
 as well as meetups, I think we need to keep having them.

 IMHO, the reasons to cut back would be:

 - People leaving with a well, that was useless... feeling
 - Not enough people able to travel to make it worthwhile

 So far, neither of those have been outcomes of the midcycles we've
 had,
 so I think we're doing okay.

 The design summits are structured differently, where we see a lot more
 diverse attendance because of the colocation with the user summit. It
 doesn't lend itself well to long and in-depth discussions about
 specific
 things, but it's very useful for what it gives us in the way of
 exposure. We could try to have less of that at the summit and more
 midcycle-ish time, but I think it's unlikely to achieve the same level
 of usefulness in that environment.

 Specifically, the lack of colocation with too many other projects has
 been a benefit. This time, Mark and Maru where there from Neutron.
 Last
 time, Mark from Neutron and the other Mark from Glance were there. If
 they were having meetups in other rooms (like at summit) they wouldn't
 have been there exposed to discussions that didn't seem like they'd
 have
 a component for their participation, but did after all (re: nova and
 glance and who should own flavors).

 I agree. The ability to focus on the issues that were blocking nova
 was very important. That's hard to do at a design summit when there is
 so much happening at the same time.

 Maybe we should change the way we structure the design summit to
 improve that. If there are critical issues blocking nova, it feels
 like it is better to be able to discuss and resolve as much as possible
 at the start of the dev cycle rather than in the middle of the dev
 cycle because I feel that means we are causing ourselves pain during
 milestone 1/2.

 Just speaking from experience, I attended the Icehouse meetup before
 my first summit (Juno in ATL) and the 

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

2014-08-14 Thread Joe Gordon
On Thu, Aug 14, 2014 at 1:47 AM, Daniel P. Berrange berra...@redhat.com
wrote:

 On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:
  On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote:
   I'm not questioning the value of f2f - I'm questioning the idea of
   doing f2f meetings sooo many times a year. OpenStack is very much
   the outlier here among open source projects - the vast majority of
   projects get along very well with much less f2f time and a far
   smaller % of their contributors attend those f2f meetings that do
   happen. So I really do question what is missing from OpenStack's
   community interaction that makes us believe that having 4 f2f
   meetings a year is critical to our success.
  
   How many is too many? So far, I have found the midcycles to be
 extremely
   productive -- productive in a way that we don't see at the summits, and
   I think other attendees agree. Obviously if budgets start limiting
 them,
   then we'll have to deal with it, but I don't want to stop meeting
   preemptively.
 
  I agree they're very productive. Let's pick on the nova v3 API case as
  an example... We had failed as a community to reach a consensus using
  our existing discussion mechanisms (hundreds of emails, at least three
  specs, phone calls between the various parties, et cetera), yet at the
  summit and then a midcycle meetup we managed to nail down an agreement
  on a very contentious and complicated topic.

 We thought we had agreement on v3 API after Atlanta f2f summit and
 after Hong Kong f2f too. So I wouldn't neccessarily say that we
 needed another f2f meeting to resolve that, but rather than this is
 a very complex topic that takes a long time to resolve no matter
 how we discuss it and the discussions had just happened to reach
 a natural conclusion this time around. But lets see if this agreement
 actually sticks this time

  I can see the argument that travel cost is an issue, but I think its
  also not a very strong argument. We have companies spending millions
  of dollars on OpenStack -- surely spending a relatively small amount
  on travel to keep the development team as efficient as possible isn't
  a big deal? I wouldn't be at all surprised if the financial costs of
  the v3 API debate (staff time mainly) were much higher than the travel
  costs of those involved in the summit and midcycle discussions which
  sorted it out.

 I think the travel cost really is a big issue. Due to the number of
 people who had to travel to the many mid-cycle meetups, a good number
 of people I work with no longer have the ability to go to the Paris
 design summit. This is going to make it harder for them to feel a
 proper engaged part of our community. I can only see this situation
 get worse over time if greater emphasis is placed on attending the
 mid-cycle meetups.

  Travelling to places to talk to people isn't a great solution, but it
  is the most effective one we've found so far. We should continue to
  experiment with other options, but until we find something that works
  as well as meetups, I think we need to keep having them.
 
   IMHO, the reasons to cut back would be:
  
   - People leaving with a well, that was useless... feeling
   - Not enough people able to travel to make it worthwhile
  
   So far, neither of those have been outcomes of the midcycles we've had,
   so I think we're doing okay.
  
   The design summits are structured differently, where we see a lot more
   diverse attendance because of the colocation with the user summit. It
   doesn't lend itself well to long and in-depth discussions about
 specific
   things, but it's very useful for what it gives us in the way of
   exposure. We could try to have less of that at the summit and more
   midcycle-ish time, but I think it's unlikely to achieve the same level
   of usefulness in that environment.
  
   Specifically, the lack of colocation with too many other projects has
   been a benefit. This time, Mark and Maru where there from Neutron. Last
   time, Mark from Neutron and the other Mark from Glance were there. If
   they were having meetups in other rooms (like at summit) they wouldn't
   have been there exposed to discussions that didn't seem like they'd
 have
   a component for their participation, but did after all (re: nova and
   glance and who should own flavors).
 
  I agree. The ability to focus on the issues that were blocking nova
  was very important. That's hard to do at a design summit when there is
  so much happening at the same time.

 Maybe we should change the way we structure the design summit to
 improve that. If there are critical issues blocking nova, it feels
 like it is better to be able to discuss and resolve as much as possible
 at the start of the dev cycle rather than in the middle of the dev
 cycle because I feel that means we are causing ourselves pain during
 milestone 1/2.

   As I explain in the rest of my email below I'm not advocating
   getting 

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

2014-08-14 Thread Sylvain Bauza
Le 14 août 2014 21:56, Joe Gordon joe.gord...@gmail.com a écrit :




 On Thu, Aug 14, 2014 at 1:47 AM, Daniel P. Berrange berra...@redhat.com
wrote:

 On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote:
  On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote:
   I'm not questioning the value of f2f - I'm questioning the idea of
   doing f2f meetings sooo many times a year. OpenStack is very much
   the outlier here among open source projects - the vast majority of
   projects get along very well with much less f2f time and a far
   smaller % of their contributors attend those f2f meetings that do
   happen. So I really do question what is missing from OpenStack's
   community interaction that makes us believe that having 4 f2f
   meetings a year is critical to our success.
  
   How many is too many? So far, I have found the midcycles to be
extremely
   productive -- productive in a way that we don't see at the summits,
and
   I think other attendees agree. Obviously if budgets start limiting
them,
   then we'll have to deal with it, but I don't want to stop meeting
   preemptively.
 
  I agree they're very productive. Let's pick on the nova v3 API case as
  an example... We had failed as a community to reach a consensus using
  our existing discussion mechanisms (hundreds of emails, at least three
  specs, phone calls between the various parties, et cetera), yet at the
  summit and then a midcycle meetup we managed to nail down an agreement
  on a very contentious and complicated topic.

 We thought we had agreement on v3 API after Atlanta f2f summit and
 after Hong Kong f2f too. So I wouldn't neccessarily say that we
 needed another f2f meeting to resolve that, but rather than this is
 a very complex topic that takes a long time to resolve no matter
 how we discuss it and the discussions had just happened to reach
 a natural conclusion this time around. But lets see if this agreement
 actually sticks this time

  I can see the argument that travel cost is an issue, but I think its
  also not a very strong argument. We have companies spending millions
  of dollars on OpenStack -- surely spending a relatively small amount
  on travel to keep the development team as efficient as possible isn't
  a big deal? I wouldn't be at all surprised if the financial costs of
  the v3 API debate (staff time mainly) were much higher than the travel
  costs of those involved in the summit and midcycle discussions which
  sorted it out.

 I think the travel cost really is a big issue. Due to the number of
 people who had to travel to the many mid-cycle meetups, a good number
 of people I work with no longer have the ability to go to the Paris
 design summit. This is going to make it harder for them to feel a
 proper engaged part of our community. I can only see this situation
 get worse over time if greater emphasis is placed on attending the
 mid-cycle meetups.

  Travelling to places to talk to people isn't a great solution, but it
  is the most effective one we've found so far. We should continue to
  experiment with other options, but until we find something that works
  as well as meetups, I think we need to keep having them.
 
   IMHO, the reasons to cut back would be:
  
   - People leaving with a well, that was useless... feeling
   - Not enough people able to travel to make it worthwhile
  
   So far, neither of those have been outcomes of the midcycles we've
had,
   so I think we're doing okay.
  
   The design summits are structured differently, where we see a lot
more
   diverse attendance because of the colocation with the user summit. It
   doesn't lend itself well to long and in-depth discussions about
specific
   things, but it's very useful for what it gives us in the way of
   exposure. We could try to have less of that at the summit and more
   midcycle-ish time, but I think it's unlikely to achieve the same
level
   of usefulness in that environment.
  
   Specifically, the lack of colocation with too many other projects has
   been a benefit. This time, Mark and Maru where there from Neutron.
Last
   time, Mark from Neutron and the other Mark from Glance were there. If
   they were having meetups in other rooms (like at summit) they
wouldn't
   have been there exposed to discussions that didn't seem like they'd
have
   a component for their participation, but did after all (re: nova and
   glance and who should own flavors).
 
  I agree. The ability to focus on the issues that were blocking nova
  was very important. That's hard to do at a design summit when there is
  so much happening at the same time.

 Maybe we should change the way we structure the design summit to
 improve that. If there are critical issues blocking nova, it feels
 like it is better to be able to discuss and resolve as much as possible
 at the start of the dev cycle rather than in the middle of the dev
 cycle because I feel that means we are causing ourselves pain during
 milestone 1/2.

   As I 

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

2014-08-14 Thread Andrew Laski


On 08/14/2014 02:48 PM, Dugger, Donald D wrote:


My experience with mics, no matter how good, In conference rooms is 
not good.  You are always working hard to hear the soft spoken person 
who is drowned by the background noise. It’s always a strain and I 
don’t want to even think about doing it for a full 8 hrs.  It’s better 
than nothing so I agree, we need to provide some sort of remote 
conferencing at meetups but nothing compares with actually being there.


I’m not a core so I’m speaking from the outside but I think requiring 
attendance at the summits (absence requires a note from your parent 
Jwhile strongly encouraging attendance at mid-cycle meetups seems 
reasonable.




I think expecting summit attendance, rather than requiring, is a better 
way to say it, but otherwise I agree that this seems reasonable.



PS: In re companies spending millions on OpenStack so travel to f2f 
events should be a drop in the bucket.  It doesn’t always work that 
way with the finance department, money comes out of different buckets 
and the travel bucket `always` dries up first.


--

Don Dugger

Censeo Toto nos in Kansa esse decisse. - D. Gale

Ph: 303/443-3786

*From:*Joe Gordon [mailto:joe.gord...@gmail.com]
*Sent:* Wednesday, August 13, 2014 10:48 PM
*To:* OpenStack Development Mailing List (not for usage questions)
*Subject:* Re: [openstack-dev] [nova][core] Expectations of core reviewers

On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com 
mailto:mi...@stillhq.com wrote:


On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com
mailto:jaypi...@gmail.com wrote:

 Just wanted to quickly weigh in with my thoughts on this
important topic. I
 very much valued the face-to-face interaction that came from the
mid-cycle
 meetup in Beaverton (it was the only one I've ever been to).

 That said, I do not believe it should be a requirement that
cores make it to
 the face-to-face meetings in-person. A number of folks have
brought up very
 valid concerns about personal/family time, travel costs and burnout.

I'm not proposing they be a requirement. I am proposing that they be
strongly encouraged.


 I believe that the issue raised about furthering the divide
between core and
 non-core folks is actually the biggest reason I don't support a
mandate to
 have cores at the face-to-face meetings, and I think we should
make our best
 efforts to support quality virtual meetings that can be done on
a more
 frequent basis than the face-to-face meetings that would be
optional.

I am all for online meetings, but we don't have a practical way to do
them at the moment apart from IRC. Until someone has a concrete
proposal that's been shown to work, I feel its a straw man argument.

What about making it easier for remote people to participate at the 
mid-cycle meetups? Set up some microphones and a Google hangout?  At 
least that way attending the mid-cycle is not all or nothing.


We did something like this last cycle (IIRC we didn't have enough 
mics) and it worked pretty well.



Michael

--
Rackspace Australia


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
mailto:OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Daniel P. Berrange
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
 Hi.
 
 One of the action items from the nova midcycle was that I was asked to
 make nova's expectations of core reviews more clear. This email is an
 attempt at that.
 
 Nova expects a minimum level of sustained code reviews from cores. In
 the past this has been generally held to be in the order of two code
 reviews a day, which is a pretty low bar compared to the review
 workload of many cores. I feel that existing cores understand this
 requirement well, and I am mostly stating it here for completeness.
 
 Additionally, there is increasing levels of concern that cores need to
 be on the same page about the criteria we hold code to, as well as the
 overall direction of nova. While the weekly meetings help here, it was
 agreed that summit attendance is really important to cores. Its the
 way we decide where we're going for the next cycle, as well as a
 chance to make sure that people are all pulling in the same direction
 and trust each other.
 
 There is also a strong preference for midcycle meetup attendance,
 although I understand that can sometimes be hard to arrange. My stance
 is that I'd like core's to try to attend, but understand that
 sometimes people will miss one. In response to the increasing
 importance of midcycles over time, I commit to trying to get the dates
 for these events announced further in advance.

Personally I'm going to find it really hard to justify long distance
travel 4 times a year for OpenStack for personal / family reasons,
let alone company cost. I couldn't attend Icehouse mid-cycle because
I just had too much travel in a short time to be able to do another
week long trip away from family. I couldn't attend Juno mid-cycle
because it clashed we personal holiday. There are other opensource
related conferences that I also have to attend (LinuxCon, FOSDEM,
KVM Forum, etc), etc so doubling the expected number of openstack
conferences from 2 to 4 is really very undesirable from my POV.
I might be able to attend the occassional mid-cycle meetup if the
location was convenient, but in general I don't see myself being
able to attend them regularly.

I tend to view the fact that we're emphasising the need of in-person
meetups to be somewhat of an indication of failure of our community
operation. The majority of open source projects work very effectively
with far less face-to-face time. OpenStack is fortunate that companies
are currently willing to spend 6/7-figure sums flying 1000's of
developers around the world many times a year, but I don't see that
lasting forever so I'm concerned about baking the idea of f2f midcycle
meetups into our way of life even more strongly.

 Given that we consider these physical events so important, I'd like
 people to let me know if they have travel funding issues. I can then
 approach the Foundation about funding travel if that is required.

Travel funding is certainly an issue, but I'm not sure that Foundation
funding would be a solution, because the impact probably isn't directly
on the core devs. Speaking with my Red Hat on, if the midcycle meetup
is important enough, the core devs will likely get the funding to attend.
The fallout of this though is that every attendee at a mid-cycle summit
means fewer attendees at the next design summit. So the impact of having
more core devs at mid-cycle is that we'll get fewer non-core devs at
the design summit. This sucks big time for the non-core devs who want
to engage with our community.

Also having each team do a f2f mid-cycle meetup at a different location
makes it even harder for people who have a genuine desire / need to take
part in multiple teams. Going to multiple mid-cycle meetups is even more
difficult to justify so they're having to make difficult decisions about
which to go to :-(

I'm also not a fan of mid-cycle meetups because I feel it further
stratifies our contributors into two increasly distinct camps - core
vs non-core.

I can see that a big benefit of a mid-cycle meetup is to be a focal
point for collaboration, to forcably break contributors our of their
day-to-day work pattern to concentrate on discussing specific issues.
It also obviously solves the distinct timezone problem we have with
our dispersed contributor base. I think that we should be examining
what we can achieve with some kind of virtual online mid-cycle meetups
instead. Using technology like google hangouts or some similar live
collaboration technology, not merely an IRC discussion. Pick a 2-3
day period, schedule formal agendas / talking slots as you would with
a physical summit and so on. I feel this would be more inclusive to
our community as a whole, avoid excessive travel costs, so allowing
more of our community to attend the bigger design summits. It would
even open possibility of having multiple meetups during a cycle (eg
could arrange mini virtual events around each milestone if we wanted)

Regards,
Daniel
-- 
|: http://berrange.com  -o-

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

2014-08-13 Thread Russell Bryant
On 08/12/2014 06:57 PM, Michael Still wrote:
 Hi.
 
 One of the action items from the nova midcycle was that I was asked to
 make nova's expectations of core reviews more clear. This email is an
 attempt at that.

Note that we also have:

https://wiki.openstack.org/wiki/Nova/CoreTeam

so once new critera reaches consensus, it should be added there.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Russell Bryant
On 08/13/2014 05:57 AM, Daniel P. Berrange wrote:
 On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
 Hi.

 One of the action items from the nova midcycle was that I was asked to
 make nova's expectations of core reviews more clear. This email is an
 attempt at that.

 Nova expects a minimum level of sustained code reviews from cores. In
 the past this has been generally held to be in the order of two code
 reviews a day, which is a pretty low bar compared to the review
 workload of many cores. I feel that existing cores understand this
 requirement well, and I am mostly stating it here for completeness.

Yep, this bit is obviously the most important.  I would prefer a good
level of review activity be the only *hard* requirement.

 Additionally, there is increasing levels of concern that cores need to
 be on the same page about the criteria we hold code to, as well as the
 overall direction of nova. While the weekly meetings help here, it was
 agreed that summit attendance is really important to cores. Its the
 way we decide where we're going for the next cycle, as well as a
 chance to make sure that people are all pulling in the same direction
 and trust each other.

 There is also a strong preference for midcycle meetup attendance,
 although I understand that can sometimes be hard to arrange. My stance
 is that I'd like core's to try to attend, but understand that
 sometimes people will miss one. In response to the increasing
 importance of midcycles over time, I commit to trying to get the dates
 for these events announced further in advance.
 
 Personally I'm going to find it really hard to justify long distance
 travel 4 times a year for OpenStack for personal / family reasons,
 let alone company cost. I couldn't attend Icehouse mid-cycle because
 I just had too much travel in a short time to be able to do another
 week long trip away from family. I couldn't attend Juno mid-cycle
 because it clashed we personal holiday. There are other opensource
 related conferences that I also have to attend (LinuxCon, FOSDEM,
 KVM Forum, etc), etc so doubling the expected number of openstack
 conferences from 2 to 4 is really very undesirable from my POV.
 I might be able to attend the occassional mid-cycle meetup if the
 location was convenient, but in general I don't see myself being
 able to attend them regularly.
 
 I tend to view the fact that we're emphasising the need of in-person
 meetups to be somewhat of an indication of failure of our community
 operation. The majority of open source projects work very effectively
 with far less face-to-face time. OpenStack is fortunate that companies
 are currently willing to spend 6/7-figure sums flying 1000's of
 developers around the world many times a year, but I don't see that
 lasting forever so I'm concerned about baking the idea of f2f midcycle
 meetups into our way of life even more strongly.

I'm concerned about this, as well.  There are lots of reasons people
can't attend things (budget or personal reasons).  I'd hate to think
that not being able to travel this much (which I think is *a lot*) hurts
someone's ability to be an important part of the nova team.
Unfortunately, that's the direction we're trending.

I also think it furthers the image of nova being an exclusive clique.  I
think we should always look at things as ways to be as inclusive as
possible.  Focusing the important conversations at the 4 in-person
meetups per year leaves most of the community out.

 Given that we consider these physical events so important, I'd like
 people to let me know if they have travel funding issues. I can then
 approach the Foundation about funding travel if that is required.
 
 Travel funding is certainly an issue, but I'm not sure that Foundation
 funding would be a solution, because the impact probably isn't directly
 on the core devs. Speaking with my Red Hat on, if the midcycle meetup
 is important enough, the core devs will likely get the funding to attend.
 The fallout of this though is that every attendee at a mid-cycle summit
 means fewer attendees at the next design summit. So the impact of having
 more core devs at mid-cycle is that we'll get fewer non-core devs at
 the design summit. This sucks big time for the non-core devs who want
 to engage with our community.

I can confirm that this is the effect I am seeing for our team.  There
were *a lot* of meetups this cycle, and it was expensive.

This was actually one of the arguments against splitting the design
summit out from the main conference, yet I'm afraid we've created the
problem anyway.

 Also having each team do a f2f mid-cycle meetup at a different location
 makes it even harder for people who have a genuine desire / need to take
 part in multiple teams. Going to multiple mid-cycle meetups is even more
 difficult to justify so they're having to make difficult decisions about
 which to go to :-(

Indeed, and we actually need to be strongly *encouraging* cross-project
participation.

 

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

2014-08-13 Thread Joshua Harlow

A big +1 to what daniel said,

If f2f events are becoming so important  the only way to get things 
done, IMHO we should really start to do some reflection on how our 
community operates and start thinking about what we are doing wrong. 
Expecting every company to send developers (core or non-core) to all 
these events is unrealistic (and IMHO is the wrong path our community 
should go down). If only cores go (they can probably convince their 
employers they should/need to), these f2f events become something akin 
to secret f2f meetings where decisions are made behind some set of 
closed-doors (maybe cores should then be renamed the 'secret society of 
core reviewers', maybe even giving them a illuminati like logo, haha), 
that doesn't seem very open to me (and as daniel said further 
stratifies the people who work on openstack...).


Going the whole virtual route does seem better (although it still feels 
like something is wrong with how we are operating if that's even 
needed).


-Josh

On Wed, Aug 13, 2014 at 2:57 AM, Daniel P. Berrange 
berra...@redhat.com wrote:

On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:

 Hi.
 
 One of the action items from the nova midcycle was that I was asked 
to
 make nova's expectations of core reviews more clear. This email is 
an

 attempt at that.
 
 Nova expects a minimum level of sustained code reviews from cores. 
In

 the past this has been generally held to be in the order of two code
 reviews a day, which is a pretty low bar compared to the review
 workload of many cores. I feel that existing cores understand this
 requirement well, and I am mostly stating it here for completeness.
 
 Additionally, there is increasing levels of concern that cores need 
to
 be on the same page about the criteria we hold code to, as well as 
the
 overall direction of nova. While the weekly meetings help here, it 
was

 agreed that summit attendance is really important to cores. Its the
 way we decide where we're going for the next cycle, as well as a
 chance to make sure that people are all pulling in the same 
direction

 and trust each other.
 
 There is also a strong preference for midcycle meetup attendance,
 although I understand that can sometimes be hard to arrange. My 
stance

 is that I'd like core's to try to attend, but understand that
 sometimes people will miss one. In response to the increasing
 importance of midcycles over time, I commit to trying to get the 
dates

 for these events announced further in advance.


Personally I'm going to find it really hard to justify long distance
travel 4 times a year for OpenStack for personal / family reasons,
let alone company cost. I couldn't attend Icehouse mid-cycle because
I just had too much travel in a short time to be able to do another
week long trip away from family. I couldn't attend Juno mid-cycle
because it clashed we personal holiday. There are other opensource
related conferences that I also have to attend (LinuxCon, FOSDEM,
KVM Forum, etc), etc so doubling the expected number of openstack
conferences from 2 to 4 is really very undesirable from my POV.
I might be able to attend the occassional mid-cycle meetup if the
location was convenient, but in general I don't see myself being
able to attend them regularly.

I tend to view the fact that we're emphasising the need of in-person
meetups to be somewhat of an indication of failure of our community
operation. The majority of open source projects work very effectively
with far less face-to-face time. OpenStack is fortunate that companies
are currently willing to spend 6/7-figure sums flying 1000's of
developers around the world many times a year, but I don't see that
lasting forever so I'm concerned about baking the idea of f2f midcycle
meetups into our way of life even more strongly.


 Given that we consider these physical events so important, I'd like
 people to let me know if they have travel funding issues. I can then
 approach the Foundation about funding travel if that is required.


Travel funding is certainly an issue, but I'm not sure that Foundation
funding would be a solution, because the impact probably isn't 
directly

on the core devs. Speaking with my Red Hat on, if the midcycle meetup
is important enough, the core devs will likely get the funding to 
attend.
The fallout of this though is that every attendee at a mid-cycle 
summit
means fewer attendees at the next design summit. So the impact of 
having

more core devs at mid-cycle is that we'll get fewer non-core devs at
the design summit. This sucks big time for the non-core devs who want
to engage with our community.

Also having each team do a f2f mid-cycle meetup at a different 
location
makes it even harder for people who have a genuine desire / need to 
take
part in multiple teams. Going to multiple mid-cycle meetups is even 
more
difficult to justify so they're having to make difficult decisions 
about

which to go to :-(

I'm also not a fan of mid-cycle meetups because I feel 

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

2014-08-13 Thread Kyle Mestery
On Wed, Aug 13, 2014 at 7:55 AM, Russell Bryant rbry...@redhat.com wrote:
 On 08/13/2014 05:57 AM, Daniel P. Berrange wrote:
 On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
 Hi.

 One of the action items from the nova midcycle was that I was asked to
 make nova's expectations of core reviews more clear. This email is an
 attempt at that.

 Nova expects a minimum level of sustained code reviews from cores. In
 the past this has been generally held to be in the order of two code
 reviews a day, which is a pretty low bar compared to the review
 workload of many cores. I feel that existing cores understand this
 requirement well, and I am mostly stating it here for completeness.

 Yep, this bit is obviously the most important.  I would prefer a good
 level of review activity be the only *hard* requirement.

 Additionally, there is increasing levels of concern that cores need to
 be on the same page about the criteria we hold code to, as well as the
 overall direction of nova. While the weekly meetings help here, it was
 agreed that summit attendance is really important to cores. Its the
 way we decide where we're going for the next cycle, as well as a
 chance to make sure that people are all pulling in the same direction
 and trust each other.

 There is also a strong preference for midcycle meetup attendance,
 although I understand that can sometimes be hard to arrange. My stance
 is that I'd like core's to try to attend, but understand that
 sometimes people will miss one. In response to the increasing
 importance of midcycles over time, I commit to trying to get the dates
 for these events announced further in advance.

 Personally I'm going to find it really hard to justify long distance
 travel 4 times a year for OpenStack for personal / family reasons,
 let alone company cost. I couldn't attend Icehouse mid-cycle because
 I just had too much travel in a short time to be able to do another
 week long trip away from family. I couldn't attend Juno mid-cycle
 because it clashed we personal holiday. There are other opensource
 related conferences that I also have to attend (LinuxCon, FOSDEM,
 KVM Forum, etc), etc so doubling the expected number of openstack
 conferences from 2 to 4 is really very undesirable from my POV.
 I might be able to attend the occassional mid-cycle meetup if the
 location was convenient, but in general I don't see myself being
 able to attend them regularly.

 I tend to view the fact that we're emphasising the need of in-person
 meetups to be somewhat of an indication of failure of our community
 operation. The majority of open source projects work very effectively
 with far less face-to-face time. OpenStack is fortunate that companies
 are currently willing to spend 6/7-figure sums flying 1000's of
 developers around the world many times a year, but I don't see that
 lasting forever so I'm concerned about baking the idea of f2f midcycle
 meetups into our way of life even more strongly.

 I'm concerned about this, as well.  There are lots of reasons people
 can't attend things (budget or personal reasons).  I'd hate to think
 that not being able to travel this much (which I think is *a lot*) hurts
 someone's ability to be an important part of the nova team.
 Unfortunately, that's the direction we're trending.


+1

I've seen a definitie uptick in travel for OpenStack, and it's not
sustainable for all the reasons stated here. We need to figure out a
better way to collaborate virtually, as we're a global Open Source
project and we can't assume that everyone can travel all the time for
all the mid-cycles, conferences, etc.


 I also think it furthers the image of nova being an exclusive clique.  I
 think we should always look at things as ways to be as inclusive as
 possible.  Focusing the important conversations at the 4 in-person
 meetups per year leaves most of the community out.


Again, I agree with this assessment. We need to shift things back to
the weekly IRC meetings, ML discussions, and perhaps some sort of
virtual conference scheduling as well.

 Given that we consider these physical events so important, I'd like
 people to let me know if they have travel funding issues. I can then
 approach the Foundation about funding travel if that is required.

 Travel funding is certainly an issue, but I'm not sure that Foundation
 funding would be a solution, because the impact probably isn't directly
 on the core devs. Speaking with my Red Hat on, if the midcycle meetup
 is important enough, the core devs will likely get the funding to attend.
 The fallout of this though is that every attendee at a mid-cycle summit
 means fewer attendees at the next design summit. So the impact of having
 more core devs at mid-cycle is that we'll get fewer non-core devs at
 the design summit. This sucks big time for the non-core devs who want
 to engage with our community.

 I can confirm that this is the effect I am seeing for our team.  There
 were *a lot* of meetups this cycle, and 

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

2014-08-13 Thread CARVER, PAUL
Daniel P. Berrange [mailto:berra...@redhat.com] wrote:

our dispersed contributor base. I think that we should be examining
what we can achieve with some kind of virtual online mid-cycle meetups
instead. Using technology like google hangouts or some similar live
collaboration technology, not merely an IRC discussion. Pick a 2-3
day period, schedule formal agendas / talking slots as you would with
a physical summit and so on. I feel this would be more inclusive to
our community as a whole, avoid excessive travel costs, so allowing
more of our community to attend the bigger design summits. It would
even open possibility of having multiple meetups during a cycle (eg
could arrange mini virtual events around each milestone if we wanted)

How about arranging some high quality telepresence rooms? A number of
the big companies associated with OpenStack either make or own some
pretty nice systems. Perhaps it could be negotiated for some of these
companies to open their doors to allow OpenStack developers for some
scheduled events.

With some scheduling and coordination effort it would probably be
possible to setup a bunch of local meet-up points interconnected
by telepresence links.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Maru Newby

On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:

 On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
 Hi.
 
 One of the action items from the nova midcycle was that I was asked to
 make nova's expectations of core reviews more clear. This email is an
 attempt at that.
 
 Nova expects a minimum level of sustained code reviews from cores. In
 the past this has been generally held to be in the order of two code
 reviews a day, which is a pretty low bar compared to the review
 workload of many cores. I feel that existing cores understand this
 requirement well, and I am mostly stating it here for completeness.
 
 Additionally, there is increasing levels of concern that cores need to
 be on the same page about the criteria we hold code to, as well as the
 overall direction of nova. While the weekly meetings help here, it was
 agreed that summit attendance is really important to cores. Its the
 way we decide where we're going for the next cycle, as well as a
 chance to make sure that people are all pulling in the same direction
 and trust each other.
 
 There is also a strong preference for midcycle meetup attendance,
 although I understand that can sometimes be hard to arrange. My stance
 is that I'd like core's to try to attend, but understand that
 sometimes people will miss one. In response to the increasing
 importance of midcycles over time, I commit to trying to get the dates
 for these events announced further in advance.
 
 Personally I'm going to find it really hard to justify long distance
 travel 4 times a year for OpenStack for personal / family reasons,
 let alone company cost. I couldn't attend Icehouse mid-cycle because
 I just had too much travel in a short time to be able to do another
 week long trip away from family. I couldn't attend Juno mid-cycle
 because it clashed we personal holiday. There are other opensource
 related conferences that I also have to attend (LinuxCon, FOSDEM,
 KVM Forum, etc), etc so doubling the expected number of openstack
 conferences from 2 to 4 is really very undesirable from my POV.
 I might be able to attend the occassional mid-cycle meetup if the
 location was convenient, but in general I don't see myself being
 able to attend them regularly.
 
 I tend to view the fact that we're emphasising the need of in-person
 meetups to be somewhat of an indication of failure of our community
 operation. The majority of open source projects work very effectively
 with far less face-to-face time. OpenStack is fortunate that companies
 are currently willing to spend 6/7-figure sums flying 1000's of
 developers around the world many times a year, but I don't see that
 lasting forever so I'm concerned about baking the idea of f2f midcycle
 meetups into our way of life even more strongly.

I was fortunate to attend both the Nova and Neutron mid-cycles last month, and 
I can attest to how productive these gatherings were.  Discussion moved quickly 
and misunderstandings were rapidly resolved.  Informal ('water-cooler') 
conversation led to many interactions that might not otherwise have occurred.  
Given your attendance of summit and other open source conferences, though, I'm 
assuming the value of f2f is not in question.

Nothing good is ever free.  The financial cost and exclusionary nature of an 
in-person meetup should definitely be weighed against the opportunity for 
focused and high-bandwidth communication.  It's clear to myself and other 
attendees just how valuable the recent mid-cycles were in terms of making 
technical decisions and building the relationships to support their 
implementation.  Maybe it isn't sustainable over the long-term to meet so 
often, but I don't think that should preclude us from deriving benefit in the 
short-term.  I also don't think we should ignore the opportunity for more 
effective decision-making on the grounds that not everyone can directly 
participate.  Not everyone is able to attend summit, but it is nonetheless a 
critical part of our community's decision-making process. The topic lists for a 
mid-cycle are published beforehand, just like summit, to allow non-attendees 
the chance to present their views in advance and/or designate one or more 
attendees to advocate on 
 their behalf.  It's not perfect, but the alternative - not holding mid-cycles 
- would seem to be a case of throwing out the baby with the bathwater.


Maru

 
 Given that we consider these physical events so important, I'd like
 people to let me know if they have travel funding issues. I can then
 approach the Foundation about funding travel if that is required.
 
 Travel funding is certainly an issue, but I'm not sure that Foundation
 funding would be a solution, because the impact probably isn't directly
 on the core devs. Speaking with my Red Hat on, if the midcycle meetup
 is important enough, the core devs will likely get the funding to attend.
 The fallout of this though is that every attendee at a mid-cycle summit
 

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

2014-08-13 Thread Daniel P. Berrange
On Wed, Aug 13, 2014 at 09:18:09AM -0700, Maru Newby wrote:
 
 On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
 
  On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
  Hi.
  
  One of the action items from the nova midcycle was that I was asked to
  make nova's expectations of core reviews more clear. This email is an
  attempt at that.
  
  Nova expects a minimum level of sustained code reviews from cores. In
  the past this has been generally held to be in the order of two code
  reviews a day, which is a pretty low bar compared to the review
  workload of many cores. I feel that existing cores understand this
  requirement well, and I am mostly stating it here for completeness.
  
  Additionally, there is increasing levels of concern that cores need to
  be on the same page about the criteria we hold code to, as well as the
  overall direction of nova. While the weekly meetings help here, it was
  agreed that summit attendance is really important to cores. Its the
  way we decide where we're going for the next cycle, as well as a
  chance to make sure that people are all pulling in the same direction
  and trust each other.
  
  There is also a strong preference for midcycle meetup attendance,
  although I understand that can sometimes be hard to arrange. My stance
  is that I'd like core's to try to attend, but understand that
  sometimes people will miss one. In response to the increasing
  importance of midcycles over time, I commit to trying to get the dates
  for these events announced further in advance.
  
  Personally I'm going to find it really hard to justify long distance
  travel 4 times a year for OpenStack for personal / family reasons,
  let alone company cost. I couldn't attend Icehouse mid-cycle because
  I just had too much travel in a short time to be able to do another
  week long trip away from family. I couldn't attend Juno mid-cycle
  because it clashed we personal holiday. There are other opensource
  related conferences that I also have to attend (LinuxCon, FOSDEM,
  KVM Forum, etc), etc so doubling the expected number of openstack
  conferences from 2 to 4 is really very undesirable from my POV.
  I might be able to attend the occassional mid-cycle meetup if the
  location was convenient, but in general I don't see myself being
  able to attend them regularly.
  
  I tend to view the fact that we're emphasising the need of in-person
  meetups to be somewhat of an indication of failure of our community
  operation. The majority of open source projects work very effectively
  with far less face-to-face time. OpenStack is fortunate that companies
  are currently willing to spend 6/7-figure sums flying 1000's of
  developers around the world many times a year, but I don't see that
  lasting forever so I'm concerned about baking the idea of f2f midcycle
  meetups into our way of life even more strongly.
 
 I was fortunate to attend both the Nova and Neutron mid-cycles last
 month, and I can attest to how productive these gatherings were.
 Discussion moved quickly and misunderstandings were rapidly resolved.
 Informal ('water-cooler') conversation led to many interactions that
 might not otherwise have occurred.  Given your attendance of summit
 and other open source conferences, though, I'm assuming the value of
 f2f is not in question.

I'm not questioning the value of f2f - I'm questioning the idea of
doing f2f meetings sooo many times a year. OpenStack is very much
the outlier here among open source projects - the vast majority of
projects get along very well with much less f2f time and a far
smaller % of their contributors attend those f2f meetings that do
happen. So I really do question what is missing from OpenStack's
community interaction that makes us believe that having 4 f2f
meetings a year is critical to our success.

 Nothing good is ever free.  The financial cost and exclusionary
 nature of an in-person meetup should definitely be weighed against
 the opportunity for focused and high-bandwidth communication.  It's
 clear to myself and other attendees just how valuable the recent
 mid-cycles were in terms of making technical decisions and building
 the relationships to support their implementation.  Maybe it isn't
 sustainable over the long-term to meet so often, but I don't think
 that should preclude us from deriving benefit in the short-term.

As pointed out this benefit for core devs has a direct negative
impact on other non-core devs. I'm questioning whether this is
really a net win overall vs other approaches to collaboration.

 I also don't think we should ignore the opportunity for more
 effective decision-making on the grounds that not everyone
 can directly participate.  Not everyone is able to attend
 summit, but it is nonetheless a critical part of our
 community's decision-making process.  The topic lists for a
 mid-cycle are published beforehand, just like summit, to
 allow non-attendees the chance to present their 

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

2014-08-13 Thread Dan Smith
 I'm not questioning the value of f2f - I'm questioning the idea of
 doing f2f meetings sooo many times a year. OpenStack is very much
 the outlier here among open source projects - the vast majority of
 projects get along very well with much less f2f time and a far
 smaller % of their contributors attend those f2f meetings that do
 happen. So I really do question what is missing from OpenStack's
 community interaction that makes us believe that having 4 f2f
 meetings a year is critical to our success.

How many is too many? So far, I have found the midcycles to be extremely
productive -- productive in a way that we don't see at the summits, and
I think other attendees agree. Obviously if budgets start limiting them,
then we'll have to deal with it, but I don't want to stop meeting
preemptively. IMHO, the reasons to cut back would be:

- People leaving with a well, that was useless... feeling
- Not enough people able to travel to make it worthwhile

So far, neither of those have been outcomes of the midcycles we've had,
so I think we're doing okay.

The design summits are structured differently, where we see a lot more
diverse attendance because of the colocation with the user summit. It
doesn't lend itself well to long and in-depth discussions about specific
things, but it's very useful for what it gives us in the way of
exposure. We could try to have less of that at the summit and more
midcycle-ish time, but I think it's unlikely to achieve the same level
of usefulness in that environment.

Specifically, the lack of colocation with too many other projects has
been a benefit. This time, Mark and Maru where there from Neutron. Last
time, Mark from Neutron and the other Mark from Glance were there. If
they were having meetups in other rooms (like at summit) they wouldn't
have been there exposed to discussions that didn't seem like they'd have
a component for their participation, but did after all (re: nova and
glance and who should own flavors).

 As pointed out this benefit for core devs has a direct negative
 impact on other non-core devs. I'm questioning whether this is
 really a net win overall vs other approaches to collaboration.

It's a net win, IMHO.

 As I explain in the rest of my email below I'm not advocating
 getting rid of mid-cycle events entirely. I'm suggesting that
 we can attain a reasonable % of the benefits of f2f meetings
 by doing more formal virtual meetups and so be more efficient
 and inclusive overall.

I'd love to see more high-bandwidth mechanisms used to have discussions
in between f2f meetings. In fact, one of the outcomes of this last
midcycle was that we should have one about APIv3 with the folks that
couldn't attend for other reasons. It came up specifically because we
made more progress in ninety minutes than we had in the previous eight
months (yes, even with a design summit in the middle of that).

Expecting cores to be at these sorts of things seems pretty reasonable
to me, given the usefulness (and gravity) of the discussions we've been
having so far. Companies with more cores will have to send more or make
some hard decisions, but I don't want to cut back on the meetings until
their value becomes unjustified.

--Dan



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Russell Bryant
On 08/13/2014 01:09 PM, Dan Smith wrote:
 Expecting cores to be at these sorts of things seems pretty reasonable
 to me, given the usefulness (and gravity) of the discussions we've been
 having so far. Companies with more cores will have to send more or make
 some hard decisions, but I don't want to cut back on the meetings until
 their value becomes unjustified.

I disagree.  IMO, *expecting* people to travel, potentially across the
globe, 4 times a year is an unreasonable expectation, and quite
uncharacteristic of open source projects.  If we can't figure out a way
to have the most important conversations in a way that is inclusive of
everyone, we're failing with our processes.

By all means, if a subset wants to meet up and make progress on some
things, I think that's fine.  I don't think anyone think it's not
useful.  However, discussions need to be summarized and taken back to
the list for discussion before decisions are made.  That's not the way
things are trending here, and I think that's a problem.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Mike Bayer

On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/13/2014 01:09 PM, Dan Smith wrote:
 Expecting cores to be at these sorts of things seems pretty reasonable
 to me, given the usefulness (and gravity) of the discussions we've been
 having so far. Companies with more cores will have to send more or make
 some hard decisions, but I don't want to cut back on the meetings until
 their value becomes unjustified.
 
 I disagree.  IMO, *expecting* people to travel, potentially across the
 globe, 4 times a year is an unreasonable expectation, and quite
 uncharacteristic of open source projects.  If we can't figure out a way
 to have the most important conversations in a way that is inclusive of
 everyone, we're failing with our processes.
 
 By all means, if a subset wants to meet up and make progress on some
 things, I think that's fine.  I don't think anyone think it's not
 useful.  However, discussions need to be summarized and taken back to
 the list for discussion before decisions are made.  That's not the way
 things are trending here, and I think that's a problem.

Count me in on the “not requiring travel” team here.   I have multiple issues 
with travel, including that it is very stressful and tends to ruin my 
productivity for weeks leading up to it, and lots of us also have family 
responsibilities that are difficult and potentially expensive to arrange for an 
absense, such as child care.

It’s difficult to compare OpenStack to other open source projects, in that it 
is on such a more massive and high velocity scale than almost any others 
(perhaps the Linux kernel is similar).   It is certainly true that F2F meetings 
encourage better communications and sparking of new ideas and directions that 
wouldn’t otherwise have occurred, but then again I will also suggest that the 
difference in collaborative productivities for different individuals between 
F2F and remote probably varies highly based on the individual, including their 
social proclivities, specific projects and focus, and working styles.In 
this sense I’m really voting for an “all of the above” approach, in that yes we 
should do what we can to facilitate travel, we should do what we can to 
facilitate remote meetings over conferences and I love the idea of telepresence 
meetups, and we should give room to those who are very productive remotely and 
have difficulties with regular travel. The telepresence idea in particular 
opens the door to people meeting up in a semi-F2F style many more than four 
times per year, in fact.  I wouldn’t mind at all going to an office every 
Friday to have our oslo.db meeting over a nice telepresence system.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Dan Smith
On 8/13/14 11:20 AM, Mike Bayer wrote:
 On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com
 wrote:
 I disagree.  IMO, *expecting* people to travel, potentially across
 the globe, 4 times a year is an unreasonable expectation, and
 quite uncharacteristic of open source projects.  If we can't figure
 out a way to have the most important conversations in a way that is
 inclusive of everyone, we're failing with our processes.
 
 By all means, if a subset wants to meet up and make progress on
 some things, I think that's fine.  I don't think anyone think it's
 not useful.

Well, it doesn't seem at all excessive to me, given the rate and volume
at which we do things around here. That said, if a significant number of
cores think it's not doable, then I guess that's a data point.

From what you said above, it sounds like you're okay with the meetings
but not the requirement for cores. I said expect above -- is that a
reasonable thing? Expect them to be present, unless they have a reason
not to be there? Reasons could be personal or preference, but hopefully
not I never come to midcycles because $reason.

 It’s difficult to compare OpenStack to other open source projects, in
 that it is on such a more massive and high velocity scale than almost
 any others (perhaps the Linux kernel is similar). 

Yeah, I have a hard time justifying anything by comparing us to other
projects. I've been involved with plenty and don't think any of them are
useful data points for what we should or should not do here in terms of
anything related to velocity :)

--Dan



signature.asc
Description: OpenPGP digital signature
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Russell Bryant
On 08/13/2014 02:33 PM, Dan Smith wrote:
 On 8/13/14 11:20 AM, Mike Bayer wrote:
 On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com
 wrote:
 I disagree.  IMO, *expecting* people to travel, potentially across
 the globe, 4 times a year is an unreasonable expectation, and
 quite uncharacteristic of open source projects.  If we can't figure
 out a way to have the most important conversations in a way that is
 inclusive of everyone, we're failing with our processes.

 By all means, if a subset wants to meet up and make progress on
 some things, I think that's fine.  I don't think anyone think it's
 not useful.
 
 Well, it doesn't seem at all excessive to me, given the rate and volume
 at which we do things around here. That said, if a significant number of
 cores think it's not doable, then I guess that's a data point.
 
 From what you said above, it sounds like you're okay with the meetings
 but not the requirement for cores. I said expect above -- is that a
 reasonable thing? Expect them to be present, unless they have a reason
 not to be there? Reasons could be personal or preference, but hopefully
 not I never come to midcycles because $reason.
 
 It’s difficult to compare OpenStack to other open source projects, in
 that it is on such a more massive and high velocity scale than almost
 any others (perhaps the Linux kernel is similar). 
 
 Yeah, I have a hard time justifying anything by comparing us to other
 projects. I've been involved with plenty and don't think any of them are
 useful data points for what we should or should not do here in terms of
 anything related to velocity :)

I think we also need to be careful with not continuing to increase
expectations because of velocity.  Burnout is a real problem.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Russell Bryant
On 08/13/2014 02:44 PM, Russell Bryant wrote:
 On 08/13/2014 02:33 PM, Dan Smith wrote:
 On 8/13/14 11:20 AM, Mike Bayer wrote:
 On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com
 wrote:
 I disagree.  IMO, *expecting* people to travel, potentially across
 the globe, 4 times a year is an unreasonable expectation, and
 quite uncharacteristic of open source projects.  If we can't figure
 out a way to have the most important conversations in a way that is
 inclusive of everyone, we're failing with our processes.

 By all means, if a subset wants to meet up and make progress on
 some things, I think that's fine.  I don't think anyone think it's
 not useful.

 Well, it doesn't seem at all excessive to me, given the rate and volume
 at which we do things around here. That said, if a significant number of
 cores think it's not doable, then I guess that's a data point.

 From what you said above, it sounds like you're okay with the meetings
 but not the requirement for cores. I said expect above -- is that a
 reasonable thing? Expect them to be present, unless they have a reason
 not to be there? Reasons could be personal or preference, but hopefully
 not I never come to midcycles because $reason.

 It’s difficult to compare OpenStack to other open source projects, in
 that it is on such a more massive and high velocity scale than almost
 any others (perhaps the Linux kernel is similar). 

 Yeah, I have a hard time justifying anything by comparing us to other
 projects. I've been involved with plenty and don't think any of them are
 useful data points for what we should or should not do here in terms of
 anything related to velocity :)
 
 I think we also need to be careful with not continuing to increase
 expectations because of velocity.  Burnout is a real problem.
 

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.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Doug Hellmann

On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote:

 On 08/13/2014 02:44 PM, Russell Bryant wrote:
 On 08/13/2014 02:33 PM, Dan Smith wrote:
 On 8/13/14 11:20 AM, Mike Bayer wrote:
 On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com
 wrote:
 I disagree.  IMO, *expecting* people to travel, potentially across
 the globe, 4 times a year is an unreasonable expectation, and
 quite uncharacteristic of open source projects.  If we can't figure
 out a way to have the most important conversations in a way that is
 inclusive of everyone, we're failing with our processes.
 
 By all means, if a subset wants to meet up and make progress on
 some things, I think that's fine.  I don't think anyone think it's
 not useful.
 
 Well, it doesn't seem at all excessive to me, given the rate and volume
 at which we do things around here. That said, if a significant number of
 cores think it's not doable, then I guess that's a data point.
 
 From what you said above, it sounds like you're okay with the meetings
 but not the requirement for cores. I said expect above -- is that a
 reasonable thing? Expect them to be present, unless they have a reason
 not to be there? Reasons could be personal or preference, but hopefully
 not I never come to midcycles because $reason.
 
 It’s difficult to compare OpenStack to other open source projects, in
 that it is on such a more massive and high velocity scale than almost
 any others (perhaps the Linux kernel is similar). 
 
 Yeah, I have a hard time justifying anything by comparing us to other
 projects. I've been involved with plenty and don't think any of them are
 useful data points for what we should or should not do here in terms of
 anything related to velocity :)
 
 I think we also need to be careful with not continuing to increase
 expectations because of velocity.  Burnout is a real problem.
 
 
 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.
 
 -- 
 Russell Bryant


+1, well said.

Doug


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Michael Still
On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote:
 I'm not questioning the value of f2f - I'm questioning the idea of
 doing f2f meetings sooo many times a year. OpenStack is very much
 the outlier here among open source projects - the vast majority of
 projects get along very well with much less f2f time and a far
 smaller % of their contributors attend those f2f meetings that do
 happen. So I really do question what is missing from OpenStack's
 community interaction that makes us believe that having 4 f2f
 meetings a year is critical to our success.

 How many is too many? So far, I have found the midcycles to be extremely
 productive -- productive in a way that we don't see at the summits, and
 I think other attendees agree. Obviously if budgets start limiting them,
 then we'll have to deal with it, but I don't want to stop meeting
 preemptively.

I agree they're very productive. Let's pick on the nova v3 API case as
an example... We had failed as a community to reach a consensus using
our existing discussion mechanisms (hundreds of emails, at least three
specs, phone calls between the various parties, et cetera), yet at the
summit and then a midcycle meetup we managed to nail down an agreement
on a very contentious and complicated topic.

I can see the argument that travel cost is an issue, but I think its
also not a very strong argument. We have companies spending millions
of dollars on OpenStack -- surely spending a relatively small amount
on travel to keep the development team as efficient as possible isn't
a big deal? I wouldn't be at all surprised if the financial costs of
the v3 API debate (staff time mainly) were much higher than the travel
costs of those involved in the summit and midcycle discussions which
sorted it out.

Travelling to places to talk to people isn't a great solution, but it
is the most effective one we've found so far. We should continue to
experiment with other options, but until we find something that works
as well as meetups, I think we need to keep having them.

 IMHO, the reasons to cut back would be:

 - People leaving with a well, that was useless... feeling
 - Not enough people able to travel to make it worthwhile

 So far, neither of those have been outcomes of the midcycles we've had,
 so I think we're doing okay.

 The design summits are structured differently, where we see a lot more
 diverse attendance because of the colocation with the user summit. It
 doesn't lend itself well to long and in-depth discussions about specific
 things, but it's very useful for what it gives us in the way of
 exposure. We could try to have less of that at the summit and more
 midcycle-ish time, but I think it's unlikely to achieve the same level
 of usefulness in that environment.

 Specifically, the lack of colocation with too many other projects has
 been a benefit. This time, Mark and Maru where there from Neutron. Last
 time, Mark from Neutron and the other Mark from Glance were there. If
 they were having meetups in other rooms (like at summit) they wouldn't
 have been there exposed to discussions that didn't seem like they'd have
 a component for their participation, but did after all (re: nova and
 glance and who should own flavors).

I agree. The ability to focus on the issues that were blocking nova
was very important. That's hard to do at a design summit when there is
so much happening at the same time.

 As pointed out this benefit for core devs has a direct negative
 impact on other non-core devs. I'm questioning whether this is
 really a net win overall vs other approaches to collaboration.

 It's a net win, IMHO.

 As I explain in the rest of my email below I'm not advocating
 getting rid of mid-cycle events entirely. I'm suggesting that
 we can attain a reasonable % of the benefits of f2f meetings
 by doing more formal virtual meetups and so be more efficient
 and inclusive overall.

 I'd love to see more high-bandwidth mechanisms used to have discussions
 in between f2f meetings. In fact, one of the outcomes of this last
 midcycle was that we should have one about APIv3 with the folks that
 couldn't attend for other reasons. It came up specifically because we
 made more progress in ninety minutes than we had in the previous eight
 months (yes, even with a design summit in the middle of that).

 Expecting cores to be at these sorts of things seems pretty reasonable
 to me, given the usefulness (and gravity) of the discussions we've been
 having so far. Companies with more cores will have to send more or make
 some hard decisions, but I don't want to cut back on the meetings until
 their value becomes unjustified.

I think this gets to the crux of the original email -- we are
increasingly needing cores to understand the overall direction nova is
going. You could argue for example that our failure to land many high
priority blueprints in Juno is because cores aren't acting in
coordinated a manner. So, we're attempting to come up with ways to
improve 

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

2014-08-13 Thread Michael Still
On Thu, Aug 14, 2014 at 3:44 AM, Russell Bryant rbry...@redhat.com wrote:
 On 08/13/2014 01:09 PM, Dan Smith wrote:
 Expecting cores to be at these sorts of things seems pretty reasonable
 to me, given the usefulness (and gravity) of the discussions we've been
 having so far. Companies with more cores will have to send more or make
 some hard decisions, but I don't want to cut back on the meetings until
 their value becomes unjustified.

 I disagree.  IMO, *expecting* people to travel, potentially across the
 globe, 4 times a year is an unreasonable expectation, and quite
 uncharacteristic of open source projects.  If we can't figure out a way
 to have the most important conversations in a way that is inclusive of
 everyone, we're failing with our processes.

I am a bit confused by this stance to be honest. You yourself said
when you were Icehouse PTL that you wanted cores to come to the
summit. What changed?

 By all means, if a subset wants to meet up and make progress on some
 things, I think that's fine.  I don't think anyone think it's not
 useful.  However, discussions need to be summarized and taken back to
 the list for discussion before decisions are made.  That's not the way
 things are trending here, and I think that's a problem.

The etherpad for the meetup has extensive notes. Any summary I write
will basically be those notes in prose. What are you looking for in a
summary that isn't in the etherpad? There also wasn't a summary of the
Icehouse midcycle produced that I can find. Whilst I am happy to do
one for Juno, its a requirement that I hadn't planned for, and is
therefore taking me some time to retrofit.

I think we should chalk the request for summaries up experience and
talk through how to better provide such things at future meetups.

Michael

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Robert Collins
On 14 August 2014 05:44, Russell Bryant rbry...@redhat.com wrote:

 By all means, if a subset wants to meet up and make progress on some
 things, I think that's fine.  I don't think anyone think it's not
 useful.  However, discussions need to be summarized and taken back to
 the list for discussion before decisions are made.  That's not the way
 things are trending here, and I think that's a problem.

Just to note, in the TripleO meetup we explicitly deferred most things
- all things which we'd seek consensus on in the first place - back to
the list for further discussion, once we had rough consensus at the
f2f.

-Rob

-- 
Robert Collins rbtcoll...@hp.com
Distinguished Technologist
HP Converged Cloud

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Jay Pipes

On 08/12/2014 06:57 PM, Michael Still wrote:

Hi.

One of the action items from the nova midcycle was that I was asked to
make nova's expectations of core reviews more clear. This email is an
attempt at that.

Nova expects a minimum level of sustained code reviews from cores. In
the past this has been generally held to be in the order of two code
reviews a day, which is a pretty low bar compared to the review
workload of many cores. I feel that existing cores understand this
requirement well, and I am mostly stating it here for completeness.

Additionally, there is increasing levels of concern that cores need to
be on the same page about the criteria we hold code to, as well as the
overall direction of nova. While the weekly meetings help here, it was
agreed that summit attendance is really important to cores. Its the
way we decide where we're going for the next cycle, as well as a
chance to make sure that people are all pulling in the same direction
and trust each other.

There is also a strong preference for midcycle meetup attendance,
although I understand that can sometimes be hard to arrange. My stance
is that I'd like core's to try to attend, but understand that
sometimes people will miss one. In response to the increasing
importance of midcycles over time, I commit to trying to get the dates
for these events announced further in advance.

Given that we consider these physical events so important, I'd like
people to let me know if they have travel funding issues. I can then
approach the Foundation about funding travel if that is required.


Just wanted to quickly weigh in with my thoughts on this important 
topic. I very much valued the face-to-face interaction that came from 
the mid-cycle meetup in Beaverton (it was the only one I've ever been to).


That said, I do not believe it should be a requirement that cores make 
it to the face-to-face meetings in-person. A number of folks have 
brought up very valid concerns about personal/family time, travel costs 
and burnout.


I believe that the issue raised about furthering the divide between core 
and non-core folks is actually the biggest reason I don't support a 
mandate to have cores at the face-to-face meetings, and I think we 
should make our best efforts to support quality virtual meetings that 
can be done on a more frequent basis than the face-to-face meetings that 
would be optional.


Best,
-jay


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Michael Still
On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:

 Just wanted to quickly weigh in with my thoughts on this important topic. I
 very much valued the face-to-face interaction that came from the mid-cycle
 meetup in Beaverton (it was the only one I've ever been to).

 That said, I do not believe it should be a requirement that cores make it to
 the face-to-face meetings in-person. A number of folks have brought up very
 valid concerns about personal/family time, travel costs and burnout.

I'm not proposing they be a requirement. I am proposing that they be
strongly encouraged.

 I believe that the issue raised about furthering the divide between core and
 non-core folks is actually the biggest reason I don't support a mandate to
 have cores at the face-to-face meetings, and I think we should make our best
 efforts to support quality virtual meetings that can be done on a more
 frequent basis than the face-to-face meetings that would be optional.

I am all for online meetings, but we don't have a practical way to do
them at the moment apart from IRC. Until someone has a concrete
proposal that's been shown to work, I feel its a straw man argument.

Michael

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Joe Gordon
On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com wrote:

 On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:

  Just wanted to quickly weigh in with my thoughts on this important
 topic. I
  very much valued the face-to-face interaction that came from the
 mid-cycle
  meetup in Beaverton (it was the only one I've ever been to).
 
  That said, I do not believe it should be a requirement that cores make
 it to
  the face-to-face meetings in-person. A number of folks have brought up
 very
  valid concerns about personal/family time, travel costs and burnout.

 I'm not proposing they be a requirement. I am proposing that they be
 strongly encouraged.

  I believe that the issue raised about furthering the divide between core
 and
  non-core folks is actually the biggest reason I don't support a mandate
 to
  have cores at the face-to-face meetings, and I think we should make our
 best
  efforts to support quality virtual meetings that can be done on a more
  frequent basis than the face-to-face meetings that would be optional.

 I am all for online meetings, but we don't have a practical way to do
 them at the moment apart from IRC. Until someone has a concrete
 proposal that's been shown to work, I feel its a straw man argument.


What about making it easier for remote people to participate at the
mid-cycle meetups? Set up some microphones and a Google hangout?  At least
that way attending the mid-cycle is not all or nothing.

We did something like this last cycle (IIRC we didn't have enough mics) and
it worked pretty well.



 Michael

 --
 Rackspace Australia

 ___
 OpenStack-dev mailing list
 OpenStack-dev@lists.openstack.org
 http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


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

2014-08-13 Thread Michael Still
On Thu, Aug 14, 2014 at 2:48 PM, Joe Gordon joe.gord...@gmail.com wrote:
 On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com wrote:
 On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote:

  Just wanted to quickly weigh in with my thoughts on this important
  topic. I
  very much valued the face-to-face interaction that came from the
  mid-cycle
  meetup in Beaverton (it was the only one I've ever been to).
 
  That said, I do not believe it should be a requirement that cores make
  it to
  the face-to-face meetings in-person. A number of folks have brought up
  very
  valid concerns about personal/family time, travel costs and burnout.

 I'm not proposing they be a requirement. I am proposing that they be
 strongly encouraged.

  I believe that the issue raised about furthering the divide between core
  and
  non-core folks is actually the biggest reason I don't support a mandate
  to
  have cores at the face-to-face meetings, and I think we should make our
  best
  efforts to support quality virtual meetings that can be done on a more
  frequent basis than the face-to-face meetings that would be optional.

 I am all for online meetings, but we don't have a practical way to do
 them at the moment apart from IRC. Until someone has a concrete
 proposal that's been shown to work, I feel its a straw man argument.

 What about making it easier for remote people to participate at the
 mid-cycle meetups? Set up some microphones and a Google hangout?  At least
 that way attending the mid-cycle is not all or nothing.

 We did something like this last cycle (IIRC we didn't have enough mics) and
 it worked pretty well.

As I said, I'm open to experimenting, but I need someone other than me
to own that. I'm simply too busy to get to it.

However, I don't think we should throw away the thing that works for
best for us now, until we have a working replacement. I'm very much in
favour of work being done on a replacement though.

Michael

-- 
Rackspace Australia

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev