Re: [openstack-dev] [all] A proposal to separate the design summit

[Jeremy Stanley]

On 2016-02-29 15:03:19 -0800 (-0800), James Bottomley wrote:
[...]
> it sounds like an an expectation that people who aren't gamers
> would submit more than one patch and, indeed, become part of the
> developer base. I wanted to explain why there's a significant set
> of people who legitimately only submit a single patch and who
> won't really ever become developers.

Some rough curve-fitting was performed based off per-contributor
patch counts over a cycle and the observation was that single-patch
contributors were a significant positive deviation. The model
suggested that we'd have somewhere around 10% fewer active
contributors in a cycle if we calculated the single-patch
contributor projection based on the counts of contributors with an
increasing number of merged patches that cycle. This was used as
justification not to increase the minimum patch requirement for a
free summit pass, since the prediction was that would simply move
the 10% bump to whatever the minimum number of patches was to
qualify.

What I'd love to do, but have yet to find the time, is perform a
more detailed analysis and model incorporating a mapping of which
contributors exercised their free admission. This would provide a
far more accurate picture of whether people are really contributing
just one patch so they can save US$600 on conference admission, or
whether we have a disproportionate number of single-patch
contributors for some other more serious reason. Honestly, if the
rough model turns out to be true, then serving 90% in the way we
intended with only 10% freeloading seems fine to me (as long as
people who have no real intention of contributing stay out of design
sessions and let the rest of us get work done).
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jonathan D. Proulx]

On Wed, Mar 02, 2016 at 04:11:48PM +, Alexis Lee wrote:
:Walter A. Boring IV said on Mon, Feb 22, 2016 at 11:47:16AM -0800:
:> I'm trying to follow this here.   If we want all of the projects in
:> the same location to hold a design summit, then all of the
:> contributors are still going to have to do international travel,
:> which is the primary cost for attendees.
:
:My understanding is that hotel cost tends to dwarf flight cost. Capital
:city hotels tend to be (much) more expensive than provincial ones, so
:moving to less glamorous locations could noticeably reduce the total
:outlay.
:
:EG 750 flight + 300/night hotel * 5 nights = 2050
:   750 flight + 100/night hotel * 5 nights = 1250
:
:(figures are approx)

Not sure howmuch cost optimization is reasonable to attempt.  It is
true hotel costs in the current arrangement have been a multiple of
flight costs for me at least.

It's also true that hotels in secondary cities tend to be cheaper (not
sure if they're 1/3 though).

If we are going to consider detailed costs, we should also consider
that flights to secondary cities are more expensive.

A semi random pricing comparison of Manchester -vs- London from Boston
USA (picked the dates of Austin summit since that about the time
distance I book things for)

BOS->LHR $900 (nonstop) + London hotel ($250 * 5)  = $2150
BOS->MAN $1200 (1 stop) + Manchester hotel ($120 * 5 ) = $1800

So it is cheaper but $350 on a week's travel isn't a stay or go choice
here.  For different city pairs and times this will all move around
so with out more detailed comparisons this is still pretty sloppy but
I don't think the cost different enough to be significant.

I think availible facilities and local OpenStack community should be
larger factors in location selection than this level of travel cost
optimization.

-Jon


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Alexis Lee]

Walter A. Boring IV said on Mon, Feb 22, 2016 at 11:47:16AM -0800:
> I'm trying to follow this here.   If we want all of the projects in
> the same location to hold a design summit, then all of the
> contributors are still going to have to do international travel,
> which is the primary cost for attendees.

My understanding is that hotel cost tends to dwarf flight cost. Capital
city hotels tend to be (much) more expensive than provincial ones, so
moving to less glamorous locations could noticeably reduce the total
outlay.

EG 750 flight + 300/night hotel * 5 nights = 2050
   750 flight + 100/night hotel * 5 nights = 1250

(figures are approx)


Alexis (lxsli)
-- 
Nova developer, Hewlett-Packard Limited.
Registered Office: Cain Road, Bracknell, Berkshire RG12 1HN.
Registered Number: 00690597 England
VAT number: GB 314 1496 79

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Adam Lawson]

After reading through this, it seems to me like Anita is frustrated with
the motivation among those who submit one patch because of her perception
that they are doing so only to take advantage of a free ticket and by
extension, crowding rooms that affects her ability to hear/engage
effectively. I understand the desire to engage more (for lack of better
term) but reaching beyond someone's contribution and openly suggest they
are not contributing for the right reasons isn't anyone'e concern to be
perfectly frank.

Aside from that, I don't think anyone is taking advantage of anything if
they earn a free ticket to an OpenStack Summit by fulfilling the needful
requirements. If they submit a patch, OpenStack becomes better and the
contributor is entitled to a free ticket to the next Summit. I fail to see
a single downside in that.

Tough love: "gaming" within the context of those who submit one patch,
making remarks about a perceived dishonorable motivation of our peers; that
level of discourse among peers is simply damaging.

//adam


*Adam Lawson*

AQORN, Inc.
427 North Tatnall Street
Ste. 58461
Wilmington, Delaware 19801-2230
Toll-free: (844) 4-AQORN-NOW ext. 101
International: +1 302-387-4660
Direct: +1 916-246-2072

On Tue, Mar 1, 2016 at 2:08 PM, Chris Friesen 
wrote:

> On 03/01/2016 03:52 PM, Clint Byrum wrote:
>
>> Excerpts from Eoghan Glynn's message of 2016-03-01 02:08:00 -0800:
>>
>
> There are a whole slew of folks who work fulltime on OpenStack but
>>> contribute mainly in the background: operating clouds, managing
>>> engineering teams, supporting customers, designing product roadmaps,
>>> training new users etc. TBH we should be flattered that the design
>>> summit sessions are interesting and engaging enough to also attract
>>> some of that sort of audience, as well as the core contributors of
>>> code. If those interested folks happen to also have the gumption to
>>> earn an ATC pass by meeting the threshold for contributor activity,
>>> then good for them! As long as no-one is actively derailing the
>>> discussion, I don't see much of an issue with the current mix of
>>> attendees.
>>>
>>>
>> I think you're right on all of these points. However, what you might
>> not have considered is that _the sheer number of people in the room_
>> can derail the productivity of a group of developers arguing complicated
>> points. It's not that we want to be operating in the shadows; it is that
>> we want to be operating in a safe, creative environment. A room with 5
>> friends, 5 acquaintances, and 100 strangers, is not that. But if there
>> are only, say, 15 strangers, one can take the time to get to know those
>> people, to understand their needs, and make far more progress and be
>> far more inclusive in discussions.
>>
>> What we want is for people to be attending and participating _on
>> purpose_.
>>
>
> I think it's pretty unlikely that people would attend the developer summit
> sessions by accident.  :)
>
> It kind of sounds to me like you want to limit the number of 'tourists'
> that aren't actively involved in the issues being discussed, but are just
> there to observe.  Or am I misinterpreting?
>
> Chris
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Chris Friesen]

On 03/01/2016 03:52 PM, Clint Byrum wrote:

Excerpts from Eoghan Glynn's message of 2016-03-01 02:08:00 -0800:



There are a whole slew of folks who work fulltime on OpenStack but
contribute mainly in the background: operating clouds, managing
engineering teams, supporting customers, designing product roadmaps,
training new users etc. TBH we should be flattered that the design
summit sessions are interesting and engaging enough to also attract
some of that sort of audience, as well as the core contributors of
code. If those interested folks happen to also have the gumption to
earn an ATC pass by meeting the threshold for contributor activity,
then good for them! As long as no-one is actively derailing the
discussion, I don't see much of an issue with the current mix of
attendees.



I think you're right on all of these points. However, what you might
not have considered is that _the sheer number of people in the room_
can derail the productivity of a group of developers arguing complicated
points. It's not that we want to be operating in the shadows; it is that
we want to be operating in a safe, creative environment. A room with 5
friends, 5 acquaintances, and 100 strangers, is not that. But if there
are only, say, 15 strangers, one can take the time to get to know those
people, to understand their needs, and make far more progress and be
far more inclusive in discussions.

What we want is for people to be attending and participating _on
purpose_.


I think it's pretty unlikely that people would attend the developer summit 
sessions by accident.  :)


It kind of sounds to me like you want to limit the number of 'tourists' that 
aren't actively involved in the issues being discussed, but are just there to 
observe.  Or am I misinterpreting?


Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 03/01/2016 04:30 PM, Chris Friesen wrote:
> On 03/01/2016 09:03 AM, Anita Kuno wrote:
>> On 03/01/2016 05:08 AM, Eoghan Glynn wrote:
> 
>> In Vancouver I happened to be sitting behind someone who stated "I'm
>> just here for the buzz." Which is lovely for that person. The
>> problem is
>> that the buzz that person is there for is partially created by me
>> and I
>> create it and mean to offer it to people who will return it in
>> kind, not
>> just soak it up and keep it to themselves.
>>
> I don't know if drive-by attendance at design summit sessions by
> under-
> qualified or uninformed summiteers is encouraged by the
> availability of
> ATC passes. But as long as those individuals aren't actively derailing
> the conversation in sessions, I wouldn't consider their buzz
> soakage as
> a major issue TBH.
>
 Folks who want to help (even if they don't know how yet) carry an
 energy
 of intention with them which is nourishing to be around. Folks who are
 trying to get in the door and not be expected to help and hope noone
 notices carry an entirely different kind of energy with them. It is a
 non-nourishing energy.
>>>
>>> Personally I don't buy into that notion of the wrong sort of people
>>> sneaking in the door of summit, keeping their heads down and hoping
>>> no-one notices.
> 
> 
> 
>>> TBH we should be flattered that the design
>>> summit sessions are interesting and engaging enough to also attract
>>> some of that sort of audience, as well as the core contributors of
>>> code. If those interested folks happen to also have the gumption to
>>> earn an ATC pass by meeting the threshold for contributor activity,
>>> then good for them! As long as no-one is actively derailing the
>>> discussion, I don't see much of an issue with the current mix of
>>> attendees.
>>
>> Yeah, I don't feel you have understood what my point is, and that is
>> fine. We did put forward an attempt to communicate and it failed. We
>> will have other opportunities on other issues in the future.
> 
> I don't think it's so much a failure to communicate, but rather simply a
> failure to arrive at a consensus.  As I see it, Eoghan understands your
> point but does not feel the same way.

No anyone who believes that my position includes dishonouring users
isn't understanding my point.

Thanks,
Anita.

> 
> Chris
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Clint Byrum]

Excerpts from Eoghan Glynn's message of 2016-03-01 02:08:00 -0800:
> 
> > > Current thinking would be to give preferential rates to access the 
> > > main
> > > summit to people who are present to other events (like this new
> > > separated contributors-oriented event, or Ops midcycle(s)). That would
> > > allow for a wider definition of "active community member" and reduce
> > > gaming.
> > >
> > 
> >  I think reducing gaming is important. It is valuable to include those
> >  folks who wish to make a contribution to OpenStack, I have confidence
> >  the next iteration of entry structure will try to more accurately
> >  identify those folks who bring value to OpenStack.
> > >>>
> > >>> There have been a couple references to "gaming" on this thread, which
> > >>> seem to imply a certain degree of dishonesty, in the sense of bending
> > >>> the rules.
> > >>>
> > >>> Can anyone who has used the phrase clarify:
> > >>>
> > >>>  (a) what exactly they mean by gaming in this context
> > >>>
> > >>> and:
> > >>>
> > >>>  (b) why they think this is a clear & present problem demanding a
> > >>>  solution?
> > >>>
> > >>> For the record, landing a small number of patches per cycle and thus
> > >>> earning an ATC summit pass as a result is not, IMO at least, gaming.
> > >>>
> > >>> Instead, it's called *contributing*.
> > >>>
> > >>> (on a small scale, but contributing none-the-less).
> > >>>
> > >>> Cheers,
> > >>> Eoghan
> > >>
> > >> Sure I can tell you what I mean.
> > >>
> > >> In Vancouver I happened to be sitting behind someone who stated "I'm
> > >> just here for the buzz." Which is lovely for that person. The problem is
> > >> that the buzz that person is there for is partially created by me and I
> > >> create it and mean to offer it to people who will return it in kind, not
> > >> just soak it up and keep it to themselves.
> > >>
> > >> Now I have no way of knowing who this person is and how they arrived at
> > >> the event. But the numbers for people offering one patch to OpenStack
> > >> (the bar for a summit pass) is significantly higher than the curve of
> > >> people offering two, three or four patches to OpenStack (patches that
> > >> are accepted and merged). So some folks are doing the minimum to get a
> > >> summit pass rather than being part of the cohort that has their first
> > >> patch to OpenStack as a means of offering their second patch to 
> > >> OpenStack.
> > >>
> > >> I consider it an honour and a privilege that I get to work with so many
> > >> wonderful people everyday who are dedicated to making open source clouds
> > >> available for whoever would wish to have clouds. I'm more than a little
> > >> tired of having my energy drained by folks who enjoy feeding off of it
> > >> while making no effort to return beneficial energy in kind.
> > >>
> > >> So when I use the phrase gaming, this is the dynamic to which I refer.
> > > 
> > > Thanks for the response.
> > > 
> > > I don't know if drive-by attendance at design summit sessions by under-
> > > qualified or uninformed summiteers is encouraged by the availability of
> > > ATC passes. But as long as those individuals aren't actively derailing
> > > the conversation in sessions, I wouldn't consider their buzz soakage as
> > > a major issue TBH.
> > > 
> > > In any case, I would say that just meeting the bar for an ATC summit pass
> > > (by landing the required number of patches) is not bending the rules or
> > > misrepresenting in any way.
> > > 
> > > Even if specifically motivated by the ATC pass (as opposed to scratching
> > > a very specific itch) it's still simply an honest and rational response
> > > to an incentive offered by the foundation.
> > > 
> > > One could argue whether the incentive is mis-designed, but that doesn't
> > > IMO make a gamer of any contributor who simply meets the required 
> > > threshold
> > > of activity.
> > > 
> > > Cheers,
> > > Eoghan
> > > 
> > 
> > No I'm not saying that. I'm saying that the larger issue is one of
> > motivation.
> > 
> > Folks who want to help (even if they don't know how yet) carry an energy
> > of intention with them which is nourishing to be around. Folks who are
> > trying to get in the door and not be expected to help and hope noone
> > notices carry an entirely different kind of energy with them. It is a
> > non-nourishing energy.
> 
> Personally I don't buy into that notion of the wrong sort of people
> sneaking in the door of summit, keeping their heads down and hoping
> no-one notices.
> 
> We have an open community that conducts its business in public. Not
> wanting folks with the wrong sort of energy to be around when that
> business is being done, runs counter to our open ethos IMO.
> 
> There are a whole slew of folks who work fulltime on OpenStack but
> contribute mainly in the background: operating clouds, managing
> engineering teams, supporting customers, designing product roadmaps,
> training new users etc. TBH 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Chris Friesen]

On 03/01/2016 09:03 AM, Anita Kuno wrote:

On 03/01/2016 05:08 AM, Eoghan Glynn wrote:



In Vancouver I happened to be sitting behind someone who stated "I'm
just here for the buzz." Which is lovely for that person. The problem is
that the buzz that person is there for is partially created by me and I
create it and mean to offer it to people who will return it in kind, not
just soak it up and keep it to themselves.


I don't know if drive-by attendance at design summit sessions by under-
qualified or uninformed summiteers is encouraged by the availability of
ATC passes. But as long as those individuals aren't actively derailing
the conversation in sessions, I wouldn't consider their buzz soakage as
a major issue TBH.


