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:
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-requ...@lists.openstack.org?subject:unsubscribe

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

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

    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-requ...@lists.openstack.org?subject:unsubscribe

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

Reply via email to