[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