Folks who want to help (even if they don't know how yet) carry an energy
of intention with them which is nourishing to be around. Folks who are
trying to get in the door and not be expected to help and hope noone
notices carry an entirely different kind of energy with them. It is a
non-nourishing energy.


Personally I don't buy into that notion of the wrong sort of people
sneaking in the door of summit, keeping their heads down and hoping
no-one notices.





TBH we should be flattered that the design
summit sessions are interesting and engaging enough to also attract
some of that sort of audience, as well as the core contributors of
code. If those interested folks happen to also have the gumption to
earn an ATC pass by meeting the threshold for contributor activity,
then good for them! As long as no-one is actively derailing the
discussion, I don't see much of an issue with the current mix of
attendees.


Yeah, I don't feel you have understood what my point is, and that is
fine. We did put forward an attempt to communicate and it failed. We
will have other opportunities on other issues in the future.


I don't think it's so much a failure to communicate, but rather simply a failure 
to arrive at a consensus.  As I see it, Eoghan understands your point but does 
not feel the same way.


Chris

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 03/01/2016 05:08 AM, Eoghan Glynn wrote:
> 
>>> Current thinking would be to give preferential rates to access the main
>>> summit to people who are present to other events (like this new
>>> separated contributors-oriented event, or Ops midcycle(s)). That would
>>> allow for a wider definition of "active community member" and reduce
>>> gaming.
>>>
>>
>> I think reducing gaming is important. It is valuable to include those
>> folks who wish to make a contribution to OpenStack, I have confidence
>> the next iteration of entry structure will try to more accurately
>> identify those folks who bring value to OpenStack.
>
> There have been a couple references to "gaming" on this thread, which
> seem to imply a certain degree of dishonesty, in the sense of bending
> the rules.
>
> Can anyone who has used the phrase clarify:
>
>  (a) what exactly they mean by gaming in this context
>
> and:
>
>  (b) why they think this is a clear & present problem demanding a
>  solution?
>
> For the record, landing a small number of patches per cycle and thus
> earning an ATC summit pass as a result is not, IMO at least, gaming.
>
> Instead, it's called *contributing*.
>
> (on a small scale, but contributing none-the-less).
>
> Cheers,
> Eoghan

 Sure I can tell you what I mean.

 In Vancouver I happened to be sitting behind someone who stated "I'm
 just here for the buzz." Which is lovely for that person. The problem is
 that the buzz that person is there for is partially created by me and I
 create it and mean to offer it to people who will return it in kind, not
 just soak it up and keep it to themselves.

 Now I have no way of knowing who this person is and how they arrived at
 the event. But the numbers for people offering one patch to OpenStack
 (the bar for a summit pass) is significantly higher than the curve of
 people offering two, three or four patches to OpenStack (patches that
 are accepted and merged). So some folks are doing the minimum to get a
 summit pass rather than being part of the cohort that has their first
 patch to OpenStack as a means of offering their second patch to OpenStack.

 I consider it an honour and a privilege that I get to work with so many
 wonderful people everyday who are dedicated to making open source clouds
 available for whoever would wish to have clouds. I'm more than a little
 tired of having my energy drained by folks who enjoy feeding off of it
 while making no effort to return beneficial energy in kind.

 So when I use the phrase gaming, this is the dynamic to which I refer.
>>>
>>> Thanks for the response.
>>>
>>> I don't know if drive-by attendance at design summit sessions by under-
>>> qualified or uninformed summiteers is encouraged by the availability of
>>> ATC passes. But as long as those individuals aren't actively derailing
>>> the conversation in sessions, I wouldn't consider their buzz soakage as
>>> a major issue TBH.
>>>
>>> In any case, I would say that just meeting the bar for an ATC summit pass
>>> (by landing the required number of patches) is not bending the rules or
>>> misrepresenting in any way.
>>>
>>> Even if specifically motivated by the ATC pass (as opposed to scratching
>>> a very specific itch) it's still simply an honest and rational response
>>> to an incentive offered by the foundation.
>>>
>>> One could argue whether the incentive is mis-designed, but that doesn't
>>> IMO make a gamer of any contributor who simply meets the required threshold
>>> of activity.
>>>
>>> Cheers,
>>> Eoghan
>>>
>>
>> No I'm not saying that. I'm saying that the larger issue is one of
>> motivation.
>>
>> Folks who want to help (even if they don't know how yet) carry an energy
>> of intention with them which is nourishing to be around. Folks who are
>> trying to get in the door and not be expected to help and hope noone
>> notices carry an entirely different kind of energy with them. It is a
>> non-nourishing energy.
> 
> Personally I don't buy into that notion of the wrong sort of people
> sneaking in the door of summit, keeping their heads down and hoping
> no-one notices.
> 
> We have an open community that conducts its business in public. Not
> wanting folks with the wrong sort of energy to be around when that
> business is being done, runs counter to our open ethos IMO.

That's fine. I guess we have a differing definition of what open means.

> 
> There are a whole slew of folks who work fulltime on OpenStack but
> contribute mainly in the background: operating clouds, managing
> engineering teams, supporting customers, designing product roadmaps,
> training new users etc.

I think you have completely misunderstood my point if you are
interpreting my words to mean I am dishonouring users.

> TBH we should be flattered that the 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Sylvain Bauza]

Le 01/03/2016 11:08, Eoghan Glynn a écrit :

Current thinking would be to give preferential rates to access the main
summit to people who are present to other events (like this new
separated contributors-oriented event, or Ops midcycle(s)). That would
allow for a wider definition of "active community member" and reduce
gaming.


I think reducing gaming is important. It is valuable to include those
folks who wish to make a contribution to OpenStack, I have confidence
the next iteration of entry structure will try to more accurately
identify those folks who bring value to OpenStack.

There have been a couple references to "gaming" on this thread, which
seem to imply a certain degree of dishonesty, in the sense of bending
the rules.

Can anyone who has used the phrase clarify:

  (a) what exactly they mean by gaming in this context

and:

  (b) why they think this is a clear & present problem demanding a
  solution?

For the record, landing a small number of patches per cycle and thus
earning an ATC summit pass as a result is not, IMO at least, gaming.

Instead, it's called *contributing*.

(on a small scale, but contributing none-the-less).

Cheers,
Eoghan

Sure I can tell you what I mean.

In Vancouver I happened to be sitting behind someone who stated "I'm
just here for the buzz." Which is lovely for that person. The problem is
that the buzz that person is there for is partially created by me and I
create it and mean to offer it to people who will return it in kind, not
just soak it up and keep it to themselves.

Now I have no way of knowing who this person is and how they arrived at
the event. But the numbers for people offering one patch to OpenStack
(the bar for a summit pass) is significantly higher than the curve of
people offering two, three or four patches to OpenStack (patches that
are accepted and merged). So some folks are doing the minimum to get a
summit pass rather than being part of the cohort that has their first
patch to OpenStack as a means of offering their second patch to OpenStack.

I consider it an honour and a privilege that I get to work with so many
wonderful people everyday who are dedicated to making open source clouds
available for whoever would wish to have clouds. I'm more than a little
tired of having my energy drained by folks who enjoy feeding off of it
while making no effort to return beneficial energy in kind.

So when I use the phrase gaming, this is the dynamic to which I refer.

Thanks for the response.

I don't know if drive-by attendance at design summit sessions by under-
qualified or uninformed summiteers is encouraged by the availability of
ATC passes. But as long as those individuals aren't actively derailing
the conversation in sessions, I wouldn't consider their buzz soakage as
a major issue TBH.

In any case, I would say that just meeting the bar for an ATC summit pass
(by landing the required number of patches) is not bending the rules or
misrepresenting in any way.

Even if specifically motivated by the ATC pass (as opposed to scratching
a very specific itch) it's still simply an honest and rational response
to an incentive offered by the foundation.

One could argue whether the incentive is mis-designed, but that doesn't
IMO make a gamer of any contributor who simply meets the required threshold
of activity.

Cheers,
Eoghan


No I'm not saying that. I'm saying that the larger issue is one of
motivation.

Folks who want to help (even if they don't know how yet) carry an energy
of intention with them which is nourishing to be around. Folks who are
trying to get in the door and not be expected to help and hope noone
notices carry an entirely different kind of energy with them. It is a
non-nourishing energy.

Personally I don't buy into that notion of the wrong sort of people
sneaking in the door of summit, keeping their heads down and hoping
no-one notices.

We have an open community that conducts its business in public. Not
wanting folks with the wrong sort of energy to be around when that
business is being done, runs counter to our open ethos IMO.

There are a whole slew of folks who work fulltime on OpenStack but
contribute mainly in the background: operating clouds, managing
engineering teams, supporting customers, designing product roadmaps,
training new users etc. TBH we should be flattered that the design
summit sessions are interesting and engaging enough to also attract
some of that sort of audience, as well as the core contributors of
code. If those interested folks happen to also have the gumption to
earn an ATC pass by meeting the threshold for contributor activity,
then good for them! As long as no-one is actively derailing the
discussion, I don't see much of an issue with the current mix of
attendees.


Excellent point. We are OpenStack, but "we" is not only the main 
upstream developers.
That's why I want to make sure that "we" is a team with all of us in a 
same venue.

That's also why we have keynotes, but "we" is not only us but their.

Re: [openstack-dev] [all] A proposal to separate the design summit

[Eoghan Glynn]

> > Current thinking would be to give preferential rates to access the main
> > summit to people who are present to other events (like this new
> > separated contributors-oriented event, or Ops midcycle(s)). That would
> > allow for a wider definition of "active community member" and reduce
> > gaming.
> >
> 
>  I think reducing gaming is important. It is valuable to include those
>  folks who wish to make a contribution to OpenStack, I have confidence
>  the next iteration of entry structure will try to more accurately
>  identify those folks who bring value to OpenStack.
> >>>
> >>> There have been a couple references to "gaming" on this thread, which
> >>> seem to imply a certain degree of dishonesty, in the sense of bending
> >>> the rules.
> >>>
> >>> Can anyone who has used the phrase clarify:
> >>>
> >>>  (a) what exactly they mean by gaming in this context
> >>>
> >>> and:
> >>>
> >>>  (b) why they think this is a clear & present problem demanding a
> >>>  solution?
> >>>
> >>> For the record, landing a small number of patches per cycle and thus
> >>> earning an ATC summit pass as a result is not, IMO at least, gaming.
> >>>
> >>> Instead, it's called *contributing*.
> >>>
> >>> (on a small scale, but contributing none-the-less).
> >>>
> >>> Cheers,
> >>> Eoghan
> >>
> >> Sure I can tell you what I mean.
> >>
> >> In Vancouver I happened to be sitting behind someone who stated "I'm
> >> just here for the buzz." Which is lovely for that person. The problem is
> >> that the buzz that person is there for is partially created by me and I
> >> create it and mean to offer it to people who will return it in kind, not
> >> just soak it up and keep it to themselves.
> >>
> >> Now I have no way of knowing who this person is and how they arrived at
> >> the event. But the numbers for people offering one patch to OpenStack
> >> (the bar for a summit pass) is significantly higher than the curve of
> >> people offering two, three or four patches to OpenStack (patches that
> >> are accepted and merged). So some folks are doing the minimum to get a
> >> summit pass rather than being part of the cohort that has their first
> >> patch to OpenStack as a means of offering their second patch to OpenStack.
> >>
> >> I consider it an honour and a privilege that I get to work with so many
> >> wonderful people everyday who are dedicated to making open source clouds
> >> available for whoever would wish to have clouds. I'm more than a little
> >> tired of having my energy drained by folks who enjoy feeding off of it
> >> while making no effort to return beneficial energy in kind.
> >>
> >> So when I use the phrase gaming, this is the dynamic to which I refer.
> > 
> > Thanks for the response.
> > 
> > I don't know if drive-by attendance at design summit sessions by under-
> > qualified or uninformed summiteers is encouraged by the availability of
> > ATC passes. But as long as those individuals aren't actively derailing
> > the conversation in sessions, I wouldn't consider their buzz soakage as
> > a major issue TBH.
> > 
> > In any case, I would say that just meeting the bar for an ATC summit pass
> > (by landing the required number of patches) is not bending the rules or
> > misrepresenting in any way.
> > 
> > Even if specifically motivated by the ATC pass (as opposed to scratching
> > a very specific itch) it's still simply an honest and rational response
> > to an incentive offered by the foundation.
> > 
> > One could argue whether the incentive is mis-designed, but that doesn't
> > IMO make a gamer of any contributor who simply meets the required threshold
> > of activity.
> > 
> > Cheers,
> > Eoghan
> > 
> 
> No I'm not saying that. I'm saying that the larger issue is one of
> motivation.
> 
> Folks who want to help (even if they don't know how yet) carry an energy
> of intention with them which is nourishing to be around. Folks who are
> trying to get in the door and not be expected to help and hope noone
> notices carry an entirely different kind of energy with them. It is a
> non-nourishing energy.

Personally I don't buy into that notion of the wrong sort of people
sneaking in the door of summit, keeping their heads down and hoping
no-one notices.

We have an open community that conducts its business in public. Not
wanting folks with the wrong sort of energy to be around when that
business is being done, runs counter to our open ethos IMO.

There are a whole slew of folks who work fulltime on OpenStack but
contribute mainly in the background: operating clouds, managing
engineering teams, supporting customers, designing product roadmaps,
training new users etc. TBH we should be flattered that the design
summit sessions are interesting and engaging enough to also attract
some of that sort of audience, as well as the core contributors of
code. If those interested folks happen to also have the gumption to
earn an ATC pass by meeting the threshold for contributor 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/29/2016 06:17 PM, Eoghan Glynn wrote:
> 
> 
> Current thinking would be to give preferential rates to access the main
> summit to people who are present to other events (like this new
> separated contributors-oriented event, or Ops midcycle(s)). That would
> allow for a wider definition of "active community member" and reduce
> gaming.
>

 I think reducing gaming is important. It is valuable to include those
 folks who wish to make a contribution to OpenStack, I have confidence
 the next iteration of entry structure will try to more accurately
 identify those folks who bring value to OpenStack.
>>>
>>> There have been a couple references to "gaming" on this thread, which
>>> seem to imply a certain degree of dishonesty, in the sense of bending
>>> the rules.
>>>
>>> Can anyone who has used the phrase clarify:
>>>
>>>  (a) what exactly they mean by gaming in this context
>>>
>>> and:
>>>
>>>  (b) why they think this is a clear & present problem demanding a
>>>  solution?
>>>
>>> For the record, landing a small number of patches per cycle and thus
>>> earning an ATC summit pass as a result is not, IMO at least, gaming.
>>>
>>> Instead, it's called *contributing*.
>>>
>>> (on a small scale, but contributing none-the-less).
>>>
>>> Cheers,
>>> Eoghan
>>
>> Sure I can tell you what I mean.
>>
>> In Vancouver I happened to be sitting behind someone who stated "I'm
>> just here for the buzz." Which is lovely for that person. The problem is
>> that the buzz that person is there for is partially created by me and I
>> create it and mean to offer it to people who will return it in kind, not
>> just soak it up and keep it to themselves.
>>
>> Now I have no way of knowing who this person is and how they arrived at
>> the event. But the numbers for people offering one patch to OpenStack
>> (the bar for a summit pass) is significantly higher than the curve of
>> people offering two, three or four patches to OpenStack (patches that
>> are accepted and merged). So some folks are doing the minimum to get a
>> summit pass rather than being part of the cohort that has their first
>> patch to OpenStack as a means of offering their second patch to OpenStack.
>>
>> I consider it an honour and a privilege that I get to work with so many
>> wonderful people everyday who are dedicated to making open source clouds
>> available for whoever would wish to have clouds. I'm more than a little
>> tired of having my energy drained by folks who enjoy feeding off of it
>> while making no effort to return beneficial energy in kind.
>>
>> So when I use the phrase gaming, this is the dynamic to which I refer.
> 
> Thanks for the response.
> 
> I don't know if drive-by attendance at design summit sessions by under-
> qualified or uninformed summiteers is encouraged by the availability of
> ATC passes. But as long as those individuals aren't actively derailing
> the conversation in sessions, I wouldn't consider their buzz soakage as
> a major issue TBH. 
> 
> In any case, I would say that just meeting the bar for an ATC summit pass
> (by landing the required number of patches) is not bending the rules or
> misrepresenting in any way.
> 
> Even if specifically motivated by the ATC pass (as opposed to scratching
> a very specific itch) it's still simply an honest and rational response
> to an incentive offered by the foundation.
> 
> One could argue whether the incentive is mis-designed, but that doesn't
> IMO make a gamer of any contributor who simply meets the required threshold
> of activity.
> 
> Cheers,
> Eoghan
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

No I'm not saying that. I'm saying that the larger issue is one of
motivation.

Folks who want to help (even if they don't know how yet) carry an energy
of intention with them which is nourishing to be around. Folks who are
trying to get in the door and not be expected to help and hope noone
notices carry an entirely different kind of energy with them. It is a
non-nourishing energy.

Ratios also come into play, if you have a group that is 98% nourishing
and 2% not nourishing then I can tolerate that. But when the ratios
start to tip (and I have no hard numbers for this as some folks carry
energy equal to three other people, plus energy can fluctuate) then we
move to the non-nourishing position.

I'm saying I'm in favour of spending time with folks with energy that is
mutually beneficial and nourishing for me. I don't have any way of
translating that to numbers or passes or gerrit actions, but that is the
best I can offer.

Thanks,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Eoghan Glynn]

> >>> Current thinking would be to give preferential rates to access the main
> >>> summit to people who are present to other events (like this new
> >>> separated contributors-oriented event, or Ops midcycle(s)). That would
> >>> allow for a wider definition of "active community member" and reduce
> >>> gaming.
> >>>
> >>
> >> I think reducing gaming is important. It is valuable to include those
> >> folks who wish to make a contribution to OpenStack, I have confidence
> >> the next iteration of entry structure will try to more accurately
> >> identify those folks who bring value to OpenStack.
> > 
> > There have been a couple references to "gaming" on this thread, which
> > seem to imply a certain degree of dishonesty, in the sense of bending
> > the rules.
> > 
> > Can anyone who has used the phrase clarify:
> > 
> >  (a) what exactly they mean by gaming in this context
> > 
> > and:
> > 
> >  (b) why they think this is a clear & present problem demanding a
> >  solution?
> > 
> > For the record, landing a small number of patches per cycle and thus
> > earning an ATC summit pass as a result is not, IMO at least, gaming.
> > 
> > Instead, it's called *contributing*.
> > 
> > (on a small scale, but contributing none-the-less).
> > 
> > Cheers,
> > Eoghan
> 
> Sure I can tell you what I mean.
> 
> In Vancouver I happened to be sitting behind someone who stated "I'm
> just here for the buzz." Which is lovely for that person. The problem is
> that the buzz that person is there for is partially created by me and I
> create it and mean to offer it to people who will return it in kind, not
> just soak it up and keep it to themselves.
> 
> Now I have no way of knowing who this person is and how they arrived at
> the event. But the numbers for people offering one patch to OpenStack
> (the bar for a summit pass) is significantly higher than the curve of
> people offering two, three or four patches to OpenStack (patches that
> are accepted and merged). So some folks are doing the minimum to get a
> summit pass rather than being part of the cohort that has their first
> patch to OpenStack as a means of offering their second patch to OpenStack.
> 
> I consider it an honour and a privilege that I get to work with so many
> wonderful people everyday who are dedicated to making open source clouds
> available for whoever would wish to have clouds. I'm more than a little
> tired of having my energy drained by folks who enjoy feeding off of it
> while making no effort to return beneficial energy in kind.
> 
> So when I use the phrase gaming, this is the dynamic to which I refer.

Thanks for the response.

I don't know if drive-by attendance at design summit sessions by under-
qualified or uninformed summiteers is encouraged by the availability of
ATC passes. But as long as those individuals aren't actively derailing
the conversation in sessions, I wouldn't consider their buzz soakage as
a major issue TBH. 

In any case, I would say that just meeting the bar for an ATC summit pass
(by landing the required number of patches) is not bending the rules or
misrepresenting in any way.

Even if specifically motivated by the ATC pass (as opposed to scratching
a very specific itch) it's still simply an honest and rational response
to an incentive offered by the foundation.

One could argue whether the incentive is mis-designed, but that doesn't
IMO make a gamer of any contributor who simply meets the required threshold
of activity.

Cheers,
Eoghan


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[James Bottomley]

On Mon, 2016-02-29 at 17:48 -0500, Anita Kuno wrote:
> On 02/29/2016 05:34 PM, James Bottomley wrote:
[...]
> > While I accept there is potentially a gaming problem in all forms 
> > of Open Source (we see this in the kernel with the attempt to boost
> > patch counts with trivial changes), I'd be hesitant to characterise
> > people who only submit a single patch as gamers because there's a 
> > lot of drive by patching that goes on in the long tail of any 
> > project.  The usual reason for this is everything works great apart 
> > from one thing, which the person gets annoyed enough over to 
> > investigate and patch.  I've done it myself in a lot of Open Source 
> > projects.  Once your patch is in, you've no need to submit another 
> > because everything is now working as you wished and your goal was 
> > to fix the problem not become further involved in the development 
> > side of things.  I suspect if you look in the long tail of 
> > OpenStack you'll find a lot of user and operator patches for
> > precisely this reason.
> 
> I think you are missing the point of my explanation to the question I
> was asked.
> 
> I am interested in mutually beneficial interactions.
> 
> I am not interested in unbalanced or one sided interactions.
> 
> Sorry I was unclear earlier.

Well, now I'm confused.  I was responding specifically to this
statement:

> So some folks are doing the minimum to get a summit pass rather than 
> being part of the cohort that has their first patch to OpenStack as a 
> means of offering their second patch to OpenStack.

Is that not who you meant by "gamers"? because to me it sounds like an
an expectation that people who aren't gamers would submit more than one
patch and, indeed, become part of the developer base.  I wanted to
explain why there's a significant set of people who legitimately only
submit a single patch and who won't really ever become developers.

James


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/29/2016 05:34 PM, James Bottomley wrote:
> On Mon, 2016-02-29 at 15:57 -0500, Anita Kuno wrote:
>> On 02/29/2016 03:10 PM, Eoghan Glynn wrote:
>>>
> Current thinking would be to give preferential rates to access 
> the main summit to people who are present to other events (like 
> this new separated contributors-oriented event, or Ops 
> midcycle(s)). That would allow for a wider definition of 
> "active community member" and reduce gaming.
>

 I think reducing gaming is important. It is valuable to include 
 those folks who wish to make a contribution to OpenStack, I have
 confidence the next iteration of entry structure will try to more 
 accurately identify those folks who bring value to OpenStack.
>>>
>>> There have been a couple references to "gaming" on this thread, 
>>> which seem to imply a certain degree of dishonesty, in the sense of
>>> bending the rules.
>>>
>>> Can anyone who has used the phrase clarify:
>>>
>>>  (a) what exactly they mean by gaming in this context
>>>
>>> and:
>>>
>>>  (b) why they think this is a clear & present problem demanding a
>>>  solution?
>>>
>>> For the record, landing a small number of patches per cycle and 
>>> thus earning an ATC summit pass as a result is not, IMO at least,
>>> gaming.
>>>
>>> Instead, it's called *contributing*.
>>>
>>> (on a small scale, but contributing none-the-less).
>>>
>>> Cheers,
>>> Eoghan
>>>
>>> ___
>>> ___
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
>>> bscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> Sure I can tell you what I mean.
>>
>> In Vancouver I happened to be sitting behind someone who stated "I'm
>> just here for the buzz." Which is lovely for that person. The problem 
>> is that the buzz that person is there for is partially created by me 
>> and I create it and mean to offer it to people who will return it in 
>> kind, not just soak it up and keep it to themselves.
> 
> Sorry about that; it does sound like a thing a sales or marketing
> person would say.

I would hardly expect you to take responsibility for someone else's
behaviour. It feels odd to me that you would try.

> 
>> Now I have no way of knowing who this person is and how they arrived
>> at the event. But the numbers for people offering one patch to
>> OpenStack (the bar for a summit pass) is significantly higher than
>> the curve of people offering two, three or four patches to OpenStack
>> (patches that are accepted and merged). So some folks are doing the
>> minimum to get a summit pass rather than being part of the cohort
>> that has their first patch to OpenStack as a means of offering their
>> second patch to OpenStack.
> 
> Which does sound like the ATC inducement is working.  If you don't want
> it to encourage people to submit patches then it shouldn't be offered.

I didn't offer it. And personally I do want people to submit patches. It
is their motivation for doing so that I am drawing attention to.

> 
>> I consider it an honour and a privilege that I get to work with so 
>> many wonderful people everyday who are dedicated to making open 
>> source clouds available for whoever would wish to have clouds. I'm 
>> more than a little tired of having my energy drained by folks who 
>> enjoy feeding off of it while making no effort to return beneficial
>> energy in kind.
>>
>> So when I use the phrase gaming, this is the dynamic to which I 
>> refer.
> 
> While I accept there is potentially a gaming problem in all forms of
> Open Source (we see this in the kernel with the attempt to boost patch
> counts with trivial changes), I'd be hesitant to characterise people
> who only submit a single patch as gamers because there's a lot of drive
> by patching that goes on in the long tail of any project.  The usual
> reason for this is everything works great apart from one thing, which
> the person gets annoyed enough over to investigate and patch.  I've
> done it myself in a lot of Open Source projects.  Once your patch is
> in, you've no need to submit another because everything is now working
> as you wished and your goal was to fix the problem not become further
> involved in the development side of things.  I suspect if you look in
> the long tail of OpenStack you'll find a lot of user and operator
> patches for precisely this reason.

I think you are missing the point of my explanation to the question I
was asked.

I am interested in mutually beneficial interactions.

I am not interested in unbalanced or one sided interactions.

Sorry I was unclear earlier.

Thanks,
Anita.

> 
> James
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all] A proposal to separate the design summit

[James Bottomley]

On Mon, 2016-02-29 at 15:57 -0500, Anita Kuno wrote:
> On 02/29/2016 03:10 PM, Eoghan Glynn wrote:
> > 
> > > > Current thinking would be to give preferential rates to access 
> > > > the main summit to people who are present to other events (like 
> > > > this new separated contributors-oriented event, or Ops 
> > > > midcycle(s)). That would allow for a wider definition of 
> > > > "active community member" and reduce gaming.
> > > > 
> > > 
> > > I think reducing gaming is important. It is valuable to include 
> > > those folks who wish to make a contribution to OpenStack, I have
> > > confidence the next iteration of entry structure will try to more 
> > > accurately identify those folks who bring value to OpenStack.
> > 
> > There have been a couple references to "gaming" on this thread, 
> > which seem to imply a certain degree of dishonesty, in the sense of
> > bending the rules.
> > 
> > Can anyone who has used the phrase clarify:
> > 
> >  (a) what exactly they mean by gaming in this context
> > 
> > and:
> > 
> >  (b) why they think this is a clear & present problem demanding a
> >  solution?
> > 
> > For the record, landing a small number of patches per cycle and 
> > thus earning an ATC summit pass as a result is not, IMO at least,
> > gaming.
> > 
> > Instead, it's called *contributing*.
> > 
> > (on a small scale, but contributing none-the-less).
> > 
> > Cheers,
> > Eoghan
> > 
> > ___
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsu
> > bscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
> 
> Sure I can tell you what I mean.
> 
> In Vancouver I happened to be sitting behind someone who stated "I'm
> just here for the buzz." Which is lovely for that person. The problem 
> is that the buzz that person is there for is partially created by me 
> and I create it and mean to offer it to people who will return it in 
> kind, not just soak it up and keep it to themselves.

Sorry about that; it does sound like a thing a sales or marketing
person would say.

> Now I have no way of knowing who this person is and how they arrived
> at the event. But the numbers for people offering one patch to
> OpenStack (the bar for a summit pass) is significantly higher than
> the curve of people offering two, three or four patches to OpenStack
> (patches that are accepted and merged). So some folks are doing the
> minimum to get a summit pass rather than being part of the cohort
> that has their first patch to OpenStack as a means of offering their
> second patch to OpenStack.

Which does sound like the ATC inducement is working.  If you don't want
it to encourage people to submit patches then it shouldn't be offered.

> I consider it an honour and a privilege that I get to work with so 
> many wonderful people everyday who are dedicated to making open 
> source clouds available for whoever would wish to have clouds. I'm 
> more than a little tired of having my energy drained by folks who 
> enjoy feeding off of it while making no effort to return beneficial
> energy in kind.
> 
> So when I use the phrase gaming, this is the dynamic to which I 
> refer.

While I accept there is potentially a gaming problem in all forms of
Open Source (we see this in the kernel with the attempt to boost patch
counts with trivial changes), I'd be hesitant to characterise people
who only submit a single patch as gamers because there's a lot of drive
by patching that goes on in the long tail of any project.  The usual
reason for this is everything works great apart from one thing, which
the person gets annoyed enough over to investigate and patch.  I've
done it myself in a lot of Open Source projects.  Once your patch is
in, you've no need to submit another because everything is now working
as you wished and your goal was to fix the problem not become further
involved in the development side of things.  I suspect if you look in
the long tail of OpenStack you'll find a lot of user and operator
patches for precisely this reason.

James


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/29/2016 03:10 PM, Eoghan Glynn wrote:
> 
>>> Current thinking would be to give preferential rates to access the main
>>> summit to people who are present to other events (like this new
>>> separated contributors-oriented event, or Ops midcycle(s)). That would
>>> allow for a wider definition of "active community member" and reduce
>>> gaming.
>>>
>>
>> I think reducing gaming is important. It is valuable to include those
>> folks who wish to make a contribution to OpenStack, I have confidence
>> the next iteration of entry structure will try to more accurately
>> identify those folks who bring value to OpenStack.
> 
> There have been a couple references to "gaming" on this thread, which
> seem to imply a certain degree of dishonesty, in the sense of bending
> the rules.
> 
> Can anyone who has used the phrase clarify:
> 
>  (a) what exactly they mean by gaming in this context
> 
> and:
> 
>  (b) why they think this is a clear & present problem demanding a
>  solution?
> 
> For the record, landing a small number of patches per cycle and thus
> earning an ATC summit pass as a result is not, IMO at least, gaming.
> 
> Instead, it's called *contributing*.
> 
> (on a small scale, but contributing none-the-less).
> 
> Cheers,
> Eoghan
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 

Sure I can tell you what I mean.

In Vancouver I happened to be sitting behind someone who stated "I'm
just here for the buzz." Which is lovely for that person. The problem is
that the buzz that person is there for is partially created by me and I
create it and mean to offer it to people who will return it in kind, not
just soak it up and keep it to themselves.

Now I have no way of knowing who this person is and how they arrived at
the event. But the numbers for people offering one patch to OpenStack
(the bar for a summit pass) is significantly higher than the curve of
people offering two, three or four patches to OpenStack (patches that
are accepted and merged). So some folks are doing the minimum to get a
summit pass rather than being part of the cohort that has their first
patch to OpenStack as a means of offering their second patch to OpenStack.

I consider it an honour and a privilege that I get to work with so many
wonderful people everyday who are dedicated to making open source clouds
available for whoever would wish to have clouds. I'm more than a little
tired of having my energy drained by folks who enjoy feeding off of it
while making no effort to return beneficial energy in kind.

So when I use the phrase gaming, this is the dynamic to which I refer.

Thanks for asking,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Eoghan Glynn]

> > Current thinking would be to give preferential rates to access the main
> > summit to people who are present to other events (like this new
> > separated contributors-oriented event, or Ops midcycle(s)). That would
> > allow for a wider definition of "active community member" and reduce
> > gaming.
> > 
> 
> I think reducing gaming is important. It is valuable to include those
> folks who wish to make a contribution to OpenStack, I have confidence
> the next iteration of entry structure will try to more accurately
> identify those folks who bring value to OpenStack.

There have been a couple references to "gaming" on this thread, which
seem to imply a certain degree of dishonesty, in the sense of bending
the rules.

Can anyone who has used the phrase clarify:

 (a) what exactly they mean by gaming in this context

and:

 (b) why they think this is a clear & present problem demanding a
 solution?

For the record, landing a small number of patches per cycle and thus
earning an ATC summit pass as a result is not, IMO at least, gaming.

Instead, it's called *contributing*.

(on a small scale, but contributing none-the-less).

Cheers,
Eoghan

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/22/2016 10:49 AM, Daniel P. Berrange wrote:
> On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote:
>> Hi everyone,
>>
>> TL;DR: Let's split the events, starting after Barcelona.
> 
> Yes, please. Your proposal addresses the big issue I have with current
> summits which is the really poor timing wrt start of each dev cycle.
> 
>> The idea would be to split the events. The first event would be for upstream
>> technical contributors to OpenStack. It would be held in a simpler,
>> scaled-back setting that would let all OpenStack project teams meet in
>> separate rooms, but in a co-located event that would make it easy to have
>> ad-hoc cross-project discussions. It would happen closer to the centers of
>> mass of contributors, in less-expensive locations.
> 
> The idea that we can choose less expensive locations is great, but I'm a
> little wary of focusing too much on "centers of mass of contributors", as
> it can easily become an excuse to have it in roughly the same places each
> time. As a non-USA based contributor, I really value the fact the the
> summits rotate around different regions instead of spending all the time
> in the USA as was the case earlier in openstcck days. Minimizing travel
> costs is no doubt a welcome aim for companies' budgets, but it should not
> be allowed to dominate to such a large extent that we miss representation
> of different regions. ie if we never went back to Asia because the it is
> cheaper for the /current/ majority of contributors to go to the US, we'll
> make it harder to attract new contributors from those regions we avoid on
> cost ground. The "center of mass of contributors" could become a self-
> fullfilling prophecy.
> 
> IOW, I'm onboard with choosing less expensive locations, but would like
> to see us still make the effort to reach out across different regions
> for the events, and not become too US focused once again.

I agree with Dan here. Ensuring the events move around and go to
different contributors is very important in ensuring we hear new or
quiet voices.

I was surprised at the difference in how operators approach their
business in Europe as compared to the US and was glad to have the
experience to hear their voice. I would like to believe we have the
ability to continue to hold contributor events in different geographical
areas.

> 
>> The split should ideally reduce the needs to organize separate in-person
>> mid-cycle events. If some are still needed, the main conference venue and
>> time could easily be used to provide space for such midcycle events (given
>> that it would end up happening in the middle of the cycle).
> 
> The obvious risk with suggesting that current mid-cycle events could take
> place alongside the business conference, is that the "business conference"
> ends up being just as large as our combined conference is today.

I think the obstacles to listening at a large event, or co-located with
one, would be larger than any cost savings for using a spare room. The
trouble is it is hard to put a dollar amount on listening or an
environment that is conducive to listening.

My ability to listen is inversely proportional to the amount of people I
witness on any given day, regardless of whether they are in the room
with me or not. Smaller is better for my ability to listen.

Thank you,
Anita.

> IOW we
> risk actually creating 4 big official developer events a year, instead of
> the current 2 events + small unofficial mid-cycles. You'd need to find some
> way to limit the scope of any "mid cycle" events that co-located with the
> business conference to prevent it growing out of hand.  We really want to
> make sure we keep the mid-cycles portrayed as optional small scale
> "hackathons", and not something that contributors feel obligated to
> attend. IMHO they're already risking getting out of hand - it is hard to
> feel well connected to development plans if you miss the mid-cycle events.
> 
> Regards,
> Daniel
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Ed Leafe]

On 02/29/2016 03:19 AM, Sylvain Bauza wrote:

>>> 3. Losing the main summit as an excuse to fund devs travel
>>>
>>> Some developers are sent to the Design Summit only because the main
>>> summit is happening at the same time and wouldn't get funding to attend
>>> a specific event.
>>
>> If you have to pretend to attend the Summit to be able to attend the
>> Design Summit instead, there is deception involved. I'd suggest to
>> have a frank talk with your employer on where the most value lies for
>> you in attending which event. We also have the Travel support program
>> to cover the gaps.
> 
> Well, not all companies are platinum or gold Foundation sponsors and
> some are contributing to OpenStack with very little budget commitment
> apart human resources.
> While one could claim the opportunity to ask their company to increase
> their budget, my guts is that the vast majority will just be unable to
> get that and will be veto'ed.

Other organizations, even the big names in sponsorship, have multiple
layers of management in which the people setting travel policy are not
the people leading the commitment to OpenStack (*cough*IBM*cough*). In
other words, travel to events is not counted as part of the business
support for OpenStack. So the issue doesn't only affect small companies
with tiny budgets.

-- 

-- Ed Leafe



signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/22/2016 12:35 PM, Thierry Carrez wrote:
> Clayton O'Neill wrote:
>> Is the expectation that the ops mid-cycle would continue separately,
>> or be held with the meeting formerly known as the Design Summit?
>>
>> Personally I’d prefer they be held together, but scheduled with the
>> thought that operators aren’t likely to be interested in work
>> sessions, but that a good number of us would be interested in
>> cross-project and some project specific planning sessions.  This would
>> also open up the possibility of having some sessions specific intended
>> for operator/developer feedback sessions.
> 
> I'll let Tom comment on that, but the general idea in the strawman
> proposal was that the Ops "midcycle" event would be preserved as a
> separate event, but likely turn more and more regional to maximize local
> attendance. The rationale was that it's hard for ops to justify
> traveling to a contributors-branded event, while they can more easily
> justify going to the main OpenStack Summit user conference event, and to
> regional Ops gatherings.
> 
> But things are still pretty open on that front, so let's see what the
> feedback is.
> 

We actually had a good chat about one recognized event vs. regional
events at the feedback session at the Ops Meetup in Manchester.

https://etherpad.openstack.org/p/MAN-ops-feedback

I'm speaking up here because I chaired the session, I'm open to
correction on my points from Tom or other Ops folks in attendance.

The benefit of having one recognized event in Manchester is that folks
came to attend from all over the world. We had people from Australia,
China, Japan, Africa, all over Europe, Canada and the US. Having one
moving recognized event means that some folks can only attend every few
years rather than every release, however the benefit is that when the
event is in your geographical region you have folks from other places
coming to you. This cross-pollination would be lost if regional events
replaced one recognized event.

