[openstack-dev] [nova] FYI, nova plans to have a room at the PTG in February

Sylvain Bauza sbauza at redhat.com
Tue Oct 11 08:42:05 UTC 2016



Le 10/10/2016 19:24, Clint Byrum a écrit :
> Excerpts from Matt Riedemann's message of 2016-10-10 11:51:36 -0500:
>> On 10/10/2016 8:59 AM, Sean McGinnis wrote:
>>> On Mon, Oct 10, 2016 at 08:37:53AM -0400, Doug Hellmann wrote:
>>>>> <snip>
>>>> We had a lot of feedback that the unstructured discussion time from
>>>> the Friday "meetups" at the summits were the most productive time
>>>> for teams, but I'm sure there are quite a few cases like what you
>>>> describe. Maybe the solution is to schedule part, but not all, of
>>>> the PTG time?
>>>>
>>>> It would be hard to say that a particular day is or is not scheduled,
>>>> because not all teams will have rooms available to them every day.
>>>> We could slice it the other way, though, and say that multi-project
>>>> topics should be scheduled in the morning. That still leaves all
>>>> of the afternoons for less structured discussions. Of course, not all
>>>> teams will necessarily have multi-project topics.
>>> Having even just one day of scheduled topics might make it easier to
>>> organize around topics that don't necessarily fall under the "cross
>>> project" category, yet still affect more than one project and would
>>> benefit from a set time for all to attend.
>>>
>>> Whether that is one day dedicated to that format, or something like AMs
>>> scheduled, PMs freeform, I do think it is good to have the mix. We've
>>> been able to make it through a lot of topics by not timeboxing certain
>>> things, so the unscheduled part definitely has benefit.
>>>
>>> The risk with an AM/PM split would be, as an example, that Nova has
>>> something scheduled that is significant to Cinder, so Cinder has to
>>> dedicated a scheduled slot to match up with it. Just a thought, but if
>>> we so split days like that, it might actually be good to have an A track
>>> and B track, where A tracks have AMs scheduled and B tracks have PMs
>>> scheduled. Maybe making things more complicated than they need to be,
>>> but if Nova has scheduled sessions in the morning and Cinder
>>> unscheduled, it might make it easy to take break and attend the other
>>> sessions, and vice versa.
>>>
>>> Sean (smcginnis)
>>>
>>> __________________________________________________________________________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>> I think we're probably over-complicating this. The nova/cinder midcycles
>> have happened at the same time in different timezones for the last two
>> releases. We've scheduled a time on a particular day and time that works
>> for both teams to get into a hangout session. Yes it's a scheduled
>> thing, but it's still pretty informal and when you only have to deal
>> with maybe a couple of those types of things during a midcycle it's not
>> overwhelming to plan ahead of time.
>>
>> If the PTG turns into the design summit with 40 minute blocks of
>> discussion, it's going to really negatively impact the productivity of
>> midcycles.
>>
> I think there's some perspective warping going on, and it's very
> concerning to me.
>
> Productivity inside the project is great, and we should definitely box
> out more than just one day of the PTG for just those high bandwidth
> internal project face to face discussions.
>
> However, I think there's a danger of siloing even further if all three
> days are just project team open ended face time. Those 40 minute sessions
> may not seem productive to the project team, but they are massively
> helpful for newcomers, for those who are shifting focus, and for those
> who want to influence design at the early stages. They're also incredibly
> useful for being able to tell the general developer community what the
> project is doing, which I'm surprised more people don't want.

I don't get why we would create silos if we respect the open agenda like 
we already do.
The only difference between Summit design sessions and midcycles is that 
we don't time-box the bullet points that we want to discuss, but we 
still expose those bullet points far before the event.
Take the Nova contributors meetup on Friday. That etherpad is pretty 
well public, and anyone can look at it to know that we'll discuss around 
those topics.
The only difference is that people don't know *when* during that day we 
will discuss a specific topic, but that's a question that Sean, Doug and 
Thierry already began to think about possible solutions.

A silo implies a will of not openly expose our thoughts and refrain 
communicating. Here, I think that's actually the contrary that will 
happen because we'll openly communicate live on the progress we're doing 
on our agenda, which was not the case before.

Either way, it could be confusing that the proposal aims to reduce 
attendance conflicts. Whatever the agenda is time-boxed or free, there 
will be cases where people would like to attend two simultaneous 
conversations, but that's a natural behaviour that we can't solve. The 
fact that you could be concerned by missing some crucial conversation 
because a conflict won't be solved by leaving us time-boxed. Just 
consider how the TC had hard time figuring out the right agenda proposal 
for time-boxed cross-project sessions at Barcelona, and you'll 
understand that's life.
The more projects you're engaged with, the most you could get conflicts, 
sure.

On a side note, I think we'll definitely *increase* communication 
because our contributors meetups are very good for people wanting to 
discuss about a specific feature that can't fit with the fishbowl 
sessions due to the very low number of slots we can accomodate. In 
general, we're far more productive during those meetups because not only 
we're not refrained by the time when we discuss, but also because it 
help some contributors to raise topics that they couldn't do if we were 
fully time-boxed.


> What I'd suggest is that we do have a single schedule, and that project
> teams schedule their time to suit their needs, with the
> following guidelines:
>
>     If you are going to discuss a large spec for the first time in the
>     week, dedicate a 40 minute session to that initial discussion on
>     Wednesday.
>
>     If you are going to discuss something that is controversial for the
>     first time in the week, bring that up in a 40 minute summary session
>     on Wednesday.
>
> This might lead to what, 5 or 6 40 minute sessions on Wednesday at the
> worst? The rest can just be project team work time. However, it gives
> people like me, who want to make sure we're paying attention to the
> right stuff in many projects a chance to introduce ourselves, raise a
> hand and ask a few questions, and insert ourselves in the agenda so we
> can be pinged and hopefully participate where it makes sense.

How can we know that things are controversial before we went to that 
conversation and saw we were in disagreement ?

I remember some topics we discussed that were looking very easy to 
discuss but somehow turned into a long conversation because of some 
detail that was raised during the conversation and requires more than 
just a single agreement.

> Whatever we do, please consider dismantling the silos, rather than
> reinforcing them.

That looks like a truism to me.

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




More information about the OpenStack-dev mailing list