►
From YouTube: AsyncAPI SIG meeting 1 (Feb 5, 2019)
Description
This is the recording for the AsyncAPI Special Interest Group (SIG) meeting #1.
Attendees:
- Fran Méndez
- Jonathan Schabowsky
- Mike Ralphson
- Raisel Melian
Moderation:
- Fran Méndez
- Jonathan Schabowsky
Agenda:
* Hey! We have an agenda! (10 minutes)
- New SIG meetings.
- New Youtube channel: https://www.youtube.com/channel/UCIz9zGwDLbrYQcDKVXdOstQ
- New cadence, now meetings are every 2 weeks.
* Communicating publicly (15 minutes)
- Strategies for the #coreteam channel.
- How to organize the conversations in Slack.
* Core team communication and processes (15 minutes)
- Let’s do as much async and written communication as possible.
- Github issues triaging.
- Defining the roadmap and the vision.
* Questions and feedback? (15 minutes)
A
A
Yes,
so
I
was
thinking
I'm
having
a
new
Katherine's
for
the
for
the
meeting.
Instead,
because
you
know
it's
the
beginnings
and
it's
it's
difficult
to
have
many
things
to
say
every
week,
all
fast,
so
we're
gonna
put
it
every
every
two
weeks
and
I
think
my
proposal
for
that
meeting
is
that
we
use
it
as
a
way
to
to
help
others
as
well
to
understand
how
to
contribute
in
KPI
and
and
to
be
more
transparent
instead
of
using
it
as
a
way
to
coordinate
work.
A
So
because
we
are
very
distributed
team
we
should
then
we
should
instead
use
slack
and
other
facing
tools
for
collaboration
right
so
yeah.
Let's
do
it
every
two
weeks
now
and
regarding
the
the
the
communication
I
was
I
was
thinking
on
making
everything
completely
public.
You
know
that
we
have
a
core
team
channel
private
and
only
by
invitation
right
now,
which
made
sense
at
the
beginning,
because
everything
was
going.
A
A
A
I'm
gonna,
I'm
gonna,
give
you
a
my
opinion
first,
because
I've
been
thinking
about
it,
I
think.
Just
for
the
record.
We
should
make
it
public
just
to
keep
the
records
there.
So
we
don't
because
I've
been
removing
the
channel
and
that's
no
sensitive
information
or
anything
secret.
We
cannot
share
so
it's
it's
fine.
C
C
A
Thing
that
I
was
thinking
is
if
we
should
be
creating
more
channels
to
split
the
communication,
but
it
doesn't
make
sense
right
now,
because
we
don't
have
lots
of
people
talking
in
the
general
channel
right
now.
People
speak
they're
like
people
right,
therefore,
from
time
to
time,
it's
not
the
case
or
anything
right.
The
moment
it
becomes
okay,
you're
sort
of
starting
to
become
okay,
as
we
might
have
to
then
take
the
decision
to
display
the
conversation
in
different
channels
and
just
use
general
for
for
general
things
right
so
yeah
anything
anything
else.
Rochelle
yeah.
D
A
No,
no
agree
cool,
so
you
nothing
you
as
a
new
as
a
new
user
in
the
in
the
core
team,
where
you
feel
in
that,
like
like
I,
think
ABI
was
a
death
channel
or
something
like
nobody
was.
Nobody
was
actually
speaking
there
because
I
know
you've
been
in
the
channel
in
slack.
For
some
time,
I
was
poking.
You
yeah.
B
You
know,
I
think
it
kind
of
was
more
of
a
Q&A
channel,
which
that
meant
that
you
know
largely
there's
an
external
entity,
that's
kind
of
asking
a
question
or
forcing
something
which
probably
wouldn't
happen
as
frequently
as
just
internal
sort
of
communication.
Plus
you
know,
having
having
conversations
split
I
mean.
Obviously
we
can
have
a
sidebar
conversation
with
direct
messaging.
B
If
there's
something
I
don't
want
to
go
to
everybody,
but
in
a
lot
of
case
is
I,
think
sort
of
having
decision-making
being
in
a
centralized
channel
where
people
can
understand
sort
of
the
history
behind
some
of
the
decisions.
I
think
is
also
very
valuable
thing,
so
yeah
I
would
be
all
for
making
and
I
and
I
haven't,
have
gone
back
and
reviewed.
What
all
you
guys
have
talked
about
in
the
core
team,
but
if
you
guys
are
saying,
there's
nothing
sort
of
private,
then
I
would
be,
for
you
know,
making
that
public
anyway,.
A
A
But
this
doesn't
work
because
sometimes
people
from
from
different
time
zones
and
not
just
time
zones,
people
have
other
meetings
and
then-
and
they
can
not
just
they
can
just
get
into
this
meeting,
always
right
every
week,
so
so
yeah
so
I
was
thinking
as
you
suggested.
The
other
day,
Mike
I
was
thinking
on
the
on
the
sort
of
tools
that
do
you
want
to
use,
or
do
you
think
we
should
use,
because
I
I've
been
using
Trello
as
a
way
to
keep
us
all
up
to
date.
A
But
it's
true
that
having
things
in
Trello
and
having
things
in
github
makes
it
a
little
bit
difficult
to
understand
why
things
are
in
github
and
why
things
are
not
in
trouble.
It's
not
just
difficult.
When
is
cyst
if
they
are,
and
we
are
not
in
sync
right
and
this
is
a
pain,
this
is
dublicate
work
and
there's
no
reason
to
have
again
some
private
place
where
this
works
will
happen.
So
I've
been
spending
some
time.
The
last
day
is
trying
to
organize
all
the
work,
mostly
all
the
work
on
the
on
the
e-type
repo.
A
So
it's
everything
is
public
and
we
can
discuss
there
like
if
it,
where
a
fellow
cars
or
something
right
and
and
also
obviously,
we
have
slack
to
to
discuss
things.
But
I
was
wondering
if
there's
something
that
you
have
been
using
in
the
past
other
things
like
aside
from
slack
or
github
other
communication
tools,
but
do
you
think
there
can
be
valuable
I
think
that
they
both
are
fine
for
for
coordinating
that'll
is
in
the
beginning.
B
C
C
Api
project
is
using
github
issues
for
agendas
for
each
weekly
meeting,
or
in
this
case
it
would
be
bi-weekly
meetings
and
we're
using
the
pinned
issues
to
keep
a
track
of
the
last
meeting
and
the
next
meeting.
So
people
can
see
the
previous
agenda
and
the
next
agenda
and
maybe
pin
another
issue
with
all
the
communication
tools
like
misting.
The
slack
invite
link
on
the
pinned
issue
might
be
worthwhile,
so
people
can
always
find
the
information
about
the
calendar
and
slack
invitation,
etc,
etc.
A
And
it
makes
I
was
the
other
day
I
was
yesterday.
I
was
having
troubles
just
with
because
he
cooled
and
see
that
the
header
of
the
document
and
with
all
the
liens
and
I,
don't
know
why
it
was
I
just
had
to
remove
things
from
the
Heather
and
put
it
in
the
body
of
the
document.
Looking
like
a
header,
but
it's
not
and-
and
it
was
weird
and
then
sharing
these
things
like,
for
instance,
you
want
to
edit
the
list
of
participants,
so
he
just
requested
access
right
now
and
it's
true.
A
You
have
to
be
always
like
crap,
it's
true.
How
do
I,
edit
this
thing
and
how
do
I
give
permissions
to
people
forget
yeah
everything
all
of
this
is
solved
with
with
it
half
right,
like
everybody
knows
how
to
do
it.
So
obviously
it's
a
little
bit
more
complicated
because
you
have
to
commit
and
or
for
just
it
just
to
have
a
paragraph
probably,
but
it
has
pros
and
cons.
Probably
we
could
use
I,
don't
know.
A
Probably
we
could
use
Google
Docs
just
for
the
current
meeting,
and
then
we
leave
a
record
of
the
past
meetings
after
the
meeting.
I
will
put
it
on
the
under
repo
as
an
issue
right
or
or
yeah.
Well,
that
doesn't
make
sense.
Please,
because
yeah
it
will
be
just
for
for
record
purposes,
but
but
the
cool
thing
about
github
is
just
to
put
it
there
principle,
so
people
can
join
to
the
next
one,
not
just
to
be
the
old
ones
right:
okay,
okay,
I'll,
give
it
a
try.
I
think
we
can.
A
A
A
This
is
this
is
gonna,
be
a
little
bit
a
word
because
we're
gonna
be
working
on
version
1.3
and
we're
not
going
to
create
any
tooling
for
that
version,
because
we'll
be
working
on
for
version
2
and
it
was
like,
let's
just
skip
version
1.3
and
let's
go
you
know
directly
to
rush
into
so
we
can
just
go
faster
and
don't
spend
time
in
making
people
think
that
yeah
person
1.3.
It
was
something
at
some
point
when
it
really
was
nothing
right,
so
and
and
and
also
for
all
Affairs.
A
Let's
not
just
let's
not
spend
time,
updating
the
tooling
or
creating
tooling
for
a
version.
That's
gonna
leave
for
two
months,
I'd
say
so
yeah.
So
this
was
a
discussant
and
like
two
weeks
ago,
or
so
that
we
discuss
here
not
to
create
more
tooling
for
the
current
version,
but
instead
to
focus
on
the
new
version
of
the
of
the
spec
and
then
we'll
create
totem
for
a
person
too,
because
really
the
light
that
the
life
for
version,
one
is
very
short
from
now
on,
scrubbing
for
shorter,
so
it
doesn't
deserve
the
effort.
A
So
I'm
going
to
go
to
the
to
the
milestones,
I
managed
to
group
all
the
issues
in
more
or
less
manageable
amount.
Adhesives.
We
have
there
something
called
improving
connectivity.
This
is
just
a
cool
thing
for
all
the
issues
related
to
the
server's
side
of
the
server
section
of
the
spec.
So
it's
just
to
improve
how
we
connect
to
the
servers
right
or
to
fix
things
that
are
broken
there.
A
We
have
the
normalized
topics
and
support
multiple
schemas.
This
is
the
major
thing
for
the
for
version
2.
So
this
is
in
case
in
case
you
didn't
you
don't
know
what
I
was
thinking
here
is
topics
we
can
make
topics,
look
like
URLs,
not
just
look
like
they
are
URLs.
Okay
and
I'll
explain
why
afterwards
and
then
we
with
this,
do
we
have
the
two
advantages
or
even
more
one
of
them?
Is
we
align
with?
Oh,
yes
with
open
API
specification,
so
all
topics
and
hats
will
look
the
same.
A
We
have
because
of
this.
We
have
because
it's
a
URL
for
Toulon.
It's
gonna
be
easier
to
parse
these
paths,
because
there
are
plenty
of
URL
parcels
out
there
right
so
for
tuning.
It's
gonna
be
easier
to
parse
this
and
then
an
exotic
format
that
we
might
invent,
and
also
because
of
the
nature
of
the
of
the
paths
we
can
then
get
rid
of
the
events
section.
The
facing
API.
The
events
section
is,
as
you
know,
is
the
communication
between
two
points
where
there
are
no
channels
or
topics
it's
just
like
WebSockets.
A
You
connect
to
a
server
and
exchange
exchange
messages
right,
so
we
can
get
rid
of
it
because
if
we
think
about
it,
we
can
make
it
mandatory
that
this
last
the
route,
the
route
path,
is
a
global
channel.
If
you
want
it's
like
no
Channel
right,
there's
no
channel
or
is
it
a
global
one?
So
we
can
make
this
last
as
a
global
channel,
we'll
move
the
the
events
section
and
we
can
make.
A
We
can
even
make
mandatory
to
every
path
to
start
in
this
last,
for
instance,
and
there
it's
just
a
matter
just
like
this
MQTT
or
MEAP,
and
everything
is
gonna,
be
easier,
because
if
someone
already
created
a
parser
for
the
open
API
specification
with
the
parameters
and
all
of
that
we
can
take
advantage
of
this.
You
know
this
is
one
thing
and
the
other
one
is
about
the
the
the
the
multiple
schemas.
A
Many
many
people
are
asking
for
support
for
more
than
just
a
schema
like
proto
path,
forever,
right
and
and
the
reason
I
I
put
it
there
like
almost
immediately
one
of
the
first
things
to
do
to
make
is
because
these
are
the
most
breaking
changes
that
we
have
in
the
list
and
I
would
like
this
breaking
changes
to
happen
as
soon
as
possible
because
they
can
potentially
affect
the
rest
of
the
things.
So
we
don't
want
to
work
in
the
center.
Try
them
there
yeah
true.
A
A
C
It's
it's
got
some
good
supposed
to
feedback.
I've
also
done
a
proof
of
concept
implementation
in
in
nodejs,
and
it's
it's
about
ninety
to
a
hundred
lines
of
code.
So
it's
not
it's
not
massively
heavyweight
I,
can't
remember
why
it's
not
progressed
to
a
pull
request,
yet
I
think
it
made
you
for
your
question
of
time
on
Darryl's
part,
but
I,
don't
think
anybody's
got
any
major
objections
to
it
and
I
think
there's
a
fair
chance.
A
Yeah
again,
this
this
is
gonna
be
a
way
also
to
keep
aligning
both
spans
as
we
evolved
right.
Listen
to
me
of
things
and
and
also
then
there's
the
last
milestone,
which
is
protocol
mappings,
and
this
is
mostly
a
group
of
issues
related
to
how
do
we
make
it
easier
for
people
and
for
us
as
well.
The
map,
async
API
messages
and
our
information
I'll
say
two
specific
protocols
like
what's
the
mapping
for
aim
QP?
What's
the
mapping
for
nqt
how
how
this
mapping.
A
For
instance
like
having
correlation
ID,
so
how
do
we
do
the
whole
thing
right?
How
do
we
map
this
to
a
name,
QP
header
we
put
this
in
the
payload
or
in
the
header
we
have
headers
are
all
things
like
that
and
yeah.
So
one
thing
that
I
wanted
to
mention
about
the
milestones
is
that
I
put
some
deadlines
there,
and
most
of
them
are
very
aggressive
dog
whines
just
to
keep
an
idea.
A
What
do
we
want
to
do
or
as
to
not
lose
track
of
things
of
how
things
will
be
nice
to
evolve
right?
I,
understand
that
just
me
right
now
is
the
only
one
working
on
the
tender,
my
tire
of
the
time,
I'm
happy
to
solve
90%
of
these
issues,
I'm
not
asking
you
to
work
on
that
right,
you're,
not
getting
paid
for
that
at
least
yet
yeah.
So
just
wanted
to
mention
that
this.
This
is
something
just
to
have
as
a
reference.
Okay,
so
I
hope
nobody
feels
pressure.
D
D
A
A
We
left
we
left
many
time
behind
this.
We've
been
waiting
so
much
for
version
2.
Now
that
it
has
grown
a
lot
and
that's
why
I
had
to
split
it.
So
so
we
cool,
so
we
could
tackle
it
in
a
handy
way
right
and
but
my
idea
was
to
finish.
The
this
milestones
will
launch
async
API
version
to
the
spec
I
will
say,
or
we
put
it
as
a
release
candidate
and
in
the
meantime,
like
before
we
finished
the
last
two
milestones.
We
start
developing
the
the
new
tooling.
A
Ok,
so,
and
we
will
also
be
have
to
be
developing
the
new
roadmap
and
I
think
that
the
next
step
for
the
roadmap
after
we
launch
this-
it's
just
to
be
very
aggressive
on
tooling,
like
this-
is
just
the
base
work
versus
a
sink
API
version.
2
is
it's
just
like
the
contract?
It's
fine,
it's
cool,
but
it
would
be
nothing
if
we
don't
have
tooling,
as
you
said,
so,
we
have
to
go
there.
We
have
to
go
for
tooling
for
sure,
not
sure
if
we
should
do
it.
A
Let's
call
it
production
ready
if
you
want
so
so.
Yeah
but
I
I
agree
I'm
I'm,
happy
to
cook
here
to
get
insights
from
you
guys
on
how
we
should
proceed
with
that
like
so,
we
start
with
with
pooling
from
day
zero
if
you
want,
or
from
day
one
or
two
with
the
so
of
this
new
any
new
version,
or
so
we
wait
a
little
bit
more
or
shall
we
wait
until
the
end
after
that,
until
we
finish
that
version
two?
A
A
E
A
A
Don't
know
how
much
time
will
we
we
will
spin
spin
they're
implementing
that
and
I
was
putting
things
like
very
formal,
but
two
inventors
are
almost
hundred
percent
as
well.
At
least
now.
I
know
that
you
know,
probably
now,
with
mules
with
mules,
often
and
Soyuz,
and
working
with
it,
we'll
probably
more
be
more
or
more
tooling
and
and
teal,
because
well
is
developing
some
tooling,
sir,
but
yeah
the
thing.
The
thing
is
that
but
I,
that
was
my
idea,
but
I
think
disappoint
on
what
Reza
was
saying.
A
Instead
of
waiting
until
the
end
like
like
like
corporation
Speaker
present,
do
right
like
they
have
projects
and
dependencies,
we
can
make
it
a
little
bit
more
agile.
If
you
want
like
this
is
a
fancy
word
and,
and
we
can
start
working
at
same
time
and
in
in
something
at
least
so
we
don't
so
we
don't
lose
so
much
time
on
because
via
in
the
end,
the
spec
is
nice
and
I
love
working
on
the
spec.
A
Now
I
really
love
it,
but
what
really
provides
value
most
of
the
times
is
is
the
tooling
right
either
the
two
men
you
build,
or
building
people
build,
and
and
and
that's
another
discussion
that
we
will
have
to-
we
will
need
to
have
in
the
future.
But
it's
also
what
kind
of
tooling
we're
gonna
develop.
B
Right
so
I
mean
to
me,
there's
like
different
aspects
of
tooling
and
I.
Guess:
I'm
kind
of
curious
from
your
guys's
perspective.
I
know
you
guys
kind
of
doctrine
seems
to
be
a
core
thing
and
in
cochin
to
some
degree,
though
it's
you
know
kind
of
in
its
infancy,
as
we
would
expect,
but
then
I
mean,
as
as
we
start
to
incorporate
into
our
products
right
like
I.
Don't
think
we
would
take
something
until
final,
but
I
think
the
cogeneration
stuff
should
start
off
as
kind
of
release
candidates.
A
Think
about
tooling
many
times
we
think
about
products
instead
of
a
wet
like,
for
instance,
induction
or
collagen.
They
could
be
products
themselves
like
they
have
an
activity
for
the
end-user
right
like
you
can
just
pass
a
nice
incubate
document
and
you
get
that
results
from
it
for
the
end
user,
but
I
was
thinking
more
on.
A
But
if
you
want
people
to
actually
be
able
to
really
fast
update
their
products,
you
have
to
provide
them
low-level
layers
right,
like
the
parser
to
have
a
parser
for
Java,
a
part
surfer
girl,
parser
for
Python.
You
know
all
these
things,
so
they
can
use
it
immediately
in
their
products
and
and
then
a
little
bit
more
of
work
like
mappings
how
to
map
to
to
protocols.
So
they
can
just
with
much
less
effort.
They
can
just
start
saying:
hey.
A
We
provide
a
sync
API
to
support
or
three
support
on,
for
you
know
and
they're,
not
stuck
with
the
with
the
old
with
the
old
version,
because
there's
nothing
out
there
that
help
them
progress
on
implement
in
the
new
right,
I'm
thinking,
for
instance,
as
you
didn't
say,
for
instance,
that
imagine
that
we
have
a
music
I,
don't
know
what
really
their
plans
hair,
but
million
that
do.
We
have
an
API
management
solution
having
dungeons
and
koji
ins.
A
D
E
B
A
Yeah,
secondly,
there
is
like,
for
instance,
in
your
case.
It's
also
like
a
like
product
itself
like
having
a
linter.
Is
it's
also?
It's
already
a
product,
I
will
say,
but
it's
a
product
that
many
people
will
use
in
the
sense
that
they
can
have
it
as
a
C
in
there
CI
ACD
pipelines
to
validate
their
documents
whenever
they
change
it
ever.
A
B
So
I
mean
yeah,
so
probably
so
it
was
yeah,
so
it
was
back
last
spring
we
launched,
you
know
as
part
of
our.
You
know:
I
work
in
the
CEOs
office,
basically
an
investigation
into
kind
of
what
we
were
acquainting
and
turny
internally.
How
do
you
make
a
venting
look
like
rest
right,
and
so
that's
how
we
found
you
guys
in
the
first
place
and
and
I
tried
to
use
the
Java
code
generator
because
I'm,
a
Java
guy
and
I
don't
know
again.
B
A
B
That
would
be
an
example
of
something
you
know.
Obviously
we
need
to
clean
it
up,
but
like
something
we
would
like
to
contribute
back
to
the
community
and
kind
of
do
that
through
our
different
customer
bases,
as
they
need.
Generators
like
the
FAA
makes
very
wide
use
of
JMS,
so
like
a
JMS
generator
on
a
sync
API
would
be
very
useful
for
it
and
all
the
airlines
that
have
to
consume.
You
know
FAA
data,
but
you
know
FAA
data
is
generally
XML.
B
So
that's
why
I
was
making
the
point
in
the
mule
soft
meeting
of
supporting
XML,
which
you
guys
have
already
thought
of.
So
that's
a
very
long-winded
to
say
is
like
I
definitely
view
the
whole
kind
of
code.
Generator
thing
is
a
very
key
aspect
of
how
you
make
a
venting
just
as
easy
as
developers
kind
of
knew
rest
as
very
easy
to
use
either
to
generate
the
API
or
the
client
yeah
yeah.
B
Yep,
no
and
that's
something
we
definitely
I
think
will
want
to
do.
I
mean
we're
in
the
process
right
now:
I've,
actually
I'm,
adding
a
person
to
the
team
that
just
focuses
on
async
API
and
that
community.
So
you
know
we
would
be
bringing
that
person
to
bear
into
your
point
right,
like
I,
think
he
would
be
sort
of
a
dummy.
Tester
he'd
help
make
the
community
well
known
along
with,
hopefully
developing,
as
our
customers
need
additional
tooling
like
we
can.
We
can
help
that
I.
B
Think
I
think
we
want
to
understand
sort
of
the
framework
which
you
guys
have
in
place
to
help
build
that
and
such
that,
like,
as
you
guys,
go
through
different
versions
of
a
spec
like.
Ideally,
it's
not
completely
breaking
everything.
Every
release,
I
mean
obviously
some
changes
right
always
happen,
but
like
not
like,
oh
god,
we
just
spent
four
weeks
building
a
generator
and
like
up
throw
that
one
away
like
time
to
go,
spend
four
more
weeks
on
a
new
one.
B
B
One
other
thing,
I'll
just
add
and
then
I'll
get
off
my
soapbox,
so
you
guys
mentioned
sort
of
the
transformation
of
protocols.
I
don't
know,
maybe
you
guys
are
already
like
completely
like
protocol
experts,
but
like
our
product
already
Matt,
you
know
on
our
broker
back
in
you
know,
Maps
between
JMS,
a
and
QP
mqtt
and
Andres
and
I
believe
on
our
website.
B
A
That
I'm
sure
that
helps
yeah
and
I.
We
can
keep
speaking
about
the
you
know.
The
protocol
mappings
I
mean
in
the
next
meetings
and
how
we're
gonna
outline
this,
because
really
it's
a
huge
effort,
because
we
have
to
start
thinking
about
the
range
of
protocols
we
want
to
give
support,
at
least
initially
in
I
mean
in
the
tooling,
and
also
the
range
of
languages
like
this.
This
is
just
not
Java
and
OGS
right.
So
there
are
other
languages.
A
It's
a
little
bit
high
so
and
with
our
resources.
So
far,
it's
gonna
be
extremely
hard
to
follow
right,
so
so
yeah
we
probably
have
to
discuss
in
the
next
meetings.
If,
if
we
have
to
what
languages
we
want
to
support
for
the
tooling
and
what
protocols
right,
if
nothing,
the
next
one
one
of
the
following
one's
right
but
yeah,
so
I
just
wanted
to
check
a
check
out
with
you
guys.
How
do
you
think
we're
doing
now
within
this
new
way
of
organizing?
A
How
are
you
feeling
now
I
know?
It's
been
like?
Ok
is
especially
the
last
three
or
four
months.
Sorry
from
from
my
side
has
been
like,
you
know,
I'm
going
crazy,
trying
to
put
it
as
a
serious
project
now
and
I
didn't
have
so
much
time,
but
I
hope
you
guys
are
having
much
better
experience
now
and-
and
this
is
a
project
that
we
all
that
we
all
do,
we
all
contribute.
Sir
I
told
my
cell
yesterday.
A
This
is
this:
is
that
async
API
team
right,
everybody
can
join
in
everybody
can
contribute
as
well.
So
we
welcome
everybody
and
let's
just
talk
about
s
and
not
just
friends
right
so
so
yeah
I,
hope,
you're
you're
doing
this
new
way
and
if
you
have
a
suggestion
on
how
to
improve
it,
just
let
let
me
know
okay
and
we
can.
We
can
keep
improving.
This
sounds
good.
A
D
A
A
very
long
weekend
for
me
time
to
organize.
Finally
like
okay:
let's
do
it
on
the
weekend
because
they're
in
new
in
the
the
work
days,
it
was
impossible,
so
so
yeah
cause
I
have
to
go
skip
to
the
next
meeting
now
and
okay,
thanks
for
joining
again,
let's
keep
in
touch
via
slack,
and
you
know,
async,
communication
and
yeah.