If we call the one recognized Ops event per release one name, currently
it is Meetup: https://wiki.openstack.org/wiki/Operations/Meetups then
there is nothing standing in the way of folks having other local events
if they want to set them up. Currently OpenStack Days are the
acknowledged local event which brings together operators, devs, users
and any other interested audience who might get some benefit from
OpenStack Days.

https://www.openstack.org/community/events/openstackdays?awesm=awe.sm_xkBj

A region could have as many OpenStack Days as they wish (as far as I
understand it) which would satisfy some "gathering-per-release" criteria
for some folks while ensuring one geographically moving recognized event
happened for operators so the benefit from global focus still happens.

Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/23/2016 04:26 AM, Thierry Carrez wrote:
> Tim Bell wrote:
>> On 22/02/16 17:27, "John Garbutt"  wrote:
>>> [...]
>>> I am sure there are more questions that will pop up. Like I assume
>>> this means there is no ATC free pass to the summit? And I guess a
>>> small nominal fee for the contributor meetup (like the recent ops
>>> meetup, to help predict numbers of accurately)? I guess that helps
>>> level the playing field for contributors who don't put git commits in
>>> the repo (I am thinking vocal operators that don't contribute code).
>>> But I probably shouldn't go into all that just yet.
>>
>> I would like to find a way to allow contributors cheaper access to the
>> summits. Many of the devOPS contributors are patching test cases,
>> configuration management recipes and documentation which should be
>> rewarded in some form.
>>
>> Assuming that many of the ATCs are not so motivated to attend the
>> summit, the cost in offering access to the event would not be
>> significant.
>>
>> Charging for the Ops meetups was, to my understanding, more to confirm
>> commitment to attend given limited space.
>>
>> Thus, I would be in favour of a preferential rate for contributors
>> (whether ATC is the right criteria is a different question) for summits.
> 
> Current thinking would be to give preferential rates to access the main
> summit to people who are present to other events (like this new
> separated contributors-oriented event, or Ops midcycle(s)). That would
> allow for a wider definition of "active community member" and reduce
> gaming.
> 

I think reducing gaming is important. It is valuable to include those
folks who wish to make a contribution to OpenStack, I have confidence
the next iteration of entry structure will try to more accurately
identify those folks who bring value to OpenStack.

Thank you,
Anita.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/22/2016 06:49 PM, Matt Fischer wrote:
> On Mon, Feb 22, 2016 at 11:51 AM, Tim Bell  wrote:
> 
>>
>>
>>
>>
>>
>> On 22/02/16 17:27, "John Garbutt"  wrote:
>>
>>> On 22 February 2016 at 15:31, Monty Taylor  wrote:
 On 02/22/2016 07:24 AM, Russell Bryant wrote:
> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez <
>> thie...@openstack.org
>> > wrote:
>> Hi everyone,
>> TL;DR: Let's split the events, starting after Barcelona.
> This proposal sounds fantastic.  Thank you very much to those that help
> put it together.
 Totally agree. I think it's an excellent way to address the concerns and
 balance all of the diverse needs we have.
>>>
>>> tl;dr
>>> +1
>>> Awesome work ttx.
>>> Thank you!
>>>
>>> Cheaper cities & venues should make it easier for more contributors to
>>> attend. Thats a big deal. This also feels like enough notice to plan
>>> for that.
>>>
>>> I think this means summit talk proposal deadline is both after the
>>> previous release, and after the contributor event for the next
>>> release? That should help keep proposals concrete (less guess work
>>> when submitting). Nice.
>>>
>>> Dev wise, it seems equally good timing. Initially I was worried about
>>> the event distracting from RC bugs, but actually I can see this
>>> helping.
>>>
>>> I am sure there are more questions that will pop up. Like I assume
>>> this means there is no ATC free pass to the summit? And I guess a
>>> small nominal fee for the contributor meetup (like the recent ops
>>> meetup, to help predict numbers of accurately)? I guess that helps
>>> level the playing field for contributors who don't put git commits in
>>> the repo (I am thinking vocal operators that don't contribute code).
>>> But I probably shouldn't go into all that just yet.
>>
>> I would like to find a way to allow contributors cheaper access to the
>> summits. Many of the devOPS contributors are patching test cases,
>> configuration management recipes and documentation which should be rewarded
>> in some form.
>>
>> Assuming that many of the ATCs are not so motivated to attend the summit,
>> the cost in offering access to the event would not be significant.
>>
>> Charging for the Ops meetups was, to my understanding, more to confirm
>> commitment to attend given limited space.
>>
>> Thus, I would be in favour of a preferential rate for contributors
>> (whether ATC is the right criteria is a different question) for summits.
>>
>>
>> Tim
> 
> 
> I believe this is already the case. Unless I'm mistaken contributing to a
> big tent config management project like the openstack puppet modules or
> chef counts for ATC. I'm not sure if osad is big tent but if so it would
> also count. Test cases and Docs also already count.

Contributions to any project listed in this file counts toward ATC
status:
http://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml

Thank you,
Anita.

> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Anita Kuno]

On 02/22/2016 11:06 AM, Dmitry Tantsur wrote:
> I agree with Daniel + a couple more comments inline.
> 
> On 02/22/2016 04:49 PM, Daniel P. Berrange wrote:
>> On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote:
>>> Hi everyone,
>>>
>>> TL;DR: Let's split the events, starting after Barcelona.
>>
>> Yes, please. Your proposal addresses the big issue I have with current
>> summits which is the really poor timing wrt start of each dev cycle.
>>
>>> The idea would be to split the events. The first event would be for
>>> upstream
>>> technical contributors to OpenStack. It would be held in a simpler,
>>> scaled-back setting that would let all OpenStack project teams meet in
>>> separate rooms, but in a co-located event that would make it easy to
>>> have
>>> ad-hoc cross-project discussions. It would happen closer to the
>>> centers of
>>> mass of contributors, in less-expensive locations.
>>
>> The idea that we can choose less expensive locations is great, but I'm a
>> little wary of focusing too much on "centers of mass of contributors", as
>> it can easily become an excuse to have it in roughly the same places each
>> time. As a non-USA based contributor, I really value the fact the the
>> summits rotate around different regions instead of spending all the time
>> in the USA as was the case earlier in openstcck days. Minimizing travel
>> costs is no doubt a welcome aim for companies' budgets, but it should not
>> be allowed to dominate to such a large extent that we miss representation
>> of different regions. ie if we never went back to Asia because the it is
>> cheaper for the /current/ majority of contributors to go to the US, we'll
>> make it harder to attract new contributors from those regions we avoid on
>> cost ground. The "center of mass of contributors" could become a self-
>> fullfilling prophecy.
>>
>> IOW, I'm onboard with choosing less expensive locations, but would like
>> to see us still make the effort to reach out across different regions
>> for the events, and not become too US focused once again.
> 
> +1 here. I got an impression that midcycles now usually happen in the
> US.

Anyone can view where sprints are held by looking at the sprints page:
https://wiki.openstack.org/wiki/Sprints

As far as stats for non-US based sprints:

Juno sprints: 2/12 outside the US
Kilo sprints: 2/18 outside the US
Liberty sprints: 1/21 outside the US
Mitaka sprints: 7/23 outside the US (two scheduled, yet to complete)

I would attribute having the Ops Meetup in the UK to having two other
events in the UK, Storyboard and the Product WG. Some events have the
ability to affect the location of other events.

As far as diversity (having events outside of the US) we seem to be
improving, so that is heartening to see. I do hope the trend continues.

Thank you,
Anita.

> Indeed, it's probably much cheaper for the majority of contributors,
> but would make things worse for non-US folks.
> 
>>
>>> The split should ideally reduce the needs to organize separate in-person
>>> mid-cycle events. If some are still needed, the main conference venue
>>> and
>>> time could easily be used to provide space for such midcycle events
>>> (given
>>> that it would end up happening in the middle of the cycle).
>>
>> The obvious risk with suggesting that current mid-cycle events could take
>> place alongside the business conference, is that the "business
>> conference"
>> ends up being just as large as our combined conference is today. IOW we
>> risk actually creating 4 big official developer events a year, instead of
>> the current 2 events + small unofficial mid-cycles. You'd need to find
>> some
>> way to limit the scope of any "mid cycle" events that co-located with the
>> business conference to prevent it growing out of hand.  We really want to
>> make sure we keep the mid-cycles portrayed as optional small scale
>> "hackathons", and not something that contributors feel obligated to
>> attend. IMHO they're already risking getting out of hand - it is hard to
>> feel well connected to development plans if you miss the mid-cycle
>> events.
> 
> This time we (Ironic) tried a virtual midcycle using the asterisk
> infrastructure provided by the infra team, and it worked surprisingly
> well. I'd recommend more teams trying this option instead of trying to
> find a better way of having one more expensive f2f event (even though I
> really like to meet other folks).
> 
>>
>> Regards,
>> Daniel
>>
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thomas Goirand]

On 02/26/2016 10:13 PM, Tom Fifield wrote:
> 
> 
> On 26/02/16 22:02, Thomas Goirand wrote:
>> On 02/23/2016 12:33 AM, Jay Pipes wrote:
>>> OpenStack Conference <-- The main event.
>>> OpenStack:How <-- The developer planning event.
>>>
>>> :)
>>>
>>> -jay
>>
>> Probably I'm dumb, but I still don't understand what's wrong with the
>> name "design summit" for the developer planning event.
>>
>> Like most free software, OpenStack is a do-o-cracy where one must do the
>> things to make them happen. Sure, we do listen to our users, but the
>> design summit is actually where decisions are taken, like it or not...
> 
> "Implementation" decisions, yup. However, because of the position in the
> start of the planning stage of the cycle, the "design" decisions will
> happen at the main event, where we've got the users to give input.

Meaning that there would be not one, but 2 events where developers would
need to go? I don't think this will happen (too expensive).

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Tim Bell]

On 29/02/16 10:32, "Thierry Carrez"  wrote:

>Tim Bell wrote:
>>
>> On 26/02/16 18:08, "Thierry Carrez"  wrote:

 2. Community split

 There is fear that the contributor-specific event will separate the
 community into two groups, with developers skipping the main event and
 non-developers not providing any feedback to the contributor-specific
 event.
>>>
>>> For those two objections, it's worth noting that there will still be a
>>> lot of strategic discussions at the main event. That is where we look at
>>> the N-1 release and start drawing plans and cross-project themes for the
>>> N+1 release. We don't need every developer there, but we still need a
>>> significant chunk of them, with every team represented, so that we can
>>> have those strategic and cross-project discussions.
>>>
>>> Therefore I'd expect someone who wants to keep touch with development
>>> could still make only one trip, and I wouldn't expect the communities to
>>> be split. We'd still all be represented in the main event.
>>
>> Is the assumption that the users would be at the summit rather than the 
>> contributor-specific sessions ? As there is a lot of sharing going on in the 
>> current summit format (it is not just talks on products), I think the cloud 
>> consumers/deployers would tend towards the summit.
>>
>> I think this is my biggest worry that we get to a scenario where we lose the 
>> chance for user (be it consumer of clouds or operators) technical discussion 
>> with the projects. It certainly does not need all developers to be present 
>> but project presentation at a high level is needed to understand the 
>> requirements, explain the reasons for design decisions and debate the 
>> appropriate improvements.
>
>I think your worry is due to a misconception. We don't move the "design 
>summit" to a separate event and remove the users from the equation. We 
>*split* the design summit into two steps: strategic and tactical. Let's 
>take the Q cycle as an example (you can refer back to the picture I 
>attached to the original post).
>
>It starts at the US Summit in May, 2017. We have everyone there: users, 
>product managers, but also a significant share of devs: PTLs, TC members 
>and other cross-project liaisons and drivers. The Ocata release has been 
>out for a few months and operators have started deploying and upgrading 
>to it. In the Strategic planning sessions, users can give feedback to 
>devs about that Ocata release and how the upgrade goes. We can start 
>drawing overarching themes for the Q cycle to address the pain points. 
>We can start prioritizing features and discuss their requirements and 
>initial design points. We can discuss user-facing policies like API 
>deprecation rules, stable branch maintenance, vulnerability 
>management... We make the most of the presence at the main summit event 
>to get all the community together.
>
>In August, 2017 we have the Q contributor-oriented event. By that date 
>we have the feedback, we have the requirements, we have the priorities. 
>The problem is in getting things done. Teams gather and make sure they 
>have assignees for everything, and that all gaps are covered. They 
>discuss how to get a specific feature into the code, bootstrap the work, 
>and solve potential conflicts. They decide on meeting frequency, patch 
>review days, cross-project liaisons. We need *all* the regular 
>developers there so that everyone agrees on the plan to execute and 
>follow. Users are still welcome, but this is not a space for discussion 
>and influencing the priorities: it's a space to get things done and get 
>tactical alignment on how to achieve it in the next 3 months.
>
>In November, 2017 we have the next summit, probably in APAC. Some 
>specific priority feature in a given project is not getting implemented 
>fast enough and is at risk. That project team decides to take advantage 
>of the summit space to hold a one-day hackathon to get this feature back 
>on track.
>
>Early March, 2018 the Q release cycle is completed.
>
>> With the offset of the two event, has an option to locate the operators 
>> mid-cycle meetup at the contributor-specific event ?
>
>That was considered... and I would not necessarily be against it, but I 
>would like to understand what the benefit would be. Tom advocated for 
>keeping it as a separate event (or a set of regional separated events) 
>that would be ops-branded, making it easier for ops to justify travel to 
>it. If the goal is to co-locate so that users can more easily 
>participate to the contributor-oriented event, I think that would be 
>counter-productive for most operators: as I said earlier those are 
>project team meetings for project team members to work together -- you 
>should only join a room if you consider yourself part of the team that 
>will do the work. We won't be rediscussing requirements or gathering 
>feedback there, those will have been discussed 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Clayton O'Neill]

On Mon, Feb 29, 2016 at 4:32 AM, Thierry Carrez  wrote:
> That was considered... and I would not necessarily be against it, but I
> would like to understand what the benefit would be. Tom advocated for
> keeping it as a separate event (or a set of regional separated events) that
> would be ops-branded, making it easier for ops to justify travel to it. If
> the goal is to co-locate so that users can more easily participate to the
> contributor-oriented event, I think that would be counter-productive for
> most operators: as I said earlier those are project team meetings for
> project team members to work together -- you should only join a room if you
> consider yourself part of the team that will do the work. We won't be
> rediscussing requirements or gathering feedback there, those will have been
> discussed at the strategic planning sessions at the summit already.

I’d strongly prefer to see the new dev event and an ops event
co-located.  I’m not against regional events, but I’m not sure why
regional events would *replace* the existing event.  We’re not doing
that for any other sort of mid-cycle/meetup/conference are we?

One suggestion regarding the funding and branding: Have the non-summit
dev event and the ops event separately branded but co-located  Have
different tickets, but have them both grant entrance to both events.
Issue different color badges or lanyards if that seems helpful in
having developers and operators find each other.  Ideally the two
events would run concurrently, or substantially overlap.  Something
like Mon-Wed for ops event, Wed-Fri for dev event or vice versa.  You
could have cross project discussions and dedicated ops/dev breakouts
on an overlapping day.  People not interested in the overlapping
sessions could arrive a day late or leave a day early.

One of my very few complaints about the past few summits has been that
the ops and dev events run concurrently.  For example, in Tokyo I had
to choose between going to cross-project design sessions, or going to
the operators session.  I picked the cross-project sessions in most
cases and I felt like that was probably a good choice.  However, on
Friday there was nothing but dev work sessions was scheduled.  Kris
Lindgren put together an informal ops session on that day and we had
40-50 people attend with no prior planning and no official space.  If
the Ops sessions had been at the end of the week instead of the
beginning there would have been less conflicts.

I’ve seen many developers express the opinion that they desperately
want more operator feedback.  Personally I’m not going to be able to
go to a 2 summits, 2 ops events and 2 dev events, and I think most
operators are in the same situation.  If I have to choose, i’m going
to skip the dev events.  I think it needs to be well thought out how
ops and dev combined sessions are going to be run if the split goes
into place.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Tim Bell wrote:


On 26/02/16 18:08, "Thierry Carrez"  wrote:


2. Community split

There is fear that the contributor-specific event will separate the
community into two groups, with developers skipping the main event and
non-developers not providing any feedback to the contributor-specific
event.


For those two objections, it's worth noting that there will still be a
lot of strategic discussions at the main event. That is where we look at
the N-1 release and start drawing plans and cross-project themes for the
N+1 release. We don't need every developer there, but we still need a
significant chunk of them, with every team represented, so that we can
have those strategic and cross-project discussions.

Therefore I'd expect someone who wants to keep touch with development
could still make only one trip, and I wouldn't expect the communities to
be split. We'd still all be represented in the main event.


Is the assumption that the users would be at the summit rather than the 
contributor-specific sessions ? As there is a lot of sharing going on in the 
current summit format (it is not just talks on products), I think the cloud 
consumers/deployers would tend towards the summit.

I think this is my biggest worry that we get to a scenario where we lose the 
chance for user (be it consumer of clouds or operators) technical discussion 
with the projects. It certainly does not need all developers to be present but 
project presentation at a high level is needed to understand the requirements, 
explain the reasons for design decisions and debate the appropriate 
improvements.


I think your worry is due to a misconception. We don't move the "design 
summit" to a separate event and remove the users from the equation. We 
*split* the design summit into two steps: strategic and tactical. Let's 
take the Q cycle as an example (you can refer back to the picture I 
attached to the original post).


It starts at the US Summit in May, 2017. We have everyone there: users, 
product managers, but also a significant share of devs: PTLs, TC members 
and other cross-project liaisons and drivers. The Ocata release has been 
out for a few months and operators have started deploying and upgrading 
to it. In the Strategic planning sessions, users can give feedback to 
devs about that Ocata release and how the upgrade goes. We can start 
drawing overarching themes for the Q cycle to address the pain points. 
We can start prioritizing features and discuss their requirements and 
initial design points. We can discuss user-facing policies like API 
deprecation rules, stable branch maintenance, vulnerability 
management... We make the most of the presence at the main summit event 
to get all the community together.


In August, 2017 we have the Q contributor-oriented event. By that date 
we have the feedback, we have the requirements, we have the priorities. 
The problem is in getting things done. Teams gather and make sure they 
have assignees for everything, and that all gaps are covered. They 
discuss how to get a specific feature into the code, bootstrap the work, 
and solve potential conflicts. They decide on meeting frequency, patch 
review days, cross-project liaisons. We need *all* the regular 
developers there so that everyone agrees on the plan to execute and 
follow. Users are still welcome, but this is not a space for discussion 
and influencing the priorities: it's a space to get things done and get 
tactical alignment on how to achieve it in the next 3 months.


In November, 2017 we have the next summit, probably in APAC. Some 
specific priority feature in a given project is not getting implemented 
fast enough and is at risk. That project team decides to take advantage 
of the summit space to hold a one-day hackathon to get this feature back 
on track.


Early March, 2018 the Q release cycle is completed.


With the offset of the two event, has an option to locate the operators 
mid-cycle meetup at the contributor-specific event ?


That was considered... and I would not necessarily be against it, but I 
would like to understand what the benefit would be. Tom advocated for 
keeping it as a separate event (or a set of regional separated events) 
that would be ops-branded, making it easier for ops to justify travel to 
it. If the goal is to co-locate so that users can more easily 
participate to the contributor-oriented event, I think that would be 
counter-productive for most operators: as I said earlier those are 
project team meetings for project team members to work together -- you 
should only join a room if you consider yourself part of the team that 
will do the work. We won't be rediscussing requirements or gathering 
feedback there, those will have been discussed at the strategic planning 
sessions at the summit already.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)

Re: [openstack-dev] [all] A proposal to separate the design summit

[Sylvain Bauza]

Honestly, it took me a while before having an opinion on that subject.

Le 26/02/2016 18:08, Thierry Carrez a écrit :

Thierry Carrez wrote:

1. "Two trips instead of one"

There is a section of attendees which benefited from a single event:
in-between people who do not generally go to any midcycle events and
successfully split their attention between the design summit and the
main conference when they were overlapping. Those people fear that in
order to keep the same benefits they will have to travel to two events
per cycle instead of one.

2. Community split

There is fear that the contributor-specific event will separate the
community into two groups, with developers skipping the main event and
non-developers not providing any feedback to the contributor-specific
event.


For those two objections, it's worth noting that there will still be a 
lot of strategic discussions at the main event. That is where we look 
at the N-1 release and start drawing plans and cross-project themes 
for the N+1 release. We don't need every developer there, but we still 
need a significant chunk of them, with every team represented, so that 
we can have those strategic and cross-project discussions.


Therefore I'd expect someone who wants to keep touch with development 
could still make only one trip, and I wouldn't expect the communities 
to be split. We'd still all be represented in the main event.


While I think some top-notch skilled OpenStack developers would still be 
able to attend both events, it would leave a huge number of non-core and 
other non-verbal developers to pick between the DevEvent and the Summit. 
Given that, it would certainly decrease the capacity for those 
developers to be part of the community feedback and feature gathering 
that we try to achieve at Summit time.




3. Losing the main summit as an excuse to fund devs travel

Some developers are sent to the Design Summit only because the main
summit is happening at the same time and wouldn't get funding to attend
a specific event.


If you have to pretend to attend the Summit to be able to attend the 
Design Summit instead, there is deception involved. I'd suggest to 
have a frank talk with your employer on where the most value lies for 
you in attending which event. We also have the Travel support program 
to cover the gaps.




Well, not all companies are platinum or gold Foundation sponsors and 
some are contributing to OpenStack with very little budget commitment 
apart human resources.
While one could claim the opportunity to ask their company to increase 
their budget, my guts is that the vast majority will just be unable to 
get that and will be veto'ed.


We also know that the Travel Support Program is not scalable. Even if 
the Austin budget for this is doubled, it couldn't cope with all 
developers wanting to attend the main Summit - because they're also 
interested in Ops.



4. The fear of US-centricity

A lot of people translated "closer to the centers of mass of
contributors" as meaning "happening in the US all the time". That would
indeed reduce the total travel costs, but at the expense of making it a
lot more costly for non-US parts of our community to participate.


That is a real concern. The goal is to "minimize and balance travel 
costs for existing contributors"... notice the word "balance": there 
would still be some continent rotation involved. The trick will be to 
strike the right balance between cost and fairness.



5. The loss of the midcycle spirit

Last but not least, some people really like the midcycles as they stand:
separated small events where only your small team is around. The split
appears to reduce the likelihood, the need, or the funding for such
events. Even if we keep the midcycle laid-back format in the new event,
co-locating them would turn it into a large event and we'd lose some of
the focus or some of the "only us around" aspect.


While I hope the proposed format will let us fulfill all our team 
socialization needs, it's true that there will be other people around, 
and it will feel a lot less exclusive and special. The trade-off is 
that having people all together encourages cross-project work and 
breaks silos. Hopefully we'll strike the right balance there that will 
let us all get most of the productivity of the current midcycles. It's 
also worth noting that the proposal doesn't prevent team-specific 
events from happening. So if for any reason people don't get what they 
need from the new event, I suspect we'll still have midcycles around 
and that will be a strong signal that we need to tweak the whole thing 
again.




Count me in for saying how those existing face-to-face midcycles are 
extremely productive and I'm really not sure virtual sprints could 
achieve the same. I'm also convinced that midcycles are not extremely 
productive because Design Summits aren't, but rather because for some 
projects, it's growing extremely fast and it's hard to wait 6 months for 
synchronizing all 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jeremy Stanley]

On 2016-02-26 19:16:55 + (+), Hongbin Lu wrote:
[...]
> I want to point out the fact that some projects were holding
> online midcycle because their developers were not able to get
> approval for a pure contributor event.

This may be true for some teams, but please don't assume that cost
is the only reason why a team might hold a virtual mid-cycle event
instead of an in-person one. I personally much prefer the virtual
approach, as I am considerably more productive when I don't have to
travel (granted, it does require some additional care to filter out
other day-to-day distractions and effectively sequester myself to
focus solely on the event; in-person gatherings provide a slightly
more constant reminder of what I'm supposed to be doing).
-- 
Jeremy Stanley

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Hongbin Lu]

-Original Message-
From: James Bottomley [mailto:james.bottom...@hansenpartnership.com] 
Sent: February-26-16 12:38 PM
To: Daniel P. Berrange
Cc: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] A proposal to separate the design summit

On Fri, 2016-02-26 at 17:24 +, Daniel P. Berrange wrote:
> On Fri, Feb 26, 2016 at 08:55:52AM -0800, James Bottomley wrote:
> > On Fri, 2016-02-26 at 16:03 +, Daniel P. Berrange wrote:
> > > On Fri, Feb 26, 2016 at 10:39:08AM -0500, Rich Bowen wrote:
> > > > 
> > > > 
> > > > On 02/22/2016 10:14 AM, Thierry Carrez wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > TL;DR: Let's split the events, starting after Barcelona.
> > > > > 
> > > > > 
> > > > > 
> > > > > Comments, thoughts ?
> > > > 
> > > > Thierry (and Jay, who wrote a similar note much earlier in 
> > > > February, and Lauren, who added more clarity over on the 
> > > > marketing list, and the many, many of you who have spoken up in 
> > > > this thread ...),
> > > > 
> > > > as a community guy, I have grave concerns about what the long 
> > > > -term effect of this move would be. I agree with your reasons, 
> > > > and the problems, but I worry that this is not the way to solve 
> > > > it.
> > > > 
> > > > Summit is one time when we have an opportunity to hold community 
> > > > up to the folks that think only product - to show them how 
> > > > critical it is that the people that are on this mailing list are 
> > > > doing the awesome things that they're doing, in the upstream, in 
> > > > cooperation and collaboration with their competitors.
> > > > 
> > > > I worry that splitting the two events would remove the community 
> > > > aspect from the conference. The conference would become more 
> > > > corporate, more product, and less project.
> > > > 
> > > > My initial response was "crap, now I have to go to four events 
> > > > instead of two", but as I thought about it, it became clear that 
> > > > that wouldn't happen. I, and everyone else, would end up picking 
> > > > one event or the other, and the division between product and 
> > > > project would deepen.
> > > > 
> > > > Summit, for me specifically, has frequently been at least as 
> > > > much about showing the community to the sales/marketing folks in 
> > > > my own company, as showing our wares to the customer.
> > > 
> > > I think what you describe is a prime reason for why separating the 
> > > events would be *beneficial* for the community contributors. The 
> > > conference has long ago become so corporate focused that its 
> > > session offers little to no value to me as a project contributor. 
> > > What you describe as a benefit of being able to put community 
> > > people infront of business people is in fact a significant 
> > > negative for the design summit productivity. It causes key 
> > > community contributors to be pulled out of important design 
> > > sessions to go talk to business people, making the design sessions 
> > > significantly less productive.
> > 
> > It's Naïve to think that something is so sacrosanct that it will be 
> > protected come what may.  Everything eventually has to justify 
> > itself to the funders.  Providing quid pro quo to sales and 
> > marketing helps enormously with that justification and it can be 
> > managed so it's not a huge drain on productive time.  OpenStack may 
> > be the new shiny now, but one day it won't be and then you'll need 
> > the support of the people you're currently disdaining.
> > 
> > I've said this before in the abstract, but let me try to make it 
> > specific and personal: once the kernel was the new shiny and money 
> > was poured all over us; we were pure and banned management types 
> > from the kernel summit and other events, but that all changed when 
> > the dot com bust came.  You're from Red Hat, if you ask the old 
> > timers about the Ottawa Linux Symposium and allied Kernel Summit I 
> > believe they'll recall that in 2005(or 6) the Red Hat answer to a 
> > plea to fund travel was here's $25 a head, go and find a floor to 
> > crash on.  As the wrangler for the new Linux Plumbers Conference I 
> > had to come up with all sorts of convoluted schemes for getting Red 
> > Hat to fund developer travel most of which involved embarrassing 
> > Brian Stevens into approving it over the objections of his managers.  
> > I don't want to go into detail about how Red Hat reached this 
> > situation; I just want to remind you that it happened before and it 
> > could happen again.
> 
> The proposal to split the design summit off actually aims to reduce 
> the travel cost burden. Currently we have a conference+design summit 
> at the wrong time, which is fairly unproductive due to people being 
> pulled out of the design summit for other tasks. So  we "fixed" that 
> by introducing mid-cycles to get real design work done. IOW 
> contributors end up with 4 events to travel to each year. With the 
> proposed 

