Open Stack

On Thu, 2020-04-16 at 17:14 -0400, Emilien Macchi wrote:
> On Wed, Apr 15, 2020 at 9:30 PM Wesley Hayutin <whayutin at redhat.com> wrote:
> 
> > Looking to see if there are strong preferences for our time slots for the
> > PTG.  I would suggest we try to shoot for 13-17 UTC slot [1] as much as
> > possible.  Any strong preference in not utilizing that time slot
> > 
> 
> One suggestion. I think we could have 2 kinds of time slots. One that is
> APAC / EMEA friendly and another which is NA / EMEA friendly.
> If we do well with Etherpad / IRC / emails, we can certainly deal with
> missing folks in some sessions and eventually do smaller sessions but more
> distributed time-wise.
that makes NA/APAC comunication harder as they have to do it via the emea folk
relaying the conversation. also physical locality is not necessarily an indicator
of when people work. i also think that for smaller project the proably dont have contibutors
form all geos so looking at the activty of there contibutors and when they are most active might
be the best approch. e.g. if the contorobutors to project X are pripmarly apac and na based 
neither the APAC / EMEA or NA / EMEA slot woudl be a good fit for that project.

> Example given: "Session about improving Upgrade CLI"
> - a first session on EMEA morning / APAC afternoon; notes taken in
> etherpad, sent to ML
> - a second session on EMEA afternoon / NA morning; notes taken in etherpad,
> summary of both sessions sent to ML; if consensus isn't reached; use ML or
> schedule a third session out of band eventually.
> 
> I would like to see this exercise as an opportunity to learn how we can
> make decisions in async; involving everyone interested in a topic, no
> matter the location/timezone.
while this is an admerial goal i think it defats the reason for having a ptg
session on a topic. when we want to have an asyc discsussion on a topic gerrit is by
far the best solution we have, the ptg seession historically have be a time
to synchronise everyone understanding of a problem (which is usally socalised before the ptg),
the options to adress it, usecase to support and take a litmus test of where the general consensus is.
the final decision is then genreally taken after the ptg during a spec review where everone has
the opportunity to give a consise input asynchronously. we leaverage the limited time we have synconosly
without other distractions such as work email to brainstorm ideas and quicly evaluate solution with multile
stakeholder with a singel shared context.  ML are very difficult to have the same type of convertion on
as the thread diverge if there are more then 1 or 2 people invloved and gerrit can be slow unless the general
direction is already agreeed and also has a visablity problem. unless you activly look for something in gerrit its
easy to miss it but if its a session topic and you are present then you will lean about it even if you did not know
about it before the session.

> 
> So what I propose is that each session leader makes sure that the sessions
> can cover an overlapped time (hard to define though) or think about the
> "multiple smaller sessions" idea.
> 
> What do you think?

it would not be my peference but on the other hand if this works form most people in general then i wont object to it.