On Wed, Apr 15, 2020 at 9:30 PM Wesley Hayutin <whayutin@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.

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),

On Thu, 2020-04-16 at 17:14 -0400, Emilien Macchi wrote: 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. 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.