Re: [openstack-dev] [all] A proposal to separate the design summit

[James Bottomley]

On Fri, 2016-02-26 at 17:24 +, Daniel P. Berrange wrote:
> On Fri, Feb 26, 2016 at 08:55:52AM -0800, James Bottomley wrote:
> > On Fri, 2016-02-26 at 16:03 +, Daniel P. Berrange wrote:
> > > On Fri, Feb 26, 2016 at 10:39:08AM -0500, Rich Bowen wrote:
> > > > 
> > > > 
> > > > On 02/22/2016 10:14 AM, Thierry Carrez wrote:
> > > > > Hi everyone,
> > > > > 
> > > > > TL;DR: Let's split the events, starting after Barcelona.
> > > > > 
> > > > > 
> > > > > 
> > > > > Comments, thoughts ?
> > > > 
> > > > Thierry (and Jay, who wrote a similar note much earlier in 
> > > > February, and Lauren, who added more clarity over on the
> > > > marketing 
> > > > list, and the many, many of you who have spoken up in this
> > > > thread
> > > > ...),
> > > > 
> > > > as a community guy, I have grave concerns about what the long
> > > > -term
> > > > effect of this move would be. I agree with your reasons, and
> > > > the
> > > > problems, but I worry that this is not the way to solve it.
> > > > 
> > > > Summit is one time when we have an opportunity to hold
> > > > community up 
> > > > to the folks that think only product - to show them how
> > > > critical it 
> > > > is that the people that are on this mailing list are doing the 
> > > > awesome things that they're doing, in the upstream, in
> > > > cooperation 
> > > > and collaboration with their competitors.
> > > > 
> > > > I worry that splitting the two events would remove the
> > > > community 
> > > > aspect from the conference. The conference would become more 
> > > > corporate, more product, and less project.
> > > > 
> > > > My initial response was "crap, now I have to go to four events 
> > > > instead of two", but as I thought about it, it became clear
> > > > that 
> > > > that wouldn't happen. I, and everyone else, would end up
> > > > picking 
> > > > one event or the other, and the division between product and
> > > > project would deepen.
> > > > 
> > > > Summit, for me specifically, has frequently been at least as
> > > > much 
> > > > about showing the community to the sales/marketing folks in my
> > > > own
> > > > company, as showing our wares to the customer.
> > > 
> > > I think what you describe is a prime reason for why separating
> > > the
> > > events would be *beneficial* for the community contributors. The
> > > conference has long ago become so corporate focused that its
> > > session
> > > offers little to no value to me as a project contributor. What
> > > you
> > > describe as a benefit of being able to put community people
> > > infront
> > > of business people is in fact a significant negative for the
> > > design
> > > summit productivity. It causes key community contributors to be 
> > > pulled out of important design sessions to go talk to business 
> > > people, making the design sessions significantly less productive.
> > 
> > It's Naïve to think that something is so sacrosanct that it will be
> > protected come what may.  Everything eventually has to justify 
> > itself to the funders.  Providing quid pro quo to sales and 
> > marketing helps enormously with that justification and it can be 
> > managed so it's not a huge drain on productive time.  OpenStack may 
> > be the new shiny now, but one day it won't be and then you'll need 
> > the support of the people you're currently disdaining.
> > 
> > I've said this before in the abstract, but let me try to make it
> > specific and personal: once the kernel was the new shiny and money 
> > was poured all over us; we were pure and banned management types 
> > from the kernel summit and other events, but that all changed when 
> > the dot com bust came.  You're from Red Hat, if you ask the old 
> > timers about the Ottawa Linux Symposium and allied Kernel Summit I 
> > believe they'll recall that in 2005(or 6) the Red Hat answer to a 
> > plea to fund travel was here's $25 a head, go and find a floor to 
> > crash on.  As the wrangler for the new Linux Plumbers Conference I 
> > had to come up with all sorts of convoluted schemes for getting Red 
> > Hat to fund developer travel most of which involved embarrassing 
> > Brian Stevens into approving it over the objections of his 
> > managers.  I don't want to go into detail about how Red Hat reached 
> > this situation; I just want to remind you that it happened before
> > and it could happen again.
> 
> The proposal to split the design summit off actually aims to reduce
> the travel cost burden. Currently we have a conference+design summit
> at the wrong time, which is fairly unproductive due to people being
> pulled out of the design summit for other tasks. So  we "fixed" that
> by introducing mid-cycles to get real design work done. IOW 
> contributors end up with 4 events to travel to each year. With the 
> proposed split of the conference from te design summit, we have a 
> chance of having a productive design summit that can ultimately 
> eliminate the need for the mid-cycles, so we have a good chance of 
> 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Tim Bell]

On 26/02/16 18:08, "Thierry Carrez"  wrote:
>>
>> 2. Community split
>>
>> There is fear that the contributor-specific event will separate the
>> community into two groups, with developers skipping the main event and
>> non-developers not providing any feedback to the contributor-specific
>> event.
>
>For those two objections, it's worth noting that there will still be a 
>lot of strategic discussions at the main event. That is where we look at 
>the N-1 release and start drawing plans and cross-project themes for the 
>N+1 release. We don't need every developer there, but we still need a 
>significant chunk of them, with every team represented, so that we can 
>have those strategic and cross-project discussions.
>
>Therefore I'd expect someone who wants to keep touch with development 
>could still make only one trip, and I wouldn't expect the communities to 
>be split. We'd still all be represented in the main event.

Is the assumption that the users would be at the summit rather than the 
contributor-specific sessions ? As there is a lot of sharing going on in the 
current summit format (it is not just talks on products), I think the cloud 
consumers/deployers would tend towards the summit.

I think this is my biggest worry that we get to a scenario where we lose the 
chance for user (be it consumer of clouds or operators) technical discussion 
with the projects. It certainly does not need all developers to be present but 
project presentation at a high level is needed to understand the requirements, 
explain the reasons for design decisions and debate the appropriate 
improvements.

With the offset of the two event, has an option to locate the operators 
mid-cycle meetup at the contributor-specific event ?

Tim


>
>-- 
>Thierry Carrez (ttx)
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Daniel P. Berrange]

On Fri, Feb 26, 2016 at 08:55:52AM -0800, James Bottomley wrote:
> On Fri, 2016-02-26 at 16:03 +, Daniel P. Berrange wrote:
> > On Fri, Feb 26, 2016 at 10:39:08AM -0500, Rich Bowen wrote:
> > > 
> > > 
> > > On 02/22/2016 10:14 AM, Thierry Carrez wrote:
> > > > Hi everyone,
> > > > 
> > > > TL;DR: Let's split the events, starting after Barcelona.
> > > > 
> > > > 
> > > > 
> > > > Comments, thoughts ?
> > > 
> > > Thierry (and Jay, who wrote a similar note much earlier in 
> > > February, and Lauren, who added more clarity over on the marketing 
> > > list, and the many, many of you who have spoken up in this thread
> > > ...),
> > > 
> > > as a community guy, I have grave concerns about what the long-term
> > > effect of this move would be. I agree with your reasons, and the
> > > problems, but I worry that this is not the way to solve it.
> > > 
> > > Summit is one time when we have an opportunity to hold community up 
> > > to the folks that think only product - to show them how critical it 
> > > is that the people that are on this mailing list are doing the 
> > > awesome things that they're doing, in the upstream, in cooperation 
> > > and collaboration with their competitors.
> > > 
> > > I worry that splitting the two events would remove the community 
> > > aspect from the conference. The conference would become more 
> > > corporate, more product, and less project.
> > > 
> > > My initial response was "crap, now I have to go to four events 
> > > instead of two", but as I thought about it, it became clear that 
> > > that wouldn't happen. I, and everyone else, would end up picking 
> > > one event or the other, and the division between product and
> > > project would deepen.
> > > 
> > > Summit, for me specifically, has frequently been at least as much 
> > > about showing the community to the sales/marketing folks in my own
> > > company, as showing our wares to the customer.
> > 
> > I think what you describe is a prime reason for why separating the
> > events would be *beneficial* for the community contributors. The
> > conference has long ago become so corporate focused that its session
> > offers little to no value to me as a project contributor. What you
> > describe as a benefit of being able to put community people infront
> > of business people is in fact a significant negative for the design
> > summit productivity. It causes key community contributors to be 
> > pulled out of important design sessions to go talk to business 
> > people, making the design sessions significantly less productive.
> 
> It's Naïve to think that something is so sacrosanct that it will be
> protected come what may.  Everything eventually has to justify itself
> to the funders.  Providing quid pro quo to sales and marketing helps
> enormously with that justification and it can be managed so it's not a
> huge drain on productive time.  OpenStack may be the new shiny now, but
> one day it won't be and then you'll need the support of the people
> you're currently disdaining.
> 
> I've said this before in the abstract, but let me try to make it
> specific and personal: once the kernel was the new shiny and money was
> poured all over us; we were pure and banned management types from the
> kernel summit and other events, but that all changed when the dot com
> bust came.  You're from Red Hat, if you ask the old timers about the
> Ottawa Linux Symposium and allied Kernel Summit I believe they'll
> recall that in 2005(or 6) the Red Hat answer to a plea to fund travel
> was here's $25 a head, go and find a floor to crash on.  As the
> wrangler for the new Linux Plumbers Conference I had to come up with
> all sorts of convoluted schemes for getting Red Hat to fund developer
> travel most of which involved embarrassing Brian Stevens into approving
> it over the objections of his managers.  I don't want to go into detail
> about how Red Hat reached this situation; I just want to remind you
> that it happened before and it could happen again.

The proposal to split the design summit off actually aims to reduce
the travel cost burden. Currently we have a conference+design summit
at the wrong time, which is fairly unproductive due to people being
pulled out of the design summit for other tasks. So  we "fixed" that
by introducing mid-cycles to get real design work done. IOW contributors
end up with 4 events to travel to each year. With the proposed split
of the conference from te design summit, we have a chance of having a
productive design summit that can ultimately eliminate the need for
the mid-cycles, so we have a good chance of getting back to 2 events
to travel to each year for the majority of contributors, with the
obviously reduction in costs.

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

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Thierry Carrez wrote:

1. "Two trips instead of one"

There is a section of attendees which benefited from a single event:
in-between people who do not generally go to any midcycle events and
successfully split their attention between the design summit and the
main conference when they were overlapping. Those people fear that in
order to keep the same benefits they will have to travel to two events
per cycle instead of one.

2. Community split

There is fear that the contributor-specific event will separate the
community into two groups, with developers skipping the main event and
non-developers not providing any feedback to the contributor-specific
event.


For those two objections, it's worth noting that there will still be a 
lot of strategic discussions at the main event. That is where we look at 
the N-1 release and start drawing plans and cross-project themes for the 
N+1 release. We don't need every developer there, but we still need a 
significant chunk of them, with every team represented, so that we can 
have those strategic and cross-project discussions.


Therefore I'd expect someone who wants to keep touch with development 
could still make only one trip, and I wouldn't expect the communities to 
be split. We'd still all be represented in the main event.



3. Losing the main summit as an excuse to fund devs travel

Some developers are sent to the Design Summit only because the main
summit is happening at the same time and wouldn't get funding to attend
a specific event.


If you have to pretend to attend the Summit to be able to attend the 
Design Summit instead, there is deception involved. I'd suggest to have 
a frank talk with your employer on where the most value lies for you in 
attending which event. We also have the Travel support program to cover 
the gaps.



4. The fear of US-centricity

A lot of people translated "closer to the centers of mass of
contributors" as meaning "happening in the US all the time". That would
indeed reduce the total travel costs, but at the expense of making it a
lot more costly for non-US parts of our community to participate.


That is a real concern. The goal is to "minimize and balance travel 
costs for existing contributors"... notice the word "balance": there 
would still be some continent rotation involved. The trick will be to 
strike the right balance between cost and fairness.



5. The loss of the midcycle spirit

Last but not least, some people really like the midcycles as they stand:
separated small events where only your small team is around. The split
appears to reduce the likelihood, the need, or the funding for such
events. Even if we keep the midcycle laid-back format in the new event,
co-locating them would turn it into a large event and we'd lose some of
the focus or some of the "only us around" aspect.


While I hope the proposed format will let us fulfill all our team 
socialization needs, it's true that there will be other people around, 
and it will feel a lot less exclusive and special. The trade-off is that 
having people all together encourages cross-project work and breaks 
silos. Hopefully we'll strike the right balance there that will let us 
all get most of the productivity of the current midcycles. It's also 
worth noting that the proposal doesn't prevent team-specific events from 
happening. So if for any reason people don't get what they need from the 
new event, I suspect we'll still have midcycles around and that will be 
a strong signal that we need to tweak the whole thing again.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Flavio Percoco]

On Fri, Feb 26, 2016 at 12:03 PM, Daniel P. Berrange
 wrote:
> On Fri, Feb 26, 2016 at 10:39:08AM -0500, Rich Bowen wrote:
>>
>>
>> On 02/22/2016 10:14 AM, Thierry Carrez wrote:
>> > Hi everyone,
>> >
>> > TL;DR: Let's split the events, starting after Barcelona.
>> >
>> > 
>> >
>> > Comments, thoughts ?
>>
>> Thierry (and Jay, who wrote a similar note much earlier in February, and
>> Lauren, who added more clarity over on the marketing list, and the many,
>> many of you who have spoken up in this thread ...),
>>
>> as a community guy, I have grave concerns about what the long-term
>> effect of this move would be. I agree with your reasons, and the
>> problems, but I worry that this is not the way to solve it.
>>
>> Summit is one time when we have an opportunity to hold community up to
>> the folks that think only product - to show them how critical it is that
>> the people that are on this mailing list are doing the awesome things
>> that they're doing, in the upstream, in cooperation and collaboration
>> with their competitors.
>>
>> I worry that splitting the two events would remove the community aspect
>> from the conference. The conference would become more corporate, more
>> product, and less project.
>>
>> My initial response was "crap, now I have to go to four events instead
>> of two", but as I thought about it, it became clear that that wouldn't
>> happen. I, and everyone else, would end up picking one event or the
>> other, and the division between product and project would deepen.
>>
>> Summit, for me specifically, has frequently been at least as much about
>> showing the community to the sales/marketing folks in my own company, as
>> showing our wares to the customer.
>
> I think what you describe is a prime reason for why separating the
> events would be *beneficial* for the community contributors. The
> conference has long ago become so corporate focused that its session
> offers little to no value to me as a project contributor. What you
> describe as a benefit of being able to put community people infront
> of business people is in fact a significant negative for the design
> summit productivity. It causes key community contributors to be pulled
> out of important design sessions to go talk to business people, making
> the design sessions significantly less productive.

I'd like to add to the above that having it all in a single week
(business meetings, community meetings, design sesions) can also make
the summit more stresful for some folks, which will likely be all
burned out at the end of it.

>
>> Now, I know you guys put on awesome events, and you have probably
>> thought about this already. The proposal to have the events be
>> back-to-back across a weekend may indeed address some of these concerns,
>> at the cost of the "less expensive city and venue" part of the proposal,
>> and at the cost of being away from my family over yet another weekend.
>
> Back to back crossing over a weekend is just a complete non-starter
> of an idea due to the increased time away & giving up personal time
> at the weekends for work.

+1

I believe a back-to-back option was brought up before the Vancouver
summit as an idea for the Tokyo one. There was close to no good
feedback for it.

Cheers,
Flavio

-- 
@flaper87
Flavio Percoco

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[James Bottomley]

On Fri, 2016-02-26 at 16:03 +, Daniel P. Berrange wrote:
> On Fri, Feb 26, 2016 at 10:39:08AM -0500, Rich Bowen wrote:
> > 
> > 
> > On 02/22/2016 10:14 AM, Thierry Carrez wrote:
> > > Hi everyone,
> > > 
> > > TL;DR: Let's split the events, starting after Barcelona.
> > > 
> > > 
> > > 
> > > Comments, thoughts ?
> > 
> > Thierry (and Jay, who wrote a similar note much earlier in 
> > February, and Lauren, who added more clarity over on the marketing 
> > list, and the many, many of you who have spoken up in this thread
> > ...),
> > 
> > as a community guy, I have grave concerns about what the long-term
> > effect of this move would be. I agree with your reasons, and the
> > problems, but I worry that this is not the way to solve it.
> > 
> > Summit is one time when we have an opportunity to hold community up 
> > to the folks that think only product - to show them how critical it 
> > is that the people that are on this mailing list are doing the 
> > awesome things that they're doing, in the upstream, in cooperation 
> > and collaboration with their competitors.
> > 
> > I worry that splitting the two events would remove the community 
> > aspect from the conference. The conference would become more 
> > corporate, more product, and less project.
> > 
> > My initial response was "crap, now I have to go to four events 
> > instead of two", but as I thought about it, it became clear that 
> > that wouldn't happen. I, and everyone else, would end up picking 
> > one event or the other, and the division between product and
> > project would deepen.
> > 
> > Summit, for me specifically, has frequently been at least as much 
> > about showing the community to the sales/marketing folks in my own
> > company, as showing our wares to the customer.
> 
> I think what you describe is a prime reason for why separating the
> events would be *beneficial* for the community contributors. The
> conference has long ago become so corporate focused that its session
> offers little to no value to me as a project contributor. What you
> describe as a benefit of being able to put community people infront
> of business people is in fact a significant negative for the design
> summit productivity. It causes key community contributors to be 
> pulled out of important design sessions to go talk to business 
> people, making the design sessions significantly less productive.

It's Naïve to think that something is so sacrosanct that it will be
protected come what may.  Everything eventually has to justify itself
to the funders.  Providing quid pro quo to sales and marketing helps
enormously with that justification and it can be managed so it's not a
huge drain on productive time.  OpenStack may be the new shiny now, but
one day it won't be and then you'll need the support of the people
you're currently disdaining.

I've said this before in the abstract, but let me try to make it
specific and personal: once the kernel was the new shiny and money was
poured all over us; we were pure and banned management types from the
kernel summit and other events, but that all changed when the dot com
bust came.  You're from Red Hat, if you ask the old timers about the
Ottawa Linux Symposium and allied Kernel Summit I believe they'll
recall that in 2005(or 6) the Red Hat answer to a plea to fund travel
was here's $25 a head, go and find a floor to crash on.  As the
wrangler for the new Linux Plumbers Conference I had to come up with
all sorts of convoluted schemes for getting Red Hat to fund developer
travel most of which involved embarrassing Brian Stevens into approving
it over the objections of his managers.  I don't want to go into detail
about how Red Hat reached this situation; I just want to remind you
that it happened before and it could happen again.

I really suggest you listen to what your community manager says because
he's the one who is actually looking out for your interests.  I
guarantee (and history shows) there will come a time when you'll regret
ignoring him.

James


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Daniel P. Berrange]

On Fri, Feb 26, 2016 at 10:39:08AM -0500, Rich Bowen wrote:
> 
> 
> On 02/22/2016 10:14 AM, Thierry Carrez wrote:
> > Hi everyone,
> > 
> > TL;DR: Let's split the events, starting after Barcelona.
> > 
> > 
> > 
> > Comments, thoughts ?
> 
> Thierry (and Jay, who wrote a similar note much earlier in February, and
> Lauren, who added more clarity over on the marketing list, and the many,
> many of you who have spoken up in this thread ...),
> 
> as a community guy, I have grave concerns about what the long-term
> effect of this move would be. I agree with your reasons, and the
> problems, but I worry that this is not the way to solve it.
>
> Summit is one time when we have an opportunity to hold community up to
> the folks that think only product - to show them how critical it is that
> the people that are on this mailing list are doing the awesome things
> that they're doing, in the upstream, in cooperation and collaboration
> with their competitors.
> 
> I worry that splitting the two events would remove the community aspect
> from the conference. The conference would become more corporate, more
> product, and less project.
> 
> My initial response was "crap, now I have to go to four events instead
> of two", but as I thought about it, it became clear that that wouldn't
> happen. I, and everyone else, would end up picking one event or the
> other, and the division between product and project would deepen.
> 
> Summit, for me specifically, has frequently been at least as much about
> showing the community to the sales/marketing folks in my own company, as
> showing our wares to the customer.

I think what you describe is a prime reason for why separating the
events would be *beneficial* for the community contributors. The
conference has long ago become so corporate focused that its session
offers little to no value to me as a project contributor. What you
describe as a benefit of being able to put community people infront
of business people is in fact a significant negative for the design
summit productivity. It causes key community contributors to be pulled
out of important design sessions to go talk to business people, making
the design sessions significantly less productive.

> Now, I know you guys put on awesome events, and you have probably
> thought about this already. The proposal to have the events be
> back-to-back across a weekend may indeed address some of these concerns,
> at the cost of the "less expensive city and venue" part of the proposal,
> and at the cost of being away from my family over yet another weekend.

Back to back crossing over a weekend is just a complete non-starter
of an idea due to the increased time away & giving up personal time
at the weekends for work.

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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Rich Bowen]

On 02/22/2016 10:14 AM, Thierry Carrez wrote:
> Hi everyone,
> 
> TL;DR: Let's split the events, starting after Barcelona.
> 
> 
> 
> Comments, thoughts ?

Thierry (and Jay, who wrote a similar note much earlier in February, and
Lauren, who added more clarity over on the marketing list, and the many,
many of you who have spoken up in this thread ...),

as a community guy, I have grave concerns about what the long-term
effect of this move would be. I agree with your reasons, and the
problems, but I worry that this is not the way to solve it.

Summit is one time when we have an opportunity to hold community up to
the folks that think only product - to show them how critical it is that
the people that are on this mailing list are doing the awesome things
that they're doing, in the upstream, in cooperation and collaboration
with their competitors.

I worry that splitting the two events would remove the community aspect
from the conference. The conference would become more corporate, more
product, and less project.

My initial response was "crap, now I have to go to four events instead
of two", but as I thought about it, it became clear that that wouldn't
happen. I, and everyone else, would end up picking one event or the
other, and the division between product and project would deepen.

Summit, for me specifically, has frequently been at least as much about
showing the community to the sales/marketing folks in my own company, as
showing our wares to the customer.

Now, I know you guys put on awesome events, and you have probably
thought about this already. The proposal to have the events be
back-to-back across a weekend may indeed address some of these concerns,
at the cost of the "less expensive city and venue" part of the proposal,
and at the cost of being away from my family over yet another weekend.

Thank you for the obvious attention and concern that you're giving to
this issue. I acknowledge the many growth pains that you're trying to
solve with this, and I'm sure that whichever way you go, it'll be awesome.

--Rich

-- 
Rich Bowen - rbo...@redhat.com
OpenStack Community Liaison
http://rdoproject.org/

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Hi everyone,

Summarizing the thread so far... The proposal was generally 
well-received, with negative feedback concentrated along the following 
themes:


1. "Two trips instead of one"

There is a section of attendees which benefited from a single event: 
in-between people who do not generally go to any midcycle events and 
successfully split their attention between the design summit and the 
main conference when they were overlapping. Those people fear that in 
order to keep the same benefits they will have to travel to two events 
per cycle instead of one.


2. Community split

There is fear that the contributor-specific event will separate the 
community into two groups, with developers skipping the main event and 
non-developers not providing any feedback to the contributor-specific event.


3. Losing the main summit as an excuse to fund devs travel

Some developers are sent to the Design Summit only because the main 
summit is happening at the same time and wouldn't get funding to attend 
a specific event.


4. The fear of US-centricity

A lot of people translated "closer to the centers of mass of 
contributors" as meaning "happening in the US all the time". That would 
indeed reduce the total travel costs, but at the expense of making it a 
lot more costly for non-US parts of our community to participate.


5. The loss of the midcycle spirit

Last but not least, some people really like the midcycles as they stand: 
separated small events where only your small team is around. The split 
appears to reduce the likelihood, the need, or the funding for such 
events. Even if we keep the midcycle laid-back format in the new event, 
co-locating them would turn it into a large event and we'd lose some of 
the focus or some of the "only us around" aspect.


I'll answer those concerns in a reply email.

--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Tom Fifield]

On 26/02/16 22:02, Thomas Goirand wrote:

On 02/23/2016 12:33 AM, Jay Pipes wrote:

OpenStack Conference <-- The main event.
OpenStack:How <-- The developer planning event.

:)

-jay


Probably I'm dumb, but I still don't understand what's wrong with the
name "design summit" for the developer planning event.

Like most free software, OpenStack is a do-o-cracy where one must do the
things to make them happen. Sure, we do listen to our users, but the
design summit is actually where decisions are taken, like it or not...


"Implementation" decisions, yup. However, because of the position in the 
start of the planning stage of the cycle, the "design" decisions will 
happen at the main event, where we've got the users to give input.


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thomas Goirand]

On 02/23/2016 12:33 AM, Jay Pipes wrote:
> OpenStack Conference <-- The main event.
> OpenStack:How <-- The developer planning event.
> 
> :)
> 
> -jay

Probably I'm dumb, but I still don't understand what's wrong with the
name "design summit" for the developer planning event.

Like most free software, OpenStack is a do-o-cracy where one must do the
things to make them happen. Sure, we do listen to our users, but the
design summit is actually where decisions are taken, like it or not...

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Antoni Segura Puimedon]

On Fri, Feb 26, 2016 at 10:44 AM, Miguel Angel Ajo Pelayo
 wrote:
