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