Open Stack

On Thu, Jul 2, 2015 at 2:26 PM, Jesse Keating <jlk at bluebox.net> wrote:
> BoD, unless they feel the need to delegate, at which point then maybe an
> Operators committee. But I'd hate to see more committees created.

I feel like this may be a User Committee thing, which is an existing
committee and sort-of-kind-of how this started I think.  Granted
that's a bit of a shadowy cabal at this point but hopefully we're on a
path to a better place with that...

-Jon

>
> - jlk
>
> On Thu, Jul 2, 2015 at 11:23 AM, Matt Fischer <matt at mattfischer.com> wrote:
>>
>> Are you proposing an Operators committee or do you mean the OpenStack BoD?
>>
>> On Thu, Jul 2, 2015 at 12:15 PM, Jesse Keating <jlk at bluebox.net> wrote:
>>>
>>> Honestly I'm fine with the elected board helping to make this decision.
>>> Folks that want to underwrite the event can submit a proposal to host, board
>>> picks from the submissions? Having a wide vote on it seems overkill to me.
>>>
>>> Open call for submissions, board votes. Is that unreasonable?
>>>
>>>
>>> - jlk
>>>
>>> On Thu, Jul 2, 2015 at 8:23 AM, Tom Fifield <tom at openstack.org> wrote:
>>>>
>>>> OK, so I'm just going to throw this one out there to re-stoke the
>>>> discussion ...
>>>>
>>>> Venue selection process.
>>>>
>>>> At the moment, there's a few of us who work hard in the shadows to make
>>>> the best choice we can from a range of generous offers :)
>>>>
>>>> In our brave new world, I think this should be a bit more open, what do
>>>> you think?
>>>>
>>>> What kind of structure do we need to make the best decision?
>>>>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Tom
>>>>
>>>>
>>>> On 01/07/15 15:29, Tom Fifield wrote:
>>>> > Team,
>>>> >
>>>> > It's great to see so much passion! :)
>>>> >
>>>> > Here's an attempt at a summary email. I'll wait until a later email to
>>>> > wade into the discussion myself ;) Feel free to jump in on any point.
>>>> >
>>>> > =Things we tend to agree on=
>>>> > "Spirit of the event"
>>>> > * The response most people had in common was that they didn't want to
>>>> > see vendor booths :) Several others noted the importance that the
>>>> > event
>>>> > should remain accessible and ensure there were no barriers to
>>>> > attendance, space for networking with others and sharing information
>>>> > about deployments without fear of vendor harassment.
>>>> >
>>>> > Multiple Sponsors
>>>> > * are OK, but they are more like underwriters who should be OK with
>>>> > only
>>>> > modest acknowledgement (see previous: no booths). Preference for
>>>> > operator sponsors. Several ways to recognise them possible.
>>>> >
>>>> > Current Schedule Format
>>>> > * It appeared like the current format is working well in general, but
>>>> > could do with minor tweaks.
>>>> >
>>>> >
>>>> > =Things still under discussion=
>>>> > Sell Tickets
>>>> > * Many people agreed that some moderate form of ticketing could be OK,
>>>> > but the question remains to what extent this should be priced ("low
>>>> > fee"? $100-200? "cover costs"?). A strong counterpoint was that paid
>>>> > ticketing makes it less accessible (see "spirit"), prevents some local
>>>> > attendance, and is unfair to smaller operators, though others noted
>>>> > that
>>>> > it may be the only practical way to raise funds in the future.
>>>> >
>>>> > Break into Regional Events
>>>> > * A number of viewpoints, ranging from "multiple regional events" to
>>>> > "one event only [maybe with a travel fund]" to "one event that moves
>>>> > around [maybe even outside USA]" to "make it in the centre of USA for
>>>> > easier travel on average".
>>>> >
>>>> >
>>>> > Capping Numbers (inc. Limit Attendees per Company)
>>>> > * A lot of disagreement here. Many argued that any kind of cap or
>>>> > barrier to entry detracts from the accessibility of the event. Others
>>>> > put forth that too few restrictions could dilute the ops-heavy
>>>> > attendee
>>>> > base, and implied that large companies might send too many people.
>>>> >
>>>> >
>>>> > Multiple Tracks
>>>> > * To help deal with room size, we could split into multiple tracks.
>>>> > The
>>>> > ideal number of tracks is not clear at this stage.
>>>> >
>>>> > Evening Event
>>>> > * Several people said they found the PHL evening event uncomfortably
>>>> > packed, and suggested cancelling it on this basis, or on the basis of
>>>> > cost. Suggested alternate was posting a list of nearby venues.
>>>> >
>>>> > Lightening Talks
>>>> > * Have lightening talks, perhaps by renaming "show and tell". More of
>>>> > them? Arranged differently? Unclear.
>>>> >
>>>> > =Ideas=
>>>> > * Video Recording - Might be worth a shot, starting small.
>>>> > * Travel Fund, Scholarship Fund, Slush Fund
>>>> > * Use Universities during the summer break for venues
>>>> >
>>>> > =Open Questions=
>>>> > * How will the number of attendees grow?
>>>> > * What are the costs involved in hosting one of these events?
>>>> > * Stuff about the summit - probably need a different thread for this
>>>> >
>>>> >
>>>> > Regards,
>>>> >
>>>> >
>>>> > Tom
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On 30/06/15 12:33, Tom Fifield wrote:
>>>> >> Hi all,
>>>> >>
>>>> >> Right now, behind-the-scenes, we're working on getting a venue for
>>>> >> next
>>>> >> ops mid-cycle. It's taking a little longer than normal, but rest
>>>> >> assured
>>>> >> it is happening.
>>>> >>
>>>> >> Why is it so difficult? As you may have noticed, we're reaching the
>>>> >> size
>>>> >> of event where both physically and financially, only the largest
>>>> >> organisations can host us.
>>>> >>
>>>> >> We thought we might get away with organising this one old-school with
>>>> >> a
>>>> >> single host and sponsor. Then, for the next, start a brainstorming
>>>> >> discussion with you about how we scale these events into the future -
>>>> >> since once we get up and beyond a few hundred people, we're looking
>>>> >> at
>>>> >> having to hire a venue as well as make some changes to the format of
>>>> >> the
>>>> >> event.
>>>> >>
>>>> >> However, it seems that even this might be too late. We already had a
>>>> >> company that proposed to host the meetup at a west coast US hotel
>>>> >> instead of their place, and wanted to scope out other companies to
>>>> >> sponsor food.
>>>> >>
>>>> >> This would be a change in the model, so let's commence the discussion
>>>> >> of
>>>> >> how we want to scale this event :)
>>>> >>
>>>> >> So far I've heard things like:
>>>> >> * "my $CORPORATE_BENEFACTOR would be fine to share sponsorship with
>>>> >> others"
>>>> >> * "I really don't want to get to the point where we want booths at
>>>> >> the
>>>> >> ops meetup"
>>>> >>
>>>> >> Which are promising! It seems like we have a shared understanding of
>>>> >> what to take this forward with.
>>>> >>
>>>> >> So, as the ops meetup grows - what would it look like for you?
>>>> >>
>>>> >> How do you think we can manage the venue selection and financial side
>>>> >> of
>>>> >> things? What about the session layout and the scheduling with the
>>>> >> growing numbers of attendees?
>>>> >>
>>>> >> Current data can be found at
>>>> >> https://wiki.openstack.org/wiki/Operations/Meetups#Venue_Selection .
>>>> >>
>>>> >> I would also be interested in your thoughts about how these events
>>>> >> have
>>>> >> only been in a limited geographical area so far, and how we can
>>>> >> address
>>>> >> that issue.
>>>> >>
>>>> >>
>>>> >> Regards,
>>>> >>
>>>> >>
>>>> >> Tom
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> OpenStack-operators mailing list
>>>> >> OpenStack-operators at lists.openstack.org
>>>> >>
>>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>> >>
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > OpenStack-operators mailing list
>>>> > OpenStack-operators at lists.openstack.org
>>>> >
>>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>> >
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-operators mailing list
>>>> OpenStack-operators at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>>
>>>
>>> _______________________________________________
>>> OpenStack-operators mailing list
>>> OpenStack-operators at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>>>
>>
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>