>
>> On 26 Feb 2016, at 02:38, Sean McGinnis  wrote:
>>
>> On Thu, Feb 25, 2016 at 04:13:56PM +0800, Qiming Teng wrote:
>>> Hi, All,
>>>
>>> After reading through all the +1's and -1's, we realized how difficult
>>> it is to come up with a proposal that makes everyone happy. When we are
>>> discussing this proposal with some other contributors, we came up with a
>>> proposal which is a little bit different. This idea could be very
>>> impractical, very naive, given that we don't know much about the huge
>>> efforts behind the scheduling, planning, coordination ... etc etc. So,
>>> please treat this as a random thought.
>>>
>>> Maybe we can still have the Summit and the Design Summit colocated, but
>>> we can avoid the overlap that has been the source of many troubles. The
>>> idea is to have both events scheduled by the end of a release cycle. For
>>> example:
>>>
>>> Week 1:
>>>  Wednesday-Friday: 3 days Summit.
>>>* Primarily an event for marketing, sales, CTOs, architects,
>>>  operators, journalists, ...
>>>* Contributors can decide whether they want to attend this.
>>>  Saturday-Sunday:
>>>* Social activities: contributors meet-up, hang outs ...
>>>
>>> Week 2:
>>>  Monday-Wednesday: 3 days Design Summit
>>>* Primarily an event for developers.
>>>* Operators can hold meetups during these days, or join project
>>>  design summits.
>>>
>
>
> A proposal like this one seems much more rational to me,
>
>   * no need for two trips
>   * no overlap of the summit/design (I end up running back and forth 
> otherwise)

These. A thousand times these. Yes, I know the timing in the cycle is still
not the best, but I suspect that with the other option project
specific mid-cycles
will still occur.

>
> Otherwise, separating both parts of the summit increases the gap
> between engineering and the final OpenStack users/ops. I couldn’t go
> to summit-related-events 4 times a year for family reasons. But I like
> to have the opportunity to spend some time close to the user/op side
> of things to understand how people is using OpenStack, what are they
> missing, what are we doing good.
>
>
>>> If you need to attend both events, you don't need two trips. Scheduling
>>> both events by the end of a release cycle can help gather more
>>> meaningful feedbacks, experiences or lessons from previous releases and
>>> ensure a better plan for the coming release.
>>>
>>> If you want to attend just the main Summit or only the Design Summit,
>>> you can plan your trip accordingly.
>>>
>>> Thoughts?
>
> I really like it. Not sure how well does it work for others, or from
> the organisational point of view.

Probably a big issue is that organizers would end up losing 2-3 weekends
in a row, which may be a bit too much to ask.

>
>>>
>>> - Qiming
>>>
>>
>> This would eliminate the need for a second flight, and it would
>> net be total less time away than attending two separate events. I could
>> see this working.
>>
>> Sean
>>
>>>
>>> __
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Miguel Angel Ajo Pelayo]

> On 26 Feb 2016, at 02:38, Sean McGinnis  wrote:
> 
> On Thu, Feb 25, 2016 at 04:13:56PM +0800, Qiming Teng wrote:
>> Hi, All,
>> 
>> After reading through all the +1's and -1's, we realized how difficult
>> it is to come up with a proposal that makes everyone happy. When we are
>> discussing this proposal with some other contributors, we came up with a
>> proposal which is a little bit different. This idea could be very
>> impractical, very naive, given that we don't know much about the huge
>> efforts behind the scheduling, planning, coordination ... etc etc. So,
>> please treat this as a random thought.
>> 
>> Maybe we can still have the Summit and the Design Summit colocated, but
>> we can avoid the overlap that has been the source of many troubles. The
>> idea is to have both events scheduled by the end of a release cycle. For
>> example:
>> 
>> Week 1:
>>  Wednesday-Friday: 3 days Summit.
>>* Primarily an event for marketing, sales, CTOs, architects,
>>  operators, journalists, ...
>>* Contributors can decide whether they want to attend this.
>>  Saturday-Sunday:
>>* Social activities: contributors meet-up, hang outs ...
>> 
>> Week 2:
>>  Monday-Wednesday: 3 days Design Summit
>>* Primarily an event for developers.
>>* Operators can hold meetups during these days, or join project
>>  design summits.
>> 


A proposal like this one seems much more rational to me, 

  * no need for two trips
  * no overlap of the summit/design (I end up running back and forth otherwise)
  
Otherwise, separating both parts of the summit increases the gap
between engineering and the final OpenStack users/ops. I couldn’t go
to summit-related-events 4 times a year for family reasons. But I like
to have the opportunity to spend some time close to the user/op side
of things to understand how people is using OpenStack, what are they
missing, what are we doing good.


>> If you need to attend both events, you don't need two trips. Scheduling
>> both events by the end of a release cycle can help gather more
>> meaningful feedbacks, experiences or lessons from previous releases and
>> ensure a better plan for the coming release.
>> 
>> If you want to attend just the main Summit or only the Design Summit,
>> you can plan your trip accordingly.
>> 
>> Thoughts?

I really like it. Not sure how well does it work for others, or from
the organisational point of view.

>> 
>> - Qiming
>> 
> 
> This would eliminate the need for a second flight, and it would
> net be total less time away than attending two separate events. I could
> see this working.
> 
> Sean
> 
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Sean McGinnis]

On Thu, Feb 25, 2016 at 04:13:56PM +0800, Qiming Teng wrote:
> Hi, All,
> 
> After reading through all the +1's and -1's, we realized how difficult
> it is to come up with a proposal that makes everyone happy. When we are
> discussing this proposal with some other contributors, we came up with a
> proposal which is a little bit different. This idea could be very
> impractical, very naive, given that we don't know much about the huge
> efforts behind the scheduling, planning, coordination ... etc etc. So,
> please treat this as a random thought.
> 
> Maybe we can still have the Summit and the Design Summit colocated, but
> we can avoid the overlap that has been the source of many troubles. The
> idea is to have both events scheduled by the end of a release cycle. For
> example:
> 
> Week 1:
>   Wednesday-Friday: 3 days Summit.
> * Primarily an event for marketing, sales, CTOs, architects,
>   operators, journalists, ...
> * Contributors can decide whether they want to attend this.
>   Saturday-Sunday:
> * Social activities: contributors meet-up, hang outs ...
> 
> Week 2:
>   Monday-Wednesday: 3 days Design Summit
> * Primarily an event for developers.
> * Operators can hold meetups during these days, or join project
>   design summits.
> 
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
> 
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
> 
> Thoughts?
> 
>  - Qiming
> 

This would eliminate the need for a second flight, and it would
net be total less time away than attending two separate events. I could
see this working.

Sean

> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Doug Hellmann]

Excerpts from Jan Klare's message of 2016-02-25 17:43:19 +0100:
> 
> > On 25 Feb 2016, at 15:54, Doug Hellmann  wrote:
> > 
> > Excerpts from Jan Klare's message of 2016-02-25 15:29:08 +0100:
> >> 
> >>> On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
> >>> 
> >>> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
>  Qiming Teng wrote:
> > [...]
> > Week 1:
> > Wednesday-Friday: 3 days Summit.
> >   * Primarily an event for marketing, sales, CTOs, architects,
> > operators, journalists, ...
> >   * Contributors can decide whether they want to attend this.
> > Saturday-Sunday:
> >   * Social activities: contributors meet-up, hang outs ...
> > 
> > Week 2:
> > Monday-Wednesday: 3 days Design Summit
> >   * Primarily an event for developers.
> >   * Operators can hold meetups during these days, or join project
> > design summits.
> > 
> > If you need to attend both events, you don't need two trips. Scheduling
> > both events by the end of a release cycle can help gather more
> > meaningful feedbacks, experiences or lessons from previous releases and
> > ensure a better plan for the coming release.
> > 
> > If you want to attend just the main Summit or only the Design Summit,
> > you can plan your trip accordingly.
>  
>  This was an option we considered. The main objection was that we are 
>  pretty
>  burnt out and ready to go home when comes Friday on a single-week event, 
>  so
>  the prospect of doing two consecutive weeks looked a bit like madness
>  (especially considering ancillary events like upstream training, the 
>  board
>  meeting etc. which tend to happen on the weekend before summit already). 
>  It
>  felt like a good way to reduce our productivity and not make the most of 
>  the
>  limited common time together. Furthermore it doesn't solve the issue of
>  suboptimal timing as described in my original email.
> >> 
> >> I do not think that the other suggestion of two different events solves 
> >> the issues, but instead moves it to another suboptimal timing issue.
> >>> 
> >>> I'd wager a sizeable number of contributors would outright refuse to 
> >>> attend
> >>> an event for 2 weeks. 6-7 days away from family is already a long time. As
> >>> such, I would certainly never do any event which spanned 2 weeks, even if
> >>> both weeks were relevant to my work.
> >> 
> >> I don’t think that the suggestion here was to create an event spanning two 
> >> full weeks. As far as i understand it, the OpenStack summit itself would 
> >> span nearly the exact same time as before and maybe even less if you 
> >> decide that you do not want to attend the main summit (or only a part of 
> >> it), but just the design one (or only a part of it). In addition to that, 
> >> i think the suggestion of 3 days in the first week and 3 days in the 
> >> following one is just something we can start a discussion about. I think 
> >> it would be enough to just have a 2 day main event (maybe Monday and 
> >> Tuesday) and schedule the design summit with 2 or 3 days directly after 
> >> that (Wednesday to Thursday or Friday).
> > 
> > For most folks the summit now is a work week + 2 days for travel
> > on either side of it, or at least 7 days (some of us travel further
> > than others). Spreading it across 7 full days like this would mean
> 
> I do not understand the 7 days you mention here, since i suggested an event 
> starting Monday and ending Friday, which would mean a total of 5 days. Adding 
> the travel time of two days, means we end up with a total of 7 days, which is 
> exactly the work week you mentioned.

The original proposal started on a Wednesday and ended on a Wednesday,
and I should have been more clear that I was responding to that.

Your proposal of 2 days followed by 3 is what we did before the
contributor portion of the summit needed to grow to allow for more
projects. I think 3 days won't be enough time to be effective.

> 
> > at least 9 days for anyone who needs to be present for the entire
> > event. Given that many technical folks do also need to be present
> > for the conference portion of the event to meet with customers, I
> > think there would likely be quite a few folks for whom this would
> > turn into a very long, tiring, trip where productivity would drop off
> > steeply near the middle.
> > 
> > As Thierry pointed out, it's a bit questionable whether there's
> > actually much savings for participants with the extended event.
> > Anyone attending only one half will still need to fly to and stay
> > in the more expensive venues we're using now, so they save nothing.
> > Anyone attending both halves may save the cost of one airline ticket,
> > unless they're going to mid-cycles which we wouldn't be able to
> > eliminate. In which case extending the event *increases* their costs

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jan Klare]

> On 25 Feb 2016, at 15:54, Doug Hellmann  wrote:
> 
> Excerpts from Jan Klare's message of 2016-02-25 15:29:08 +0100:
>> 
>>> On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
>>> 
>>> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
 Qiming Teng wrote:
> [...]
> Week 1:
> Wednesday-Friday: 3 days Summit.
>   * Primarily an event for marketing, sales, CTOs, architects,
> operators, journalists, ...
>   * Contributors can decide whether they want to attend this.
> Saturday-Sunday:
>   * Social activities: contributors meet-up, hang outs ...
> 
> Week 2:
> Monday-Wednesday: 3 days Design Summit
>   * Primarily an event for developers.
>   * Operators can hold meetups during these days, or join project
> design summits.
> 
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
> 
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
 
 This was an option we considered. The main objection was that we are pretty
 burnt out and ready to go home when comes Friday on a single-week event, so
 the prospect of doing two consecutive weeks looked a bit like madness
 (especially considering ancillary events like upstream training, the board
 meeting etc. which tend to happen on the weekend before summit already). It
 felt like a good way to reduce our productivity and not make the most of 
 the
 limited common time together. Furthermore it doesn't solve the issue of
 suboptimal timing as described in my original email.
>> 
>> I do not think that the other suggestion of two different events solves the 
>> issues, but instead moves it to another suboptimal timing issue.
>>> 
>>> I'd wager a sizeable number of contributors would outright refuse to attend
>>> an event for 2 weeks. 6-7 days away from family is already a long time. As
>>> such, I would certainly never do any event which spanned 2 weeks, even if
>>> both weeks were relevant to my work.
>> 
>> I don’t think that the suggestion here was to create an event spanning two 
>> full weeks. As far as i understand it, the OpenStack summit itself would 
>> span nearly the exact same time as before and maybe even less if you decide 
>> that you do not want to attend the main summit (or only a part of it), but 
>> just the design one (or only a part of it). In addition to that, i think the 
>> suggestion of 3 days in the first week and 3 days in the following one is 
>> just something we can start a discussion about. I think it would be enough 
>> to just have a 2 day main event (maybe Monday and Tuesday) and schedule the 
>> design summit with 2 or 3 days directly after that (Wednesday to Thursday or 
>> Friday).
> 
> For most folks the summit now is a work week + 2 days for travel
> on either side of it, or at least 7 days (some of us travel further
> than others). Spreading it across 7 full days like this would mean

I do not understand the 7 days you mention here, since i suggested an event 
starting Monday and ending Friday, which would mean a total of 5 days. Adding 
the travel time of two days, means we end up with a total of 7 days, which is 
exactly the work week you mentioned.

> at least 9 days for anyone who needs to be present for the entire
> event. Given that many technical folks do also need to be present
> for the conference portion of the event to meet with customers, I
> think there would likely be quite a few folks for whom this would
> turn into a very long, tiring, trip where productivity would drop off
> steeply near the middle.
> 
> As Thierry pointed out, it's a bit questionable whether there's
> actually much savings for participants with the extended event.
> Anyone attending only one half will still need to fly to and stay
> in the more expensive venues we're using now, so they save nothing.
> Anyone attending both halves may save the cost of one airline ticket,
> unless they're going to mid-cycles which we wouldn't be able to
> eliminate. In which case extending the event *increases* their costs
> because they end up staying in the more expensive hotel for more
> nights.

The difference in nights in comparison to the current summit of 4 days + 2 days 
travel would be just one night and i do not think than one night in a hotel is 
more expensive than the expenses for a completely separate event.

> 
> We also have to consider the extra difficulty and expense of trying
> to book a venue for such an extended time (considering set up and
> tear down time we need it for longer than we'll be actively using
> it, even if not by a lot).
> 
> Doug
> 
>> 
>> Cheers,
>> Jan
>> 
>>> 
>>> 
>>> 

Re: [openstack-dev] [all] A proposal to separate the design summit

[James Bottomley]

On Thu, 2016-02-25 at 12:40 +0100, Thierry Carrez wrote:
> Qiming Teng wrote:
> > [...]
> > Week 1:
> >Wednesday-Friday: 3 days Summit.
> >  * Primarily an event for marketing, sales, CTOs, architects,
> >operators, journalists, ...
> >  * Contributors can decide whether they want to attend this.
> >Saturday-Sunday:
> >  * Social activities: contributors meet-up, hang outs ...
> > 
> > Week 2:
> >Monday-Wednesday: 3 days Design Summit
> >  * Primarily an event for developers.
> >  * Operators can hold meetups during these days, or join
> > project
> >design summits.
> > 
> > If you need to attend both events, you don't need two trips.
> > Scheduling
> > both events by the end of a release cycle can help gather more
> > meaningful feedbacks, experiences or lessons from previous releases
> > and
> > ensure a better plan for the coming release.
> > 
> > If you want to attend just the main Summit or only the Design
> > Summit,
> > you can plan your trip accordingly.
> 
> This was an option we considered. The main objection was that we are 
> pretty burnt out and ready to go home when comes Friday on a single
> -week event, so the prospect of doing two consecutive weeks looked a 
> bit like madness (especially considering ancillary events like 
> upstream training, the board meeting etc. which tend to happen on the 
> weekend before summit already). It felt like a good way to reduce our 
> productivity and not make the most of the limited common time 
> together. Furthermore it doesn't solve the issue of suboptimal timing 
> as described in my original email.
> 
> The benefit is that for people attending both events, you indeed save 
> on pure flight costs. But since you have to cover for conference 
> hotel rooms and food over the weekend and otherwise compensate 
> employees for being stuck there over the weekend, the gain is not 
> that significant...

We did actually try to do this for Kernel Summit, Plumbers and Linux
Con in 2012.  Once we tried to schedule it, we got a huge back reaction
from the sponsors, the attendees and the speakers mostly about having
to be away over the weekend.  Eventually we caved to pressure and
overlaid all three events in the same week, which lead to another set
of complaints ...

The lesson I took away from this is never schedule a set of events
longer than a week and I still have the scars to remind me.

James


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Doug Hellmann]

Excerpts from Jan Klare's message of 2016-02-25 15:29:08 +0100:
> 
> > On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
> > 
> > On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
> >> Qiming Teng wrote:
> >>> [...]
> >>> Week 1:
> >>>  Wednesday-Friday: 3 days Summit.
> >>>* Primarily an event for marketing, sales, CTOs, architects,
> >>>  operators, journalists, ...
> >>>* Contributors can decide whether they want to attend this.
> >>>  Saturday-Sunday:
> >>>* Social activities: contributors meet-up, hang outs ...
> >>> 
> >>> Week 2:
> >>>  Monday-Wednesday: 3 days Design Summit
> >>>* Primarily an event for developers.
> >>>* Operators can hold meetups during these days, or join project
> >>>  design summits.
> >>> 
> >>> If you need to attend both events, you don't need two trips. Scheduling
> >>> both events by the end of a release cycle can help gather more
> >>> meaningful feedbacks, experiences or lessons from previous releases and
> >>> ensure a better plan for the coming release.
> >>> 
> >>> If you want to attend just the main Summit or only the Design Summit,
> >>> you can plan your trip accordingly.
> >> 
> >> This was an option we considered. The main objection was that we are pretty
> >> burnt out and ready to go home when comes Friday on a single-week event, so
> >> the prospect of doing two consecutive weeks looked a bit like madness
> >> (especially considering ancillary events like upstream training, the board
> >> meeting etc. which tend to happen on the weekend before summit already). It
> >> felt like a good way to reduce our productivity and not make the most of 
> >> the
> >> limited common time together. Furthermore it doesn't solve the issue of
> >> suboptimal timing as described in my original email.
> 
> I do not think that the other suggestion of two different events solves the 
> issues, but instead moves it to another suboptimal timing issue.
> > 
> > I'd wager a sizeable number of contributors would outright refuse to attend
> > an event for 2 weeks. 6-7 days away from family is already a long time. As
> > such, I would certainly never do any event which spanned 2 weeks, even if
> > both weeks were relevant to my work.
> 
> I don’t think that the suggestion here was to create an event spanning two 
> full weeks. As far as i understand it, the OpenStack summit itself would span 
> nearly the exact same time as before and maybe even less if you decide that 
> you do not want to attend the main summit (or only a part of it), but just 
> the design one (or only a part of it). In addition to that, i think the 
> suggestion of 3 days in the first week and 3 days in the following one is 
> just something we can start a discussion about. I think it would be enough to 
> just have a 2 day main event (maybe Monday and Tuesday) and schedule the 
> design summit with 2 or 3 days directly after that (Wednesday to Thursday or 
> Friday).

For most folks the summit now is a work week + 2 days for travel
on either side of it, or at least 7 days (some of us travel further
than others). Spreading it across 7 full days like this would mean
at least 9 days for anyone who needs to be present for the entire
event. Given that many technical folks do also need to be present
for the conference portion of the event to meet with customers, I
think there would likely be quite a few folks for whom this would
turn into a very long, tiring, trip where productivity would drop off
steeply near the middle.

As Thierry pointed out, it's a bit questionable whether there's
actually much savings for participants with the extended event.
Anyone attending only one half will still need to fly to and stay
in the more expensive venues we're using now, so they save nothing.
Anyone attending both halves may save the cost of one airline ticket,
unless they're going to mid-cycles which we wouldn't be able to
eliminate. In which case extending the event *increases* their costs
because they end up staying in the more expensive hotel for more
nights.

We also have to consider the extra difficulty and expense of trying
to book a venue for such an extended time (considering set up and
tear down time we need it for longer than we'll be actively using
it, even if not by a lot).

Doug

> 
> Cheers,
> Jan
> 
> > 
> > 
> > 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  :|
> > 
> > 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jan Klare]

> On 25 Feb 2016, at 13:39, Daniel P. Berrange  wrote:
> 
> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
>> Qiming Teng wrote:
>>> [...]
>>> Week 1:
>>>  Wednesday-Friday: 3 days Summit.
>>>* Primarily an event for marketing, sales, CTOs, architects,
>>>  operators, journalists, ...
>>>* Contributors can decide whether they want to attend this.
>>>  Saturday-Sunday:
>>>* Social activities: contributors meet-up, hang outs ...
>>> 
>>> Week 2:
>>>  Monday-Wednesday: 3 days Design Summit
>>>* Primarily an event for developers.
>>>* Operators can hold meetups during these days, or join project
>>>  design summits.
>>> 
>>> If you need to attend both events, you don't need two trips. Scheduling
>>> both events by the end of a release cycle can help gather more
>>> meaningful feedbacks, experiences or lessons from previous releases and
>>> ensure a better plan for the coming release.
>>> 
>>> If you want to attend just the main Summit or only the Design Summit,
>>> you can plan your trip accordingly.
>> 
>> This was an option we considered. The main objection was that we are pretty
>> burnt out and ready to go home when comes Friday on a single-week event, so
>> the prospect of doing two consecutive weeks looked a bit like madness
>> (especially considering ancillary events like upstream training, the board
>> meeting etc. which tend to happen on the weekend before summit already). It
>> felt like a good way to reduce our productivity and not make the most of the
>> limited common time together. Furthermore it doesn't solve the issue of
>> suboptimal timing as described in my original email.

I do not think that the other suggestion of two different events solves the 
issues, but instead moves it to another suboptimal timing issue.
> 
> I'd wager a sizeable number of contributors would outright refuse to attend
> an event for 2 weeks. 6-7 days away from family is already a long time. As
> such, I would certainly never do any event which spanned 2 weeks, even if
> both weeks were relevant to my work.

I don’t think that the suggestion here was to create an event spanning two full 
weeks. As far as i understand it, the OpenStack summit itself would span nearly 
the exact same time as before and maybe even less if you decide that you do not 
want to attend the main summit (or only a part of it), but just the design one 
(or only a part of it). In addition to that, i think the suggestion of 3 days 
in the first week and 3 days in the following one is just something we can 
start a discussion about. I think it would be enough to just have a 2 day main 
event (maybe Monday and Tuesday) and schedule the design summit with 2 or 3 
days directly after that (Wednesday to Thursday or Friday).

Cheers,
Jan

> 
> 
> 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 Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org 
> ?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev 
> 
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Clark, Robert Graham]

+1 For security too, this exactly mirrors our experience.

From: Duncan Thomas [mailto:duncan.tho...@gmail.com]
Sent: 24 February 2016 12:55
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all] A proposal to separate the design summit



On 22 February 2016 at 23:11, Devananda van der Veen 
> wrote:
On 02/22/2016 09:45 AM, Thierry Carrez wrote:

The split should ideally reduce the needs to organize separate in-person 
mid-cycle events. If some are still needed, the main conference venue and time 
could easily be used to provide space for such midcycle events (given that it 
would end up happening in the middle of the cycle).

If this "extra midcycle" is sanctioned by the foundation, even if optional, I'm 
concerned that it would grow until developer attendance is expected again. That 
said, I can appreciate the need to keep the option open for now. Perhaps if the 
Conference organizers include a hack-space and allow developers to 
self-organize if present, it will avoid the draw that a formal midcycle has?

The cinder mid-cycle is, by far, out most productive part of the cycle, and 
this has been true for two cycles now. The midcycle is already much, much 
cheaper to attend than the foundation events, and I think the bulk of the 
productivity comes from the fact that all of the people are totally focused on 
one thing - there's no running out to do something else, little scheduling 
around other commitments (except remote attendees) and plenty of opportunity to 
circle back around to things. The massive progress we made at the Cinder 
midcycle only happened because we came back to it I think four times - the kind 
of thinking and communication needed often doesn't fit into slots and sessions, 
and really needs the bandwidth of face to face time.
I now think the cinder mid-cycle is more valuable for many devs, and much 
cheaper, than the foundation events. I don't see that this proposal will 
actually increase that value at all.

--
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Sean Dague]

On 02/25/2016 07:39 AM, Daniel P. Berrange wrote:
> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
>> Qiming Teng wrote:
>>> [...]
>>> Week 1:
>>>   Wednesday-Friday: 3 days Summit.
>>> * Primarily an event for marketing, sales, CTOs, architects,
>>>   operators, journalists, ...
>>> * Contributors can decide whether they want to attend this.
>>>   Saturday-Sunday:
>>> * Social activities: contributors meet-up, hang outs ...
>>>
>>> Week 2:
>>>   Monday-Wednesday: 3 days Design Summit
>>> * Primarily an event for developers.
>>> * Operators can hold meetups during these days, or join project
>>>   design summits.
>>>
>>> If you need to attend both events, you don't need two trips. Scheduling
>>> both events by the end of a release cycle can help gather more
>>> meaningful feedbacks, experiences or lessons from previous releases and
>>> ensure a better plan for the coming release.
>>>
>>> If you want to attend just the main Summit or only the Design Summit,
>>> you can plan your trip accordingly.
>>
>> This was an option we considered. The main objection was that we are pretty
>> burnt out and ready to go home when comes Friday on a single-week event, so
>> the prospect of doing two consecutive weeks looked a bit like madness
>> (especially considering ancillary events like upstream training, the board
>> meeting etc. which tend to happen on the weekend before summit already). It
>> felt like a good way to reduce our productivity and not make the most of the
>> limited common time together. Furthermore it doesn't solve the issue of
>> suboptimal timing as described in my original email.
> 
> I'd wager a sizeable number of contributors would outright refuse to attend
> an event for 2 weeks. 6-7 days away from family is already a long time. As
> such, I would certainly never do any event which spanned 2 weeks, even if
> both weeks were relevant to my work.

Agreed. For folks that need to get in time for the board meeting, the
Summit is basically already an 8 day event (counting travel days). I
know I wouldn't do back to back weeks.

-Sean

-- 
Sean Dague
http://dague.net

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Daniel P. Berrange]

On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote:
> Qiming Teng wrote:
> >[...]
> >Week 1:
> >   Wednesday-Friday: 3 days Summit.
> > * Primarily an event for marketing, sales, CTOs, architects,
> >   operators, journalists, ...
> > * Contributors can decide whether they want to attend this.
> >   Saturday-Sunday:
> > * Social activities: contributors meet-up, hang outs ...
> >
> >Week 2:
> >   Monday-Wednesday: 3 days Design Summit
> > * Primarily an event for developers.
> > * Operators can hold meetups during these days, or join project
> >   design summits.
> >
> >If you need to attend both events, you don't need two trips. Scheduling
> >both events by the end of a release cycle can help gather more
> >meaningful feedbacks, experiences or lessons from previous releases and
> >ensure a better plan for the coming release.
> >
> >If you want to attend just the main Summit or only the Design Summit,
> >you can plan your trip accordingly.
> 
> This was an option we considered. The main objection was that we are pretty
> burnt out and ready to go home when comes Friday on a single-week event, so
> the prospect of doing two consecutive weeks looked a bit like madness
> (especially considering ancillary events like upstream training, the board
> meeting etc. which tend to happen on the weekend before summit already). It
> felt like a good way to reduce our productivity and not make the most of the
> limited common time together. Furthermore it doesn't solve the issue of
> suboptimal timing as described in my original email.

I'd wager a sizeable number of contributors would outright refuse to attend
an event for 2 weeks. 6-7 days away from family is already a long time. As
such, I would certainly never do any event which spanned 2 weeks, even if
both weeks were relevant to my work.


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 Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Qiming Teng wrote:

[...]
Week 1:
   Wednesday-Friday: 3 days Summit.
 * Primarily an event for marketing, sales, CTOs, architects,
   operators, journalists, ...
 * Contributors can decide whether they want to attend this.
   Saturday-Sunday:
 * Social activities: contributors meet-up, hang outs ...

Week 2:
   Monday-Wednesday: 3 days Design Summit
 * Primarily an event for developers.
 * Operators can hold meetups during these days, or join project
   design summits.

If you need to attend both events, you don't need two trips. Scheduling
both events by the end of a release cycle can help gather more
meaningful feedbacks, experiences or lessons from previous releases and
ensure a better plan for the coming release.

If you want to attend just the main Summit or only the Design Summit,
you can plan your trip accordingly.


This was an option we considered. The main objection was that we are 
pretty burnt out and ready to go home when comes Friday on a single-week 
event, so the prospect of doing two consecutive weeks looked a bit like 
madness (especially considering ancillary events like upstream training, 
the board meeting etc. which tend to happen on the weekend before summit 
already). It felt like a good way to reduce our productivity and not 
make the most of the limited common time together. Furthermore it 
doesn't solve the issue of suboptimal timing as described in my original 
email.


The benefit is that for people attending both events, you indeed save on 
pure flight costs. But since you have to cover for conference hotel 
rooms and food over the weekend and otherwise compensate employees for 
being stuck there over the weekend, the gain is not that significant...


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Michał Dulko]

On 02/25/2016 09:13 AM, Qiming Teng wrote:
> Hi, All,
>
> After reading through all the +1's and -1's, we realized how difficult
> it is to come up with a proposal that makes everyone happy. When we are
> discussing this proposal with some other contributors, we came up with a
> proposal which is a little bit different. This idea could be very
> impractical, very naive, given that we don't know much about the huge
> efforts behind the scheduling, planning, coordination ... etc etc. So,
> please treat this as a random thought.
>
> Maybe we can still have the Summit and the Design Summit colocated, but
> we can avoid the overlap that has been the source of many troubles. The
> idea is to have both events scheduled by the end of a release cycle. For
> example:
>
> Week 1:
>   Wednesday-Friday: 3 days Summit.
> * Primarily an event for marketing, sales, CTOs, architects,
>   operators, journalists, ...
> * Contributors can decide whether they want to attend this.
>   Saturday-Sunday:
> * Social activities: contributors meet-up, hang outs ...
>
> Week 2:
>   Monday-Wednesday: 3 days Design Summit
> * Primarily an event for developers.
> * Operators can hold meetups during these days, or join project
>   design summits.
>
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
>
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
>
> Thoughts?
>
>  - Qiming

>From my perspective this idea is more appealing. If someone doesn't want
to join main conference he don't need to and we avoid distractions
coming from both events intersecting.

What isn't solved here is placing developer conference in "cheaper"
cities, but I have a feeling that even if hotels cost less, it will be
harder to travel to less popular locations.

Another problem is the timing of the main conference, which in this
proposition won't happen in the middle of the cycle. I wonder however if
it really makes a difference here and if companies want to present
products based on latest release in 2.5 month timeline.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jan Klare]

Hi Qiming,

this sounds like a much more pragmatic and practical idea to me and it think 
just splitting the events into two not parallel parts, but keeping them in the 
same “week” would also solve most of the problems mentioned in this thread, but 
allow people to attend both summits without travelling twice as you mentioned. 
The main issue with this idea might be, that this will not reduce the costs of 
the Desing summit, but in my opinion neither will the completely splittet 
solution. Thanks for this suggestion.

Cheers,
Jan

> On 25 Feb 2016, at 09:13, Qiming Teng  wrote:
> 
> Hi, All,
> 
> After reading through all the +1's and -1's, we realized how difficult
> it is to come up with a proposal that makes everyone happy. When we are
> discussing this proposal with some other contributors, we came up with a
> proposal which is a little bit different. This idea could be very
> impractical, very naive, given that we don't know much about the huge
> efforts behind the scheduling, planning, coordination ... etc etc. So,
> please treat this as a random thought.
> 
> Maybe we can still have the Summit and the Design Summit colocated, but
> we can avoid the overlap that has been the source of many troubles. The
> idea is to have both events scheduled by the end of a release cycle. For
> example:
> 
> Week 1:
>  Wednesday-Friday: 3 days Summit.
>* Primarily an event for marketing, sales, CTOs, architects,
>  operators, journalists, ...
>* Contributors can decide whether they want to attend this.
>  Saturday-Sunday:
>* Social activities: contributors meet-up, hang outs ...
> 
> Week 2:
>  Monday-Wednesday: 3 days Design Summit
>* Primarily an event for developers.
>* Operators can hold meetups during these days, or join project
>  design summits.
> 
> If you need to attend both events, you don't need two trips. Scheduling
> both events by the end of a release cycle can help gather more
> meaningful feedbacks, experiences or lessons from previous releases and
> ensure a better plan for the coming release.
> 
> If you want to attend just the main Summit or only the Design Summit,
> you can plan your trip accordingly.
> 
> Thoughts?
> 
> - Qiming
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Qiming Teng]

Hi, All,

After reading through all the +1's and -1's, we realized how difficult
it is to come up with a proposal that makes everyone happy. When we are
discussing this proposal with some other contributors, we came up with a
proposal which is a little bit different. This idea could be very
impractical, very naive, given that we don't know much about the huge
efforts behind the scheduling, planning, coordination ... etc etc. So,
please treat this as a random thought.

Maybe we can still have the Summit and the Design Summit colocated, but
we can avoid the overlap that has been the source of many troubles. The
idea is to have both events scheduled by the end of a release cycle. For
example:

Week 1:
  Wednesday-Friday: 3 days Summit.
* Primarily an event for marketing, sales, CTOs, architects,
  operators, journalists, ...
* Contributors can decide whether they want to attend this.
  Saturday-Sunday:
* Social activities: contributors meet-up, hang outs ...

Week 2:
  Monday-Wednesday: 3 days Design Summit
* Primarily an event for developers.
* Operators can hold meetups during these days, or join project
  design summits.

If you need to attend both events, you don't need two trips. Scheduling
both events by the end of a release cycle can help gather more
meaningful feedbacks, experiences or lessons from previous releases and
ensure a better plan for the coming release.

If you want to attend just the main Summit or only the Design Summit,
you can plan your trip accordingly.

Thoughts?

 - Qiming


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Walter A. Boring IV]

On 02/23/2016 06:14 AM, Qiming Teng wrote:



I don't think the proposal removes that opportunity. Contributors
/can/ still go to OpenStack Summits. They just don't /have to/. I
just don't think every contributor needs to be present at every
OpenStack Summit, while I'd like to see most of them present at
every separated contributors-oriented event[tm].

Yes they can, but if contributors go to the design summit, then they
also have to get travel budget to go to the new Summit.   So, design
summits,  midcycle meetups, and now the split off marketing summit.
This is making it overall more expensive for contributors that meet
with customers.


My take of this is that we are saving the cost by isolating developers
(contributors) from users/customers.

And that is exactly a problem for contributors like myself that use the
conference to meet with customers.   If we split off the summit from
developers, then I'll also have to travel to yet another meetup, just to
meet with customers.

For contributors that just focus on design and development, the proposed
change is probably fine, but for everyone else this seems to make things 
worse

and adds additional costs and travel.

Walt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Duncan Thomas]

On 22 February 2016 at 23:11, Devananda van der Veen <
devananda@gmail.com> wrote:

> On 02/22/2016 09:45 AM, Thierry Carrez wrote:
>

> The split should ideally reduce the needs to organize separate in-person
> mid-cycle events. If some are still needed, the main conference venue and
> time could easily be used to provide space for such midcycle events (given
> that it would end up happening in the middle of the cycle).
>
> If this "extra midcycle" is sanctioned by the foundation, even if
> optional, I'm concerned that it would grow until developer attendance is
> expected again. That said, I can appreciate the need to keep the option
> open for now. Perhaps if the Conference organizers include a hack-space and
> allow developers to self-organize if present, it will avoid the draw that a
> formal midcycle has?
>

The cinder mid-cycle is, by far, out most productive part of the cycle, and
this has been true for two cycles now. The midcycle is already much, much
cheaper to attend than the foundation events, and I think the bulk of the
productivity comes from the fact that all of the people are totally focused
on one thing - there's no running out to do something else, little
scheduling around other commitments (except remote attendees) and plenty of
opportunity to circle back around to things. The massive progress we made
at the Cinder midcycle only happened because we came back to it I think
four times - the kind of thinking and communication needed often doesn't
fit into slots and sessions, and really needs the bandwidth of face to face
time.

I now think the cinder mid-cycle is more valuable for many devs, and much
cheaper, than the foundation events. I don't see that this proposal will
actually increase that value at all.

-- 
Duncan Thomas
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/23/2016 09:50 AM, Michael Krotscheck wrote:

> Also, it doesn't seem like alternative cost-savings solutions have
> been considered. For example, how about we host a summit in a
> Not-Top-Tier city for a change? Examples that come to mind are
> Columbus, Pittsburgh, and Indianapolis, which each have convention
> centers larger than Austin.

One of the reasons we started having Summits in big cities was the
cheaper airfares and simpler flight arrangements for people coming
from overseas. The second summit in San Antonio was great since most
people in OpenStack at the time worked for Rackspace, and that's where
the mother ship is located. But after hearing the problems of flying
to SA from, say, Japan, it was decided to keep the summits at coastal
cities in the US, alternating east/west.

But now that the summits have grown to be so huge, the flight savings
have been overwhelmed by the hotel costs in most cases. Making the
events smaller, like the midcycles, can allow us to hold them in much
smaller venues with much less expensive hotels.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWzK2HAAoJEKMgtcocwZqLM4wP/2cY7HrSwq//iqLGd23yxqr7
7q9xSN6y1sxjP77q8TA6bt+XO7r4oFzLltMgU8YwgITY0qyMEDZ+MHizCw4hNxKq
AdMUj1XkDR+q/zT9h4SWNEyYY8ySlLLaaSq1Rb6TcvJFYWfy0KjF2FJWjd2tB8Yq
M4I1WDrqkkB4yO88qYYRvHRVPMNsMYQCBXlUSO9P1HrERUT+x4wNUgE7EMgogYnF
IPupCtR+o+8qRH28Yq302W36iwKwQum6aFn4zjjZhAciikiHI9ohZpY/GaWKZxeX
prnY/POaQ95bFBm87A7ZVR1Bc1R1m84ljhCWUPJL2foAkfRpgMwOFUr7qwFHIkM+
YjSTcDmpLOtIO1A3rhoqjJP47O6LajLtANb7Qh88JFv+DcdfbeyD11V/BzG8CK1i
HDEyk2cxvz0E2i2WwhUNoLx3WpHBeTLSANUGuH+QuTh52yh5CwtTnwmN/RUVdTfE
LctWxORMeRk/PV4XRwhFAxtzf3I7Eibb1l6V9TNcGGzBD8uTwx6hLYJcMpEiswl9
GQvnXQEeXxrUW6cGmwMbXz/tNXGVnzowOHcRPSWv5jqg3niG+e7E4GnXqefSl6dU
cztj3eceBrAGawxZ3JAili8X7JztqIqV575yVJFgEVqyho3g5fzBcAkbsZ+9FP9E
Jh38onWzKSm3ri4lS7V0
=aCk5
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/23/2016 11:52 AM, Clint Byrum wrote:

> I did not attend the first few summits, my first one being the
> Boston event, but I did attend quite a few Ubuntu Developer
> Summits, which were much more about development discussions, and
> almost completely devoid of conference semantics. It always felt
> like a series of productive meetings, and not like a series of
> rushed, agitated, nervous brain dumps, which frankly is what a lot
> of Tokyo felt like.

While the first was more of a "what exactly are we getting ourselves
into?" event, the next two were much more focused on the developer
design discussions. Yes, there were some business sessions, but there
were no technical talks or splashy booths. The dev sessions were
completely separate, and I remember moving bean bag chairs around to
get a few people together to discuss an issue, and then moving them
again to form a different group. There also weren't many separate
teams then, so it was pretty much everyone in a few rooms.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWzKrsAAoJEKMgtcocwZqLDmAP+wazkjbzxz5LHqyB/wFZwgMy
ds7t+6g5smsaCW/ukGP1l6XhSBmgkNC1P7pGSSoAmL2KN3trMD1qLHM49IQo8bla
1IswO3bdXeacJ0Z+ZcwhdJ5k+Joohk8vRz5HmoVEFuIPApzvMaC+GSiTht/1q4HL
cbTKtxlbam9Nis4NsqOt2X/qOJyukWVBeSwq4SEwZB74PNE/g/o48xWWWPcaTXdp
ehNcbrkSVR0tJyvCbkNxtpm+cJF3/kVRoao+M5kdp4zEhhfTkEbpDAGvjQe6TqpL
3m5C6OK3HpMvPJq7dnvG7Rz+N9IKE8TJfr6vx1vkt8/Xsq9/YeVoX1ezA1lQ+XFL
i7b6mlNuVw21kQlJtx4Tv43ws39hqDMPnM0tuwd/28EtdG99Ck69oTKidS43H7pu
i0tsyqLlNCMr37hxXKiut32kcULJZ1GX0r6sIz53QDBBDNvZRv7sDT4lq4pLiOO3
bLHJwrBSxFjk6/hgV/I/YZZ3yUt4NRkfTMy/fyddvJb+GdSQzU2ieq/rr6bC+1DQ
zjrUt9qWSeNXVAiDH1gZurF6vJnsQ2HsHt2hGc3xAE4/trKkP4+brjipJbOurNo6
uZAWNW2R+sRLq5Qmb4GqfYpU4seDhdIYzMf/ZQjnyYUhWyh+Wkn2vrYLR9SCwk5k
d409ChN/loE2F2gYn7mu
=ZDmG
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Matt Fischer]

>
> >  * would it better to keep the ocata cycle at a more normal length, and
> >then run the "contributor events" in Mar/Sept, as opposed to Feb/Aug?
> >(again to avoid the August black hole)
> >
>
> Late March is treacherous in the US, as spring break is generally around
> the last week of March. So I think it just has to stay mid-March or
> earlier.
>
>
Spring break here and many other places is the 2nd week of March, but it
varies in every school district in every state. I think any week in March
is bad in general if you're worried about this but it will be impossible to
avoid all of them.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Clint Byrum]

Excerpts from Eoghan Glynn's message of 2016-02-22 15:06:01 -0800:
> 
> > Hi everyone,
> > 
> > TL;DR: Let's split the events, starting after Barcelona.
> > 
> > Long long version:
> > 
> > In a global and virtual community, high-bandwidth face-to-face time is
> > essential. This is why we made the OpenStack Design Summits an integral
> > part of our processes from day 0. Those were set at the beginning of
> > each of our development cycles to help set goals and organize the work
> > for the upcoming 6 months. At the same time and in the same location, a
> > more traditional conference was happening, ensuring a lot of interaction
> > between the upstream (producers) and downstream (consumers) parts of our
> > community.
> > 
> > This setup, however, has a number of issues. For developers first: the
> > "conference" part of the common event got bigger and bigger and it is
> > difficult to focus on upstream work (and socially bond with your
> > teammates) with so much other commitments and distractions. The result
> > is that our design summits are a lot less productive than they used to
> > be, and we organize other events ("midcycles") to fill our focus and
> > small-group socialization needs. The timing of the event (a couple of
> > weeks after the previous cycle release) is also suboptimal: it is way
> > too late to gather any sort of requirements and priorities for the
> > already-started new cycle, and also too late to do any sort of work
> > planning (the cycle work started almost 2 months ago).
> > 
> > But it's not just suboptimal for developers. For contributing companies,
> > flying all their developers to expensive cities and conference hotels so
> > that they can attend the Design Summit is pretty costly, and the goals
> > of the summit location (reaching out to users everywhere) do not
> > necessarily align with the goals of the Design Summit location (minimize
> > and balance travel costs for existing contributors). For the companies
> > that build products and distributions on top of the recent release, the
> > timing of the common event is not so great either: it is difficult to
> > show off products based on the recent release only two weeks after it's
> > out. The summit date is also too early to leverage all the users
> > attending the summit to gather feedback on the recent release -- not a
> > lot of people would have tried upgrades by summit time. Finally a common
> > event is also suboptimal for the events organization : finding venues
> > that can accommodate both events is becoming increasingly complicated.
> > 
> > Time is ripe for a change. After Tokyo, we at the Foundation have been
> > considering options on how to evolve our events to solve those issues.
> > This proposal is the result of this work. There is no perfect solution
> > here (and this is still work in progress), but we are confident that
> > this strawman solution solves a lot more problems than it creates, and
> > balances the needs of the various constituents of our community.
> > 
> > The idea would be to split the events. The first event would be for
> > upstream technical contributors to OpenStack. It would be held in a
> > simpler, scaled-back setting that would let all OpenStack project teams
> > meet in separate rooms, but in a co-located event that would make it
> > easy to have ad-hoc cross-project discussions. It would happen closer to
> > the centers of mass of contributors, in less-expensive locations.
> > 
> > More importantly, it would be set to happen a couple of weeks /before/
> > the previous cycle release. There is a lot of overlap between cycles.
> > Work on a cycle starts at the previous cycle feature freeze, while there
> > is still 5 weeks to go. Most people switch full-time to the next cycle
> > by RC1. Organizing the event just after that time lets us organize the
> > work and kickstart the new cycle at the best moment. It also allows us
> > to use our time together to quickly address last-minute release-critical
> > issues if such issues arise.
> > 
> > The second event would be the main downstream business conference, with
> > high-end keynotes, marketplace and breakout sessions. It would be
> > organized two or three months /after/ the release, to give time for all
> > downstream users to deploy and build products on top of the release. It
> > would be the best time to gather feedback on the recent release, and
> > also the best time to have strategic discussions: start gathering
> > requirements for the next cycle, leveraging the very large cross-section
> > of all our community that attends the event.
> > 
> > To that effect, we'd still hold a number of strategic planning sessions
> > at the main event to gather feedback, determine requirements and define
> > overall cross-project themes, but the session format would not require
> > all project contributors to attend. A subset of contributors who would
> > like to participate in this sessions can collect and relay feedback to
> > other 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Clint Byrum]

Excerpts from Sean McGinnis's message of 2016-02-22 11:48:50 -0800:
> On Mon, Feb 22, 2016 at 05:20:21PM +, Amrith Kumar wrote:
> > Thierry and all of those who contributed to putting together this write-up, 
> > thank you very much.
> > 
> > TL;DR: +0
> > 
> > Longer version:
> > 
> > While I definitely believe that the new proposed timing for "OpenStack 
> > Summit" which is some months after the release, is a huge improvement, I am 
> > not completely enamored of this proposal. Here is why.
> > 
> > As a result of this proposal, there will still be four events each year, 
> > two "OpenStack Summit" events and two "MidCycle" events. The material 
> > change is that the "MidCycle" event that is currently project specific will 
> > become a single event inclusive of all projects, not unlike our current 
> > "Design Summit".
> > 
> > I contrast this proposal with a mid-cycle two weeks ago for the Trove 
> > project. Thanks to the folks at Red Hat who hosted us in Raleigh, we had a 
> > dedicated room, with high bandwidth internet and the ability to have people 
> > join us remotely via audio and video (which we used mostly for screen 
> > sharing). The previous mid-cycle similarly had excellent facilities 
> > provided us by HP (in California), Rackspace (in Austin) and at MIT in 
> > Cambridge when we (Tesora) hosted the event.
> > 
> > At these "simpler, scaled-back settings", would we be able to provide the 
> > same kind of infrastructure for each project?
> > 
> > Given the number of projects, and leaving aside high bandwidth internet and 
> > remote participation, providing dedicated meeting room for the duration of 
> > the MidCycle event for each project is a considerable undertaking. I 
> > believe therefore that the consequence is that the MidCycle event will end 
> > up being of comparable scale to the current Design Summit or larger, and 
> > will likely need a similar venue.
> > 
> > I also believe that it is important that OpenStack continue to grow not 
> > only a global customer base but also a global contributor base. As others 
> > have already commented, this proposal risks the "design summit" become US 
> > based, maybe Europe once in a long while. But I find it much harder to 
> > believe that these design summits would be truly global. And this I think 
> > would be an unwelcome consequence.
> > 
> > At the current OpenStack Summit, there is an opportunity for contributors, 
> > customers and operators to interact, not just in technical meetings, but 
> > also in a social setting. I think this is valuable, even though there seems 
> > to be a number of people who believe that this is not necessarily the case.
> > 
> > Those are the three concerns I have with the proposal. 
> > 
> > Thanks again to Thierry and all who contributed to putting this proposal 
> > together.
> > 
> > -amrith
> 
> I agree with a lot of the concerns raised here. I wonder if we're not
> just shifting some of the problems and causing others.
> 
> While the timing of things isn't ideal right now, I'm also afraid the
> timing of these changes would also interupt our development flow and
> cause distractions when we need folks focused on getting things done.
> 
> I'm also very concerned about losing our midcycles. At least for Cinder,
> the midcycle events have been hugely successful and well worth the time
> and travel expense, IMO. To me, the design summit event is good for
> cross-project communication and getting more operator input. But the
> midcycles have been where we've really been able to focus and figure out
> issues.
> 

I do understand this concern, but the difference is in the way a
development-summit-only event is attended versus a conference+summit.
When you don't have keynotes every morning expending peoples' time, and
you don't have people running out of discussions to give their talks,
this immediately adds a calm focus to the discussions that feels a
lot more like a mid-cycle. When there's no booth for your company to
ask you to come by and man for a while to meet customers and partners,
suddenly every developer can spend the whole of the event talking to
other developers and operators who have come to participate directly.

I did not attend the first few summits, my first one being the Boston
event, but I did attend quite a few Ubuntu Developer Summits, which were
much more about development discussions, and almost completely devoid of
conference semantics. It always felt like a series of productive meetings,
and not like a series of rushed, agitated, nervous brain dumps, which
frankly is what a lot of Tokyo felt like.

> Even if we still have a colocated "midcycle" now, I would be afraid that
> there would be too many distractions from everything else going on for
> us to be able to really tackle some of the things we've been able to in
> our past midcycles.
> 

I _DO_ share your concern here. The mid-cycles are productive because
they're focused. Putting one at the conference will just 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jonathan Proulx]

On Tue, Feb 23, 2016 at 10:14:11PM +0800, Qiming Teng wrote:

:My take of this is that we are saving the cost by isolating developers
:(contributors) from users/customers.

I'm a little concerned about this as well.  Though presumably at least
the PTLs would still attend the User/Ops conference even if their
project didn't co-schedule a midcycle and while there could be more
focused on that user feed back rather than splitting their attention
with implementation detais and other design summit type issues.

I'm not entierly settled in my opinion yet, but right now the proposed
changes seem like a good direction to me.

Moving the design summit seems popular with the dev community here.

Moving the User/Ops session further after release also seems like a
good plan as there will be some people there with real production
experiance with the new release.  In Tokyo we had an Operators session
on upgrade issues with Liberty that was very well attended but exactly
zero attendees had actually run the upgrade in production.

So later in the cycle is definitely better for getting feed back on
the last realeas, but is there a good plan for how that feed back will
feed into the next release (or maybe at that point it will be next+1)?

-Jon 

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Michael Krotscheck]

On Tue, Feb 23, 2016 at 3:40 AM Chris Dent  wrote:

>
> However, it makes me sad to see the continued trend of limiting
> in-person gatherings. They are useful as a way of keeping people
> aligned with similar goals and approaches to reaching those goals.
> Yes, it is expensive, but it would be nice if the patrons (our
> employers) would recognize that getting us all working well together
> is a cost of doing this business.
>

To echo (and add an angle) what Chris is saying: follow the money. Sales
and marketing has traditionally gotten more dollars than dev, and I feel
that splitting the summit into two is the start of the long slow
budget-cutting death of the design summit. "Sorry, we just can't afford to
send you this year" is going to erode attendance.

Also, it doesn't seem like alternative cost-savings solutions have been
considered. For example, how about we host a summit in a Not-Top-Tier city
for a change? Examples that come to mind are Columbus, Pittsburgh, and
Indianapolis, which each have convention centers larger than Austin.

On the upside, if we're going down this path, can I recommend that the Ops
summit be combined with the marketing summit? It seems like a natural fit
to put People Who Deploy OpenStack together with People Who Sell Things To
People Who Deploy OpenStack.

Michael
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Qiming Teng]

> >I don't think the proposal removes that opportunity. Contributors
> >/can/ still go to OpenStack Summits. They just don't /have to/. I
> >just don't think every contributor needs to be present at every
> >OpenStack Summit, while I'd like to see most of them present at
> >every separated contributors-oriented event[tm].
> 
> Yes they can, but if contributors go to the design summit, then they
> also have to get travel budget to go to the new Summit.   So, design
> summits,  midcycle meetups, and now the split off marketing summit.
> This is making it overall more expensive for contributors that meet
> with customers.
> 
My take of this is that we are saving the cost by isolating developers
(contributors) from users/customers.

- Qiming


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Qiming Teng]

On Mon, Feb 22, 2016 at 10:30:56PM -0500, michael mccune wrote:
> On 02/22/2016 11:06 AM, Dmitry Tantsur wrote:
> >+1 here. I got an impression that midcycles now usually happen in the
> >US. Indeed, it's probably much cheaper for the majority of contributors,
> >but would make things worse for non-US folks.
> 
> cost of travel has been a big reason we have never managed to have a
> sahara mid-cycle, as the team is evenly split across the world.
> 
> mike
> 
Cool. Then this proposal is about saving your mid-cycle costs for ever.

- Qiming


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thomas Goirand]

Thierry,

Thanks for writing this up.

On 02/22/2016 11:14 PM, Thierry Carrez wrote:
> More importantly, it would be set to happen a couple of weeks /before/
> the previous cycle release. There is a lot of overlap between cycles.
> Work on a cycle starts at the previous cycle feature freeze, while there
> is still 5 weeks to go. Most people switch full-time to the next cycle
> by RC1. Organizing the event just after that time lets us organize the
> work and kickstart the new cycle at the best moment. It also allows us
> to use our time together to quickly address last-minute release-critical
> issues if such issues arise.

Just a quick comment on the timing... :P

While it makes little sense to have the design summit scheduled a long
time after the final release, I'm a little bit scared that having the
design summit meetings between RC1 and the final release includes the
risk to loose the focus on RC bug fixing.

Cheers,

Thomas Goirand (zigo)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Chris Dent]

On Tue, 23 Feb 2016, Thierry Carrez wrote:

We can't really prevent people from organizing those anyway :) I just hope 
social in-person team gatherings will not be needed as much with this split. 
What may still be needed are mid-cycle "sprints" to achieve specific 
objectives: those could happen in hackathon space at the main summit, in 
donated office space, or online.


Overall I'm in favor of the proposal because it achieves the one thing
that seems most important to have: less conflict of attention between
the project/design summit stuff and the presentatations/marketing/
selling/showing off stuff. It's hard to be in both frames of mind at
the same time.

However, it makes me sad to see the continued trend of limiting
in-person gatherings. They are useful as a way of keeping people
aligned with similar goals and approaches to reaching those goals.
Yes, it is expensive, but it would be nice if the patrons (our
employers) would recognize that getting us all working well together
is a cost of doing this business.

Virtualized gatherings are useful too, but they don't accomplish the
same thing.

--
Chris Dent   (�s°□°)�s�喋擤ォ�http://anticdent.org/
freenode: cdent tw: @anticdent__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Tom Fifield]

Hi ops (cc: devs),

I'm writing to you to let you know why I think Thierry's proposal is a 
good one that probably works better for us than the current situation.


The design summit for us at the moment isn't as good as it could be. You 
turn up, ready to contribute and help out developers with feedback and 
ideas, and get told either "that release is too old, we fixed that 
already" or "oh, we're already well into feature design, try next 
cycle?". It's frustrating for all involved.



A key aspect of this change is the shifting of the the release cycle 
(see the diagram from Thierry). The summit becomes situated a few months 
after the previous release, and right at the start of the planning cycle 
for the next next release.


As a result, the kind of sessions we expect developers to continue to 
host at the summit are exactly the kind we can make most difference in: 
gathering feedback from the previous release, discussing requirements 
for the next next release and cross-project planning and strategy.


In that other, "new" separate developer-oriented event, the plan is that 
the discussions are about the code, not the concepts. The "How" to do 
things that were already discussed at the summit. Unless you're a 
hardcore python folk, or have specific interest in the deep details of 
how something works, in theory there'd be nothing of there of interest.


So, I think that by re-tasking the summit time, I think we actually end 
up with much more relevance at the summit for ops. The details are to be 
worked out in coming months, please participate on openstack-dev to 
ensure that we continue to achieve the "Open Design" goals of this project.



Finally, to answer one specific question:

Also where do the current operators design sessions and operators 
midcycle fit in here?


The changes in the proposal don't touch anything about the ops sessions 
at the design summit, or the ops events that happen during the cycle, 
unless you think its a good thing to do :) I have some ideas saved over 
from our last thread talking about those events, but will propose we 
move to a separate thread for this specifically to avoid drowning -dev ;)




Regards,


Tom

On 22/02/16 23:14, Thierry Carrez wrote:

Hi everyone,

TL;DR: Let's split the events, starting after Barcelona.

Long long version:

In a global and virtual community, high-bandwidth face-to-face time is
essential. This is why we made the OpenStack Design Summits an integral
part of our processes from day 0. Those were set at the beginning of
each of our development cycles to help set goals and organize the work
for the upcoming 6 months. At the same time and in the same location, a
more traditional conference was happening, ensuring a lot of interaction
between the upstream (producers) and downstream (consumers) parts of our
community.

This setup, however, has a number of issues. For developers first: the
"conference" part of the common event got bigger and bigger and it is
difficult to focus on upstream work (and socially bond with your
teammates) with so much other commitments and distractions. The result
is that our design summits are a lot less productive than they used to
be, and we organize other events ("midcycles") to fill our focus and
small-group socialization needs. The timing of the event (a couple of
weeks after the previous cycle release) is also suboptimal: it is way
too late to gather any sort of requirements and priorities for the
already-started new cycle, and also too late to do any sort of work
planning (the cycle work started almost 2 months ago).

But it's not just suboptimal for developers. For contributing companies,
flying all their developers to expensive cities and conference hotels so
that they can attend the Design Summit is pretty costly, and the goals
of the summit location (reaching out to users everywhere) do not
necessarily align with the goals of the Design Summit location (minimize
and balance travel costs for existing contributors). For the companies
that build products and distributions on top of the recent release, the
timing of the common event is not so great either: it is difficult to
show off products based on the recent release only two weeks after it's
out. The summit date is also too early to leverage all the users
attending the summit to gather feedback on the recent release -- not a
lot of people would have tried upgrades by summit time. Finally a common
event is also suboptimal for the events organization : finding venues
that can accommodate both events is becoming increasingly complicated.

Time is ripe for a change. After Tokyo, we at the Foundation have been
considering options on how to evolve our events to solve those issues.
This proposal is the result of this work. There is no perfect solution
here (and this is still work in progress), but we are confident that
this strawman solution solves a lot more problems than it creates, and
balances the needs of the various constituents of our community.

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Eoghan Glynn wrote:

Thanks for the proposal, just a few questions:

  * how would we achieve a "scaled-down design summit in Barcelona"? i.e.
what would be the forcing function to ensure fewer contributors attend,
given that some people will already be making plans?


Exactly how much the Barcelona Design Summit will be scaled down is 
still an open question. If Ocata ends up being a shorter cycle, there 
should be less design discussions needed (especially if some projects 
opt to turn Ocata into a "stabilization cycle"). As a result there 
should be less space requests and we should be able to "scale down" to 
using slightly less rooms.



  * would free passes continue to be issued to all ATCs, for *both* the
conference and the contributor event? (absent cross-subsidization at
the latter event from non-ATC attendees paying full whack)


The contributor event would likely be free for existing contributors to 
attend. Then the idea would be to offer a discount to attend the main 
summit to any person that was physically present at the contributors 
event. That should help control the costs for those who want to attend 
them all.



  * if reducing travel costs is part of the aim here, would it be wise not
to hold the second contributor event per-year in mid-August, when in
Europe at least the cost of flights and hotels spike upwards and the
availability of individual contributors tends to plummet due to PTO.

  * would it better to keep the ocata cycle at a more normal length, and
then run the "contributor events" in Mar/Sept, as opposed to Feb/Aug?
(again to avoid the August black hole)


This is a good point. The reason February / August were picked is that 
the dates for the main summits in 2017 are already ~known (see picture) 
and placing (for example) the P contributors event in early September 
means the summit would happen before the middle of the dev cycle, when 
it's too early to start discussing requirements for the next cycle.


It's still an option though... And over the long run nothing prevents us 
from moving the summit more toward the end of November / start of 
December and end of May / start of June, to allow for a start of March / 
start of September contributors event.


I expect we'll have a session in Austin to discuss all this.


  * instead of collocating any surviving mid-cycles with the more glitzy
conference-style event (which seems to run counter to the midcycle
ethos AIUI), why not allow these to continue running per-project in
unofficial mode in donated office space? (if projects consider them
still needed)


We can't really prevent people from organizing those anyway :) I just 
hope social in-person team gatherings will not be needed as much with 
this split. What may still be needed are mid-cycle "sprints" to achieve 
specific objectives: those could happen in hackathon space at the main 
summit, in donated office space, or online.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Henry Nash wrote:

On 22 Feb 2016, at 17:45, Thierry Carrez  wrote:

Amrith Kumar wrote:

[...]
As a result of this proposal, there will still be four events each year, two "OpenStack 
Summit" events and two "MidCycle" events.


Actually, the OpenStack summit becomes the midcycle event. The new separated 
contributors-oriented event[tm] happens at the beginning of the new cycle.


So in general a well thought out proposal - and it certainly helps address some 
of the early concerns over a “simplistic” split. I was also worrying, however, 
about the reduction in developer face time - it wasn’t immediate clear that the 
main summit could be treated as a developer midcycle. Is the idea that we just 
let this be informally organized by the projects, or tha there would at least 
be room set aside for each project (but without all the formal cross-project 
structure/agenda that there is in a main developer summit)?


How exactly the upstream sessions would be organized at the main 
"summit" event is still an open discussion.


I hear you and John worrying about reducing developer "face time" from 4 
to 2 events per year. On one hand I really think that with this proposed 
split, most teams will get enough face-to-face time with one focused 
event, or will be fine with holding online midcycle sprints. It should 
go a long way to reduce travel costs for most contributors to 2 events 
per year. Worries about exploding contributors travel costs are one of 
the issues that this proposal aims to address.


On the other hand, *some* teams may still need another face-time event 
-- initial team building, solve a very specific issue, whatever. They 
have the opportunity to leverage the main summit as a midcycle venue 
space, or they could even organize their own separate thing. This 
proposal doesn't reduce any dev face time. It just makes it less likely 
that midcycle events would be needed, and provides a default venue to 
hold them in case you end up still needing them.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Tim Bell wrote:

On 22/02/16 17:27, "John Garbutt"  wrote:

[...]
I am sure there are more questions that will pop up. Like I assume
this means there is no ATC free pass to the summit? And I guess a
small nominal fee for the contributor meetup (like the recent ops
meetup, to help predict numbers of accurately)? I guess that helps
level the playing field for contributors who don't put git commits in
the repo (I am thinking vocal operators that don't contribute code).
But I probably shouldn't go into all that just yet.


I would like to find a way to allow contributors cheaper access to the summits. 
Many of the devOPS contributors are patching test cases, configuration 
management recipes and documentation which should be rewarded in some form.

Assuming that many of the ATCs are not so motivated to attend the summit, the 
cost in offering access to the event would not be significant.

Charging for the Ops meetups was, to my understanding, more to confirm 
commitment to attend given limited space.

Thus, I would be in favour of a preferential rate for contributors (whether ATC 
is the right criteria is a different question) for summits.


Current thinking would be to give preferential rates to access the main 
summit to people who are present to other events (like this new 
separated contributors-oriented event, or Ops midcycle(s)). That would 
allow for a wider definition of "active community member" and reduce gaming.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[michael mccune]

On 02/22/2016 11:33 AM, Jay Pipes wrote:

OpenStack:How <-- The developer planning event.

:)


very nice ;)


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[michael mccune]

On 02/22/2016 11:06 AM, Dmitry Tantsur wrote:

+1 here. I got an impression that midcycles now usually happen in the
US. Indeed, it's probably much cheaper for the majority of contributors,
but would make things worse for non-US folks.


cost of travel has been a big reason we have never managed to have a 
sahara mid-cycle, as the team is evenly split across the world.


mike


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[michael mccune]

On 02/22/2016 10:14 AM, Thierry Carrez wrote:

Hi everyone,

TL;DR: Let's split the events, starting after Barcelona.


as a developer, i'm +1 for this. thanks for all the hard work putting 
this together Thierry.


mike


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Matt Fischer]

On Mon, Feb 22, 2016 at 11:51 AM, Tim Bell  wrote:

>
>
>
>
>
> On 22/02/16 17:27, "John Garbutt"  wrote:
>
> >On 22 February 2016 at 15:31, Monty Taylor  wrote:
> >> On 02/22/2016 07:24 AM, Russell Bryant wrote:
> >>> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez <
> thie...@openstack.org
>  > wrote:
>  Hi everyone,
>  TL;DR: Let's split the events, starting after Barcelona.
> >>> This proposal sounds fantastic.  Thank you very much to those that help
> >>> put it together.
> >> Totally agree. I think it's an excellent way to address the concerns and
> >> balance all of the diverse needs we have.
> >
> >tl;dr
> >+1
> >Awesome work ttx.
> >Thank you!
> >
> >Cheaper cities & venues should make it easier for more contributors to
> >attend. Thats a big deal. This also feels like enough notice to plan
> >for that.
> >
> >I think this means summit talk proposal deadline is both after the
> >previous release, and after the contributor event for the next
> >release? That should help keep proposals concrete (less guess work
> >when submitting). Nice.
> >
> >Dev wise, it seems equally good timing. Initially I was worried about
> >the event distracting from RC bugs, but actually I can see this
> >helping.
> >
> >I am sure there are more questions that will pop up. Like I assume
> >this means there is no ATC free pass to the summit? And I guess a
> >small nominal fee for the contributor meetup (like the recent ops
> >meetup, to help predict numbers of accurately)? I guess that helps
> >level the playing field for contributors who don't put git commits in
> >the repo (I am thinking vocal operators that don't contribute code).
> >But I probably shouldn't go into all that just yet.
>
> I would like to find a way to allow contributors cheaper access to the
> summits. Many of the devOPS contributors are patching test cases,
> configuration management recipes and documentation which should be rewarded
> in some form.
>
> Assuming that many of the ATCs are not so motivated to attend the summit,
> the cost in offering access to the event would not be significant.
>
> Charging for the Ops meetups was, to my understanding, more to confirm
> commitment to attend given limited space.
>
> Thus, I would be in favour of a preferential rate for contributors
> (whether ATC is the right criteria is a different question) for summits.
>
>
> Tim


I believe this is already the case. Unless I'm mistaken contributing to a
big tent config management project like the openstack puppet modules or
chef counts for ATC. I'm not sure if osad is big tent but if so it would
also count. Test cases and Docs also already count.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Eoghan Glynn]

> Hi everyone,
> 
> TL;DR: Let's split the events, starting after Barcelona.
> 
> Long long version:
> 
> In a global and virtual community, high-bandwidth face-to-face time is
> essential. This is why we made the OpenStack Design Summits an integral
> part of our processes from day 0. Those were set at the beginning of
> each of our development cycles to help set goals and organize the work
> for the upcoming 6 months. At the same time and in the same location, a
> more traditional conference was happening, ensuring a lot of interaction
> between the upstream (producers) and downstream (consumers) parts of our
> community.
> 
> This setup, however, has a number of issues. For developers first: the
> "conference" part of the common event got bigger and bigger and it is
> difficult to focus on upstream work (and socially bond with your
> teammates) with so much other commitments and distractions. The result
> is that our design summits are a lot less productive than they used to
> be, and we organize other events ("midcycles") to fill our focus and
> small-group socialization needs. The timing of the event (a couple of
> weeks after the previous cycle release) is also suboptimal: it is way
> too late to gather any sort of requirements and priorities for the
> already-started new cycle, and also too late to do any sort of work
> planning (the cycle work started almost 2 months ago).
> 
> But it's not just suboptimal for developers. For contributing companies,
> flying all their developers to expensive cities and conference hotels so
> that they can attend the Design Summit is pretty costly, and the goals
> of the summit location (reaching out to users everywhere) do not
> necessarily align with the goals of the Design Summit location (minimize
> and balance travel costs for existing contributors). For the companies
> that build products and distributions on top of the recent release, the
> timing of the common event is not so great either: it is difficult to
> show off products based on the recent release only two weeks after it's
> out. The summit date is also too early to leverage all the users
> attending the summit to gather feedback on the recent release -- not a
> lot of people would have tried upgrades by summit time. Finally a common
> event is also suboptimal for the events organization : finding venues
> that can accommodate both events is becoming increasingly complicated.
> 
> Time is ripe for a change. After Tokyo, we at the Foundation have been
> considering options on how to evolve our events to solve those issues.
> This proposal is the result of this work. There is no perfect solution
> here (and this is still work in progress), but we are confident that
> this strawman solution solves a lot more problems than it creates, and
> balances the needs of the various constituents of our community.
> 
> The idea would be to split the events. The first event would be for
> upstream technical contributors to OpenStack. It would be held in a
> simpler, scaled-back setting that would let all OpenStack project teams
> meet in separate rooms, but in a co-located event that would make it
> easy to have ad-hoc cross-project discussions. It would happen closer to
> the centers of mass of contributors, in less-expensive locations.
> 
> More importantly, it would be set to happen a couple of weeks /before/
> the previous cycle release. There is a lot of overlap between cycles.
> Work on a cycle starts at the previous cycle feature freeze, while there
> is still 5 weeks to go. Most people switch full-time to the next cycle
> by RC1. Organizing the event just after that time lets us organize the
> work and kickstart the new cycle at the best moment. It also allows us
> to use our time together to quickly address last-minute release-critical
> issues if such issues arise.
> 
> The second event would be the main downstream business conference, with
> high-end keynotes, marketplace and breakout sessions. It would be
> organized two or three months /after/ the release, to give time for all
> downstream users to deploy and build products on top of the release. It
> would be the best time to gather feedback on the recent release, and
> also the best time to have strategic discussions: start gathering
> requirements for the next cycle, leveraging the very large cross-section
> of all our community that attends the event.
> 
> To that effect, we'd still hold a number of strategic planning sessions
> at the main event to gather feedback, determine requirements and define
> overall cross-project themes, but the session format would not require
> all project contributors to attend. A subset of contributors who would
> like to participate in this sessions can collect and relay feedback to
> other team members for implementation (similar to the Ops midcycle).
> Other contributors will also want to get more involved in the
> conference, whether that's giving presentations or hearing user stories.
> 
> The split should 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Rico Lin]

+1
I believe that separate design summit give the chances for operators and
users can focus on design sessions and gives some great feedback during
design summit. We just have to think about how we attract them to there.


2016-02-23 6:07 GMT+08:00 Flavio Percoco :

>
>
> On Mon, Feb 22, 2016 at 11:31 AM, Monty Taylor 
> wrote:
>
>> On 02/22/2016 07:24 AM, Russell Bryant wrote:
>>
>>>
>>>
>>> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez >> > wrote:
>>>
>>> Hi everyone,
>>>
>>> TL;DR: Let's split the events, starting after Barcelona.
>>>
>>>
>>> This proposal sounds fantastic.  Thank you very much to those that help
>>> put it together.
>>>
>>
>> Totally agree. I think it's an excellent way to address the concerns and
>> balance all of the diverse needs we have.
>>
>> Thank you very much!
>>
>
> +1
>
> I don't have much to say as my questions have been asked and answered
> already (co-loation, regional events, etc etc). I believe the proposal is
> great and I'd love to see it happening.
>
> Flavio
>
> --
> @flaper87
> Flavio Percoco
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Best regards,

*Rico Lin*

迎棧科技股份有限公司
│ 886-963-612-021
│ ric...@inwinstack.com
│ 886-2-7738-6804 #7754
│ 新北市220板橋區遠東路3號5樓C室
Rm.C, 5F., No.3, Yuandong Rd.,
Banqiao Dist., New Taipei City 220, Taiwan (R.O.C)
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Flavio Percoco]

On Mon, Feb 22, 2016 at 11:31 AM, Monty Taylor  wrote:

> On 02/22/2016 07:24 AM, Russell Bryant wrote:
>
>>
>>
>> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > > wrote:
>>
>> Hi everyone,
>>
>> TL;DR: Let's split the events, starting after Barcelona.
>>
>>
>> This proposal sounds fantastic.  Thank you very much to those that help
>> put it together.
>>
>
> Totally agree. I think it's an excellent way to address the concerns and
> balance all of the diverse needs we have.
>
> Thank you very much!
>

+1

I don't have much to say as my questions have been asked and answered
already (co-loation, regional events, etc etc). I believe the proposal is
great and I'd love to see it happening.

Flavio

--
@flaper87
Flavio Percoco
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Flavio Percoco]

On Mon, Feb 22, 2016 at 1:52 PM, Jay Pipes  wrote:

> On 02/22/2016 12:45 PM, Thierry Carrez wrote:
>
>> I don't think the proposal removes that opportunity. Contributors /can/
>> still go to OpenStack Summits. They just don't /have to/. I just don't
>> think every contributor needs to be present at every OpenStack Summit,
>> while I'd like to see most of them present at every separated
>> contributors-oriented event[tm].
>>
>
> Yes. This. A thousand this.


Fully agreed here!

--
@flaper87
Flavio Percoco
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Devananda van der Veen]

On Mon, Feb 22, 2016 at 11:51 AM, Walter A. Boring IV  wrote:

> On 02/22/2016 09:45 AM, Thierry Carrez wrote:
>
>> Amrith Kumar wrote:
>>
>>> [...]
>>> As a result of this proposal, there will still be four events each year,
>>> two "OpenStack Summit" events and two "MidCycle" events.
>>>
>>
>> Actually, the OpenStack summit becomes the midcycle event. The new
>> separated contributors-oriented event[tm] happens at the beginning of the
>> new cycle.
>>
>> [...]
>>> Given the number of projects, and leaving aside high bandwidth internet
>>> and remote participation, providing dedicated meeting room for the duration
>>> of the MidCycle event for each project is a considerable undertaking. I
>>> believe therefore that the consequence is that the MidCycle event will end
>>> up being of comparable scale to the current Design Summit or larger, and
>>> will likely need a similar venue.
>>>
>>
>> It still is an order of magnitude smaller than the "OpenStack Summit".
>> Think 600 people instead of 6000. The idea behind co-hosting is to
>> facilitate cross-project interactions. You know where to find people, and
>> you can easily arrange a meeting between two teams for an hour.
>>
>> [...]
>>> At the current OpenStack Summit, there is an opportunity for
>>> contributors, customers and operators to interact, not just in technical
>>> meetings, but also in a social setting. I think this is valuable, even
>>> though there seems to be a number of people who believe that this is not
>>> necessarily the case.
>>>
>>
>> I don't think the proposal removes that opportunity. Contributors /can/
>> still go to OpenStack Summits. They just don't /have to/. I just don't
>> think every contributor needs to be present at every OpenStack Summit,
>> while I'd like to see most of them present at every separated
>> contributors-oriented event[tm].
>>
>
> Yes they can, but if contributors go to the design summit, then they also
> have to get travel budget to go to the new Summit.   So, design summits,
> midcycle meetups, and now the split off marketing summit.   This is making
> it overall more expensive for contributors that meet with customers.
>
>
I do not believe this proposal will increase the travel requirements on
contributors. AIUI, there would still be two Conferences per year (but
without the attached design summit) and still be two design/planning events
(with all the projects together, instead of individual midcycles) per year.
That's it.
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Devananda van der Veen]

On Mon, Feb 22, 2016 at 7:14 AM, Thierry Carrez 
wrote:

> Hi everyone,
>
> TL;DR: Let's split the events, starting after Barcelona
>

Thank you for the excellent write-up, Thierry (and everyone else behind
it)! This sounds great to me.


> Long long version:
>
> In a global and virtual community, high-bandwidth face-to-face time is
> essential. This is why we made the OpenStack Design Summits an integral
> part of our processes from day 0. Those were set at the beginning of each
> of our development cycles to help set goals and organize the work for the
> upcoming 6 months. At the same time and in the same location, a more
> traditional conference was happening, ensuring a lot of interaction between
> the upstream (producers) and downstream (consumers) parts of our community.
>
> This setup, however, has a number of issues. For developers first: the
> "conference" part of the common event got bigger and bigger and it is
> difficult to focus on upstream work (and socially bond with your teammates)
> with so much other commitments and distractions. The result is that our
> design summits are a lot less productive than they used to be, and we
> organize other events ("midcycles") to fill our focus and small-group
> socialization needs. The timing of the event (a couple of weeks after the
> previous cycle release) is also suboptimal: it is way too late to gather
> any sort of requirements and priorities for the already-started new cycle,
> and also too late to do any sort of work planning (the cycle work started
> almost 2 months ago).
>
> But it's not just suboptimal for developers. For contributing companies,
> flying all their developers to expensive cities and conference hotels so
> that they can attend the Design Summit is pretty costly, and the goals of
> the summit location (reaching out to users everywhere) do not necessarily
> align with the goals of the Design Summit location (minimize and balance
> travel costs for existing contributors). For the companies that build
> products and distributions on top of the recent release, the timing of the
> common event is not so great either: it is difficult to show off products
> based on the recent release only two weeks after it's out. The summit date
> is also too early to leverage all the users attending the summit to gather
> feedback on the recent release -- not a lot of people would have tried
> upgrades by summit time. Finally a common event is also suboptimal for the
> events organization : finding venues that can accommodate both events is
> becoming increasingly complicated.
>
> Time is ripe for a change. After Tokyo, we at the Foundation have been
> considering options on how to evolve our events to solve those issues. This
> proposal is the result of this work. There is no perfect solution here (and
> this is still work in progress), but we are confident that this strawman
> solution solves a lot more problems than it creates, and balances the needs
> of the various constituents of our community.
>
> The idea would be to split the events. The first event would be for
> upstream technical contributors to OpenStack. It would be held in a
> simpler, scaled-back setting that would let all OpenStack project teams
> meet in separate rooms, but in a co-located event that would make it easy
> to have ad-hoc cross-project discussions. It would happen closer to the
> centers of mass of contributors, in less-expensive locations.
>
> More importantly, it would be set to happen a couple of weeks /before/ the
> previous cycle release. There is a lot of overlap between cycles. Work on a
> cycle starts at the previous cycle feature freeze, while there is still 5
> weeks to go. Most people switch full-time to the next cycle by RC1.
> Organizing the event just after that time lets us organize the work and
> kickstart the new cycle at the best moment. It also allows us to use our
> time together to quickly address last-minute release-critical issues if
> such issues arise.
>
> The second event would be the main downstream business conference, with
> high-end keynotes, marketplace and breakout sessions. It would be organized
> two or three months /after/ the release, to give time for all downstream
> users to deploy and build products on top of the release. It would be the
> best time to gather feedback on the recent release, and also the best time
> to have strategic discussions: start gathering requirements for the next
> cycle, leveraging the very large cross-section of all our community that
> attends the event.


> To that effect, we'd still hold a number of strategic planning sessions at
> the main event to gather feedback, determine requirements and define
> overall cross-project themes, but the session format would not require all
> project contributors to attend. A subset of contributors who would like to
> participate in this sessions can collect and relay feedback to other team
> members for implementation (similar to the Ops 

Re: [openstack-dev] [all] A proposal to separate the design summit

[Walter A. Boring IV]

On 02/22/2016 09:45 AM, Thierry Carrez wrote:

Amrith Kumar wrote:

[...]
As a result of this proposal, there will still be four events each 
year, two "OpenStack Summit" events and two "MidCycle" events.


Actually, the OpenStack summit becomes the midcycle event. The new 
separated contributors-oriented event[tm] happens at the beginning of 
the new cycle.



[...]
Given the number of projects, and leaving aside high bandwidth 
internet and remote participation, providing dedicated meeting room 
for the duration of the MidCycle event for each project is a 
considerable undertaking. I believe therefore that the consequence is 
that the MidCycle event will end up being of comparable scale to the 
current Design Summit or larger, and will likely need a similar venue.


It still is an order of magnitude smaller than the "OpenStack Summit". 
Think 600 people instead of 6000. The idea behind co-hosting is to 
facilitate cross-project interactions. You know where to find people, 
and you can easily arrange a meeting between two teams for an hour.



[...]
At the current OpenStack Summit, there is an opportunity for 
contributors, customers and operators to interact, not just in 
technical meetings, but also in a social setting. I think this is 
valuable, even though there seems to be a number of people who 
believe that this is not necessarily the case.


I don't think the proposal removes that opportunity. Contributors 
/can/ still go to OpenStack Summits. They just don't /have to/. I just 
don't think every contributor needs to be present at every OpenStack 
Summit, while I'd like to see most of them present at every separated 
contributors-oriented event[tm].


Yes they can, but if contributors go to the design summit, then they 
also have to get travel budget to go to the new Summit.   So, design 
summits,  midcycle meetups, and now the split off marketing summit.   
This is making it overall more expensive for contributors that meet with 
customers.





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Walter A. Boring IV]

On 02/22/2016 07:14 AM, Thierry Carrez wrote:

Hi everyone,

TL;DR: Let's split the events, starting after Barcelona.


Time is ripe for a change. After Tokyo, we at the Foundation have been 
considering options on how to evolve our events to solve those issues. 
This proposal is the result of this work. There is no perfect solution 
here (and this is still work in progress), but we are confident that 
this strawman solution solves a lot more problems than it creates, and 
balances the needs of the various constituents of our community.


The idea would be to split the events. The first event would be for 
upstream technical contributors to OpenStack. It would be held in a 
simpler, scaled-back setting that would let all OpenStack project 
teams meet in separate rooms, but in a co-located event that would 
make it easy to have ad-hoc cross-project discussions. It would happen 
closer to the centers of mass of contributors, in less-expensive 
locations.
I'm trying to follow this here.   If we want all of the projects in the 
same location to hold a design summit, then all of the contributors are 
still going to have to do international travel, which is the primary 
cost for attendees.   I'm not sure how this saves the attendees much at 
all, unless they just stop attending. Part of the justification for 
myself for the summits is the ability to meet up with customers, as well 
as do presentations on the work that my team has done over the last 
release cycle, as well as the contributors meet up and cross project 
networking.   If we break the summits up, then I may lose the ability to 
justify my travel, if I don't get to meet with customers and do 
presentations to the wider audience.



What kind of locations are we talking about here? Are we looking to stay 
with one continent as it's deemed 'less-expensive'?  Will we still 
alternate between Americas, Europe, Asia?  I'm not sure there is a way 
to make it less expensive for all the projects as there are people from 
around the globe working on each project.



Walt





__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Sean McGinnis]

On Mon, Feb 22, 2016 at 05:20:21PM +, Amrith Kumar wrote:
> Thierry and all of those who contributed to putting together this write-up, 
> thank you very much.
> 
> TL;DR: +0
> 
> Longer version:
> 
> While I definitely believe that the new proposed timing for "OpenStack 
> Summit" which is some months after the release, is a huge improvement, I am 
> not completely enamored of this proposal. Here is why.
> 
> As a result of this proposal, there will still be four events each year, two 
> "OpenStack Summit" events and two "MidCycle" events. The material change is 
> that the "MidCycle" event that is currently project specific will become a 
> single event inclusive of all projects, not unlike our current "Design 
> Summit".
> 
> I contrast this proposal with a mid-cycle two weeks ago for the Trove 
> project. Thanks to the folks at Red Hat who hosted us in Raleigh, we had a 
> dedicated room, with high bandwidth internet and the ability to have people 
> join us remotely via audio and video (which we used mostly for screen 
> sharing). The previous mid-cycle similarly had excellent facilities provided 
> us by HP (in California), Rackspace (in Austin) and at MIT in Cambridge when 
> we (Tesora) hosted the event.
> 
> At these "simpler, scaled-back settings", would we be able to provide the 
> same kind of infrastructure for each project?
> 
> Given the number of projects, and leaving aside high bandwidth internet and 
> remote participation, providing dedicated meeting room for the duration of 
> the MidCycle event for each project is a considerable undertaking. I believe 
> therefore that the consequence is that the MidCycle event will end up being 
> of comparable scale to the current Design Summit or larger, and will likely 
> need a similar venue.
> 
> I also believe that it is important that OpenStack continue to grow not only 
> a global customer base but also a global contributor base. As others have 
> already commented, this proposal risks the "design summit" become US based, 
> maybe Europe once in a long while. But I find it much harder to believe that 
> these design summits would be truly global. And this I think would be an 
> unwelcome consequence.
> 
> At the current OpenStack Summit, there is an opportunity for contributors, 
> customers and operators to interact, not just in technical meetings, but also 
> in a social setting. I think this is valuable, even though there seems to be 
> a number of people who believe that this is not necessarily the case.
> 
> Those are the three concerns I have with the proposal. 
> 
> Thanks again to Thierry and all who contributed to putting this proposal 
> together.
> 
> -amrith

I agree with a lot of the concerns raised here. I wonder if we're not
just shifting some of the problems and causing others.

While the timing of things isn't ideal right now, I'm also afraid the
timing of these changes would also interupt our development flow and
cause distractions when we need folks focused on getting things done.

I'm also very concerned about losing our midcycles. At least for Cinder,
the midcycle events have been hugely successful and well worth the time
and travel expense, IMO. To me, the design summit event is good for
cross-project communication and getting more operator input. But the
midcycles have been where we've really been able to focus and figure out
issues.

Even if we still have a colocated "midcycle" now, I would be afraid that
there would be too many distractions from everything else going on for
us to be able to really tackle some of the things we've been able to in
our past midcycles.

There are definitely details we would need to work out with this
proposal, and I'm not saying I'm absolutely against it for now. I'm
trying to keep an open mind and see how this will improve things
overall. I would just ask that up front we plan on having a date set,
maybe after a year, where we plan to take a good look back on the
changes and decide whether they really have improved things or not.

Sean (smcginnis)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Shamail]

> On Feb 22, 2016, at 11:19 AM, Tim Bell  wrote:
> 
> 
>> On 22/02/16 18:35, "Thierry Carrez"  wrote:
>> 
>> Clayton O'Neill wrote:
>>> Is the expectation that the ops mid-cycle would continue separately,
>>> or be held with the meeting formerly known as the Design Summit?
>>> 
>>> Personally I’d prefer they be held together, but scheduled with the
>>> thought that operators aren’t likely to be interested in work
>>> sessions, but that a good number of us would be interested in
>>> cross-project and some project specific planning sessions.  This would
>>> also open up the possibility of having some sessions specific intended
>>> for operator/developer feedback sessions.
>> 
>> I'll let Tom comment on that, but the general idea in the strawman 
>> proposal was that the Ops "midcycle" event would be preserved as a 
>> separate event, but likely turn more and more regional to maximize local 
>> attendance. The rationale was that it's hard for ops to justify 
>> traveling to a contributors-branded event, while they can more easily 
>> justify going to the main OpenStack Summit user conference event, and to 
>> regional Ops gatherings.
>> 
>> But things are still pretty open on that front, so let's see what the 
>> feedback is.
> 
> Once we get the ideas reviewed, it would be good to validate it with the 
> -operators list too. There are some impacts on the value of the 
> summits/contributor sessions which would be worth checking to make sure the 
> feedback loops can be kept/enhanced.
> 
> Many will follow both lists but the volume of messages can lead to people 
> focussing on one or the other.
+1, a separate thread focused on Ops-meetups on the operators thread would be a 
great next step.
> 
> Tim
> 
> 
>> 
>> -- 
>> Thierry Carrez (ttx)
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Tim Bell]

On 22/02/16 18:35, "Thierry Carrez"  wrote:

>Clayton O'Neill wrote:
>> Is the expectation that the ops mid-cycle would continue separately,
>> or be held with the meeting formerly known as the Design Summit?
>>
>> Personally I’d prefer they be held together, but scheduled with the
>> thought that operators aren’t likely to be interested in work
>> sessions, but that a good number of us would be interested in
>> cross-project and some project specific planning sessions.  This would
>> also open up the possibility of having some sessions specific intended
>> for operator/developer feedback sessions.
>
>I'll let Tom comment on that, but the general idea in the strawman 
>proposal was that the Ops "midcycle" event would be preserved as a 
>separate event, but likely turn more and more regional to maximize local 
>attendance. The rationale was that it's hard for ops to justify 
>traveling to a contributors-branded event, while they can more easily 
>justify going to the main OpenStack Summit user conference event, and to 
>regional Ops gatherings.
>
>But things are still pretty open on that front, so let's see what the 
>feedback is.

Once we get the ideas reviewed, it would be good to validate it with the 
-operators list too. There are some impacts on the value of the 
summits/contributor sessions which would be worth checking to make sure the 
feedback loops can be kept/enhanced.

Many will follow both lists but the volume of messages can lead to people 
focussing on one or the other.

Tim


>
>-- 
>Thierry Carrez (ttx)
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Henry Nash]

> On 22 Feb 2016, at 17:45, Thierry Carrez  wrote:
> 
> Amrith Kumar wrote:
>> [...]
>> As a result of this proposal, there will still be four events each year, two 
>> "OpenStack Summit" events and two "MidCycle" events.
> 
> Actually, the OpenStack summit becomes the midcycle event. The new separated 
> contributors-oriented event[tm] happens at the beginning of the new cycle.

So in general a well thought out proposal - and it certainly helps address some 
of the early concerns over a “simplistic” split. I was also worrying, however, 
about the reduction in developer face time - it wasn’t immediate clear that the 
main summit could be treated as a developer midcycle. Is the idea that we just 
let this be informally organized by the projects, or tha there would at least 
be room set aside for each project (but without all the formal cross-project 
structure/agenda that there is in a main developer summit)?

>> [...]
>> Given the number of projects, and leaving aside high bandwidth internet and 
>> remote participation, providing dedicated meeting room for the duration of 
>> the MidCycle event for each project is a considerable undertaking. I believe 
>> therefore that the consequence is that the MidCycle event will end up being 
>> of comparable scale to the current Design Summit or larger, and will likely 
>> need a similar venue.
> 
> It still is an order of magnitude smaller than the "OpenStack Summit". Think 
> 600 people instead of 6000. The idea behind co-hosting is to facilitate 
> cross-project interactions. You know where to find people, and you can easily 
> arrange a meeting between two teams for an hour.
> 
>> [...]
>> At the current OpenStack Summit, there is an opportunity for contributors, 
>> customers and operators to interact, not just in technical meetings, but 
>> also in a social setting. I think this is valuable, even though there seems 
>> to be a number of people who believe that this is not necessarily the case.
> 
> I don't think the proposal removes that opportunity. Contributors /can/ still 
> go to OpenStack Summits. They just don't /have to/. I just don't think every 
> contributor needs to be present at every OpenStack Summit, while I'd like to 
> see most of them present at every separated contributors-oriented event[tm].
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Tim Bell]

On 22/02/16 17:27, "John Garbutt"  wrote:

>On 22 February 2016 at 15:31, Monty Taylor  wrote:
>> On 02/22/2016 07:24 AM, Russell Bryant wrote:
>>> On Mon, Feb 22, 2016 at 10:14 AM, Thierry Carrez > wrote:
 Hi everyone,
 TL;DR: Let's split the events, starting after Barcelona.
>>> This proposal sounds fantastic.  Thank you very much to those that help
>>> put it together.
>> Totally agree. I think it's an excellent way to address the concerns and
>> balance all of the diverse needs we have.
>
>tl;dr
>+1
>Awesome work ttx.
>Thank you!
>
>Cheaper cities & venues should make it easier for more contributors to
>attend. Thats a big deal. This also feels like enough notice to plan
>for that.
>
>I think this means summit talk proposal deadline is both after the
>previous release, and after the contributor event for the next
>release? That should help keep proposals concrete (less guess work
>when submitting). Nice.
>
>Dev wise, it seems equally good timing. Initially I was worried about
>the event distracting from RC bugs, but actually I can see this
>helping.
>
>I am sure there are more questions that will pop up. Like I assume
>this means there is no ATC free pass to the summit? And I guess a
>small nominal fee for the contributor meetup (like the recent ops
>meetup, to help predict numbers of accurately)? I guess that helps
>level the playing field for contributors who don't put git commits in
>the repo (I am thinking vocal operators that don't contribute code).
>But I probably shouldn't go into all that just yet.

I would like to find a way to allow contributors cheaper access to the summits. 
Many of the devOPS contributors are patching test cases, configuration 
management recipes and documentation which should be rewarded in some form.

Assuming that many of the ATCs are not so motivated to attend the summit, the 
cost in offering access to the event would not be significant.

Charging for the Ops meetups was, to my understanding, more to confirm 
commitment to attend given limited space.

Thus, I would be in favour of a preferential rate for contributors (whether ATC 
is the right criteria is a different question) for summits.


Tim

>
>Thanks,
>johnthetubaguy
>
>__
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

smime.p7s
Description: S/MIME cryptographic signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[John Dickinson]

Amrith raises an interesting point. This proposal moves from effectively 4 dev 
events a year to 2 dev events a year, thus *reducing* the amount of 
face-to-face time we have.

While my first reaction to the proposed changes is positive, de facto reduction 
of time spent together as devs seems counter-productive.

My thinking goes like this: we have mid-cycles currently. Regardless of if they 
are "required" or if they are official or not, effectively they are productive 
weeks that the most active contributors try to attend. And they are highly 
beneficial and productive weeks.

The current summits have time and space set aside for contributor 
communication. Over the last couple of years, these summit sessions have gotten 
better, not worse. While the current summit/conference design does indeed but a 
burden on some contributors (myself included--it's a really busy week), the 
majority of devs in the room during the current design sessions do *not* also 
have customer meetings, booth duty, two conference talks, and various company 
parties to attend.

I'm worried that we're losing valuable dev face-to-face time from the 
"long-tail" of contributors for the benefit of the minority of devs who are 
most active. And for those who are most active, we're still doing four events a 
year all over the world.


--John




On 22 Feb 2016, at 9:45, Thierry Carrez wrote:

> Amrith Kumar wrote:
>> [...]
>> As a result of this proposal, there will still be four events each year, two 
>> "OpenStack Summit" events and two "MidCycle" events.
>
> Actually, the OpenStack summit becomes the midcycle event. The new separated 
> contributors-oriented event[tm] happens at the beginning of the new cycle.
>
>> [...]
>> Given the number of projects, and leaving aside high bandwidth internet and 
>> remote participation, providing dedicated meeting room for the duration of 
>> the MidCycle event for each project is a considerable undertaking. I believe 
>> therefore that the consequence is that the MidCycle event will end up being 
>> of comparable scale to the current Design Summit or larger, and will likely 
>> need a similar venue.
>
> It still is an order of magnitude smaller than the "OpenStack Summit". Think 
> 600 people instead of 6000. The idea behind co-hosting is to facilitate 
> cross-project interactions. You know where to find people, and you can easily 
> arrange a meeting between two teams for an hour.
>
>> [...]
>> At the current OpenStack Summit, there is an opportunity for contributors, 
>> customers and operators to interact, not just in technical meetings, but 
>> also in a social setting. I think this is valuable, even though there seems 
>> to be a number of people who believe that this is not necessarily the case.
>
> I don't think the proposal removes that opportunity. Contributors /can/ still 
> go to OpenStack Summits. They just don't /have to/. I just don't think every 
> contributor needs to be present at every OpenStack Summit, while I'd like to 
> see most of them present at every separated contributors-oriented event[tm].
>
> -- 
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


signature.asc
Description: OpenPGP digital signature
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Michał Dulko]

On 02/22/2016 04:49 PM, Daniel P. Berrange wrote:
> On Mon, Feb 22, 2016 at 04:14:06PM +0100, Thierry Carrez wrote:
>> The idea would be to split the events. The first event would be for upstream
>> technical contributors to OpenStack. It would be held in a simpler,
>> scaled-back setting that would let all OpenStack project teams meet in
>> separate rooms, but in a co-located event that would make it easy to have
>> ad-hoc cross-project discussions. It would happen closer to the centers of
>> mass of contributors, in less-expensive locations.
> The idea that we can choose less expensive locations is great, but I'm a
> little wary of focusing too much on "centers of mass of contributors", as
> it can easily become an excuse to have it in roughly the same places each
> time. As a non-USA based contributor, I really value the fact the the
> summits rotate around different regions instead of spending all the time
> in the USA as was the case earlier in openstcck days. Minimizing travel
> costs is no doubt a welcome aim for companies' budgets, but it should not
> be allowed to dominate to such a large extent that we miss representation
> of different regions. ie if we never went back to Asia because the it is
> cheaper for the /current/ majority of contributors to go to the US, we'll
> make it harder to attract new contributors from those regions we avoid on
> cost ground. The "center of mass of contributors" could become a self-
> fullfilling prophecy.
>
> IOW, I'm onboard with choosing less expensive locations, but would like
> to see us still make the effort to reach out across different regions
> for the events, and not become too US focused once again.

As an EU-based contributor I have similar concerns. First OpenStack
Summit I was able to attend was in Paris and the fact that it was close
let us send almost entire team of contributors. That fact helped us in
future funding negotiations and we were able to maintain constant number
of contributors sent also to Summits far more expensive for us. I don't
believe that would be ever possible if all the conferences were
organized in the US.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Jay Pipes]

On 02/22/2016 12:45 PM, Thierry Carrez wrote:

I don't think the proposal removes that opportunity. Contributors /can/
still go to OpenStack Summits. They just don't /have to/. I just don't
think every contributor needs to be present at every OpenStack Summit,
while I'd like to see most of them present at every separated
contributors-oriented event[tm].


Yes. This. A thousand this.

-jay

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Amrith Kumar wrote:

[...]
As a result of this proposal, there will still be four events each year, two "OpenStack 
Summit" events and two "MidCycle" events.


Actually, the OpenStack summit becomes the midcycle event. The new 
separated contributors-oriented event[tm] happens at the beginning of 
the new cycle.



[...]
Given the number of projects, and leaving aside high bandwidth internet and 
remote participation, providing dedicated meeting room for the duration of the 
MidCycle event for each project is a considerable undertaking. I believe 
therefore that the consequence is that the MidCycle event will end up being of 
comparable scale to the current Design Summit or larger, and will likely need a 
similar venue.


It still is an order of magnitude smaller than the "OpenStack Summit". 
Think 600 people instead of 6000. The idea behind co-hosting is to 
facilitate cross-project interactions. You know where to find people, 
and you can easily arrange a meeting between two teams for an hour.



[...]
At the current OpenStack Summit, there is an opportunity for contributors, 
customers and operators to interact, not just in technical meetings, but also 
in a social setting. I think this is valuable, even though there seems to be a 
number of people who believe that this is not necessarily the case.


I don't think the proposal removes that opportunity. Contributors /can/ 
still go to OpenStack Summits. They just don't /have to/. I just don't 
think every contributor needs to be present at every OpenStack Summit, 
while I'd like to see most of them present at every separated 
contributors-oriented event[tm].


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Thierry Carrez]

Clayton O'Neill wrote:

Is the expectation that the ops mid-cycle would continue separately,
or be held with the meeting formerly known as the Design Summit?

Personally I’d prefer they be held together, but scheduled with the
thought that operators aren’t likely to be interested in work
sessions, but that a good number of us would be interested in
cross-project and some project specific planning sessions.  This would
also open up the possibility of having some sessions specific intended
for operator/developer feedback sessions.


I'll let Tom comment on that, but the general idea in the strawman 
proposal was that the Ops "midcycle" event would be preserved as a 
separate event, but likely turn more and more regional to maximize local 
attendance. The rationale was that it's hard for ops to justify 
traveling to a contributors-branded event, while they can more easily 
justify going to the main OpenStack Summit user conference event, and to 
regional Ops gatherings.


But things are still pretty open on that front, so let's see what the 
feedback is.


--
Thierry Carrez (ttx)

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Ricardo Carrillo Cruz]

+1

2016-02-22 18:27 GMT+01:00 Clayton O'Neill :

> Is the expectation that the ops mid-cycle would continue separately,
> or be held with the meeting formerly known as the Design Summit?
>
> Personally I’d prefer they be held together, but scheduled with the
> thought that operators aren’t likely to be interested in work
> sessions, but that a good number of us would be interested in
> cross-project and some project specific planning sessions.  This would
> also open up the possibility of having some sessions specific intended
> for operator/developer feedback sessions.
>
> On Mon, Feb 22, 2016 at 12:15 PM, Lauren Sell 
> wrote:
> >
> >> On Feb 22, 2016, at 8:52 AM, Clayton O'Neill 
> wrote:
> >>
> >> I think this is a great proposal, but like Matt I’m curious how it
> >> might impact the operator sessions that have been part of the Design
> >> Summit and the Operators Mid-Cycle.
> >>
> >> As an operator I got a lot out of the cross-project designs sessions
> >> in Tokyo, but they were scheduled at the same time as the Operator
> >> sessions.  On the other hand, the work sessions clearly aren’t as
> >> useful to me.  It would be nice would be worked out so that the new
> >> design summit replacement was in the same location, and scheduled so
> >> that the operator specific parts were overlapping the work sessions
> >> instead of the more big picture sessions.
> >
> > Great question. The current plan is to maintain the ops summit and
> mid-cycle activities.
> >
> > The new format would allow us to reduce overlap between ops summit and
> cross project sessions at the main event, both for the operators and
> developers who want to be involved in either activity.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Clayton O'Neill]

Is the expectation that the ops mid-cycle would continue separately,
or be held with the meeting formerly known as the Design Summit?

Personally I’d prefer they be held together, but scheduled with the
thought that operators aren’t likely to be interested in work
sessions, but that a good number of us would be interested in
cross-project and some project specific planning sessions.  This would
also open up the possibility of having some sessions specific intended
for operator/developer feedback sessions.

On Mon, Feb 22, 2016 at 12:15 PM, Lauren Sell  wrote:
>
>> On Feb 22, 2016, at 8:52 AM, Clayton O'Neill  wrote:
>>
>> I think this is a great proposal, but like Matt I’m curious how it
>> might impact the operator sessions that have been part of the Design
>> Summit and the Operators Mid-Cycle.
>>
>> As an operator I got a lot out of the cross-project designs sessions
>> in Tokyo, but they were scheduled at the same time as the Operator
>> sessions.  On the other hand, the work sessions clearly aren’t as
>> useful to me.  It would be nice would be worked out so that the new
>> design summit replacement was in the same location, and scheduled so
>> that the operator specific parts were overlapping the work sessions
>> instead of the more big picture sessions.
>
> Great question. The current plan is to maintain the ops summit and mid-cycle 
> activities.
>
> The new format would allow us to reduce overlap between ops summit and cross 
> project sessions at the main event, both for the operators and developers who 
> want to be involved in either activity.

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Lauren Sell]

> On Feb 22, 2016, at 8:52 AM, Clayton O'Neill  wrote:
> 
> I think this is a great proposal, but like Matt I’m curious how it
> might impact the operator sessions that have been part of the Design
> Summit and the Operators Mid-Cycle.
> 
> As an operator I got a lot out of the cross-project designs sessions
> in Tokyo, but they were scheduled at the same time as the Operator
> sessions.  On the other hand, the work sessions clearly aren’t as
> useful to me.  It would be nice would be worked out so that the new
> design summit replacement was in the same location, and scheduled so
> that the operator specific parts were overlapping the work sessions
> instead of the more big picture sessions.

Great question. The current plan is to maintain the ops summit and mid-cycle 
activities. 

The new format would allow us to reduce overlap between ops summit and cross 
project sessions at the main event, both for the operators and developers who 
want to be involved in either activity.

> 
> On Mon, Feb 22, 2016 at 11:32 AM, Matt Fischer  wrote:
>> Cross-post to openstack-operators...
>> 
>> As an operator, there's value in me attending some of the design summit
>> sessions to provide feedback and guidance. But I don't really need to be in
>> the room for a week discussing minutiae of implementations. So I probably
>> can't justify 2 extra trips just to give a few hours of feedback/discussion.
>> If this is indeed the case for some other folks we'll need to do a good job
>> of collecting operator feedback at the operator sessions (perhaps hopefully
>> with reps from each major project?). We don't want projects operating in a
>> vacuum when it comes to major decisions.
>> 
>> Also where do the current operators design sessions and operators midcycle
>> fit in here?
>> 
>> (apologies for not replying directly to the first message, gmail seems to
>> have lost it).
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] A proposal to separate the design summit

[Ed Leafe]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 02/22/2016 10:45 AM, Jay Pipes wrote:

>> If you now have a separate summit/meeting for the developers away
>> from the big splashy business event, I'm wondering if we might
>> make it harder for many developers to get funded for this
>> travel.
> 
> I happen to work for one of the aforementioned companies. The
> challenge is on me to explain to management the productivity gains
> that can be gotten from sending greater quantities of developers to
> the smaller working events.
> 
> I gratefully accept this challenge.

I work for such a company, too, and I suspect that the layers of
management that need such convincing are much further removed in my
case. You and I, though, might have a little more clout than, let's
say, someone just starting out in OpenStack.

- -- 

- -- Ed Leafe
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCgAGBQJWyz+xAAoJEKMgtcocwZqLdjsP/2O5sA5JA3qr2HiZ+1z8ZI2Q
x3VLcxcIpuBm3f+pROjn57xn3ht5IXlmJSDSlHA5nXybFkUp9ZPSkzvV63/Gohqd
qPU2+ebRqKfjNaewMI6GjtjT6U/ECjPQkpL2DA+ZC5xlF1CHd5vfpBY1bm4VPDFG
FszhhcS0dYL/ioDia4E6rXVUvzPcajQfD167RSSagOu3shfvWpc+jDnREgxIEPVM
8YrWutjtDW0q595oLU6dwA3AYu7r0aJ7xfPOl6N6znHKFRE1tguzHLcRO/PgY7mf
+2/XORSqo/4TGi5PedCpYKH56lys3lxJL6HLihr6ejj/nD+3u681xoSPOeBpPzMl
tc0dwYUSwSHSGz4b/IyBj5FFASMSGlcKJI6i226YBCNM0fFDOFwvUnKIa0OSmVRI
4IyrO10g37JNrHIOthySFPftJeliNOFNpO2v3e/WT+QA7IFd3YL0kxiN6zX0mpnm
Cw6V3eIS3bHezdQRLRvpf03KmuTLAAi0Lgz7CRxJ7+efx0OMguGFfApe5W3w+jdS
8cvtVocDX89BZpJ7y5zX3MQwjTnd93wRP0DPwcG82zXTZ+v3rnacIdodLN47lcGk
sAuxoXOwl+gYK874Rm1lm1iVUmuqH7VwK/Cc9lKs5Mz7XP9jNwvruo4+lz36gNxt
byqqVs8ood/lKPHLJojl
=i4ZL
-END PGP SIGNATURE-

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev