►
From YouTube: GraphQL Over HTTP - August 25, 2020
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
A
A
A
A
Okay,
so
yeah,
we
don't
have
a
lot
of
people
here
today.
A
But
maybe
let's
go
around
and
introduce
attendees
first,
so
I
can
start
sam
parsons.
I
work
at
paypal
based
in
the
us
iowa.
C
D
All
right,
I'm
morris,
or
can
I
be
on
in
the
us
in
boston-
it's
not
my
birthday
but
happy
birthday
to
dennis.
Thank
you.
B
A
B
By
the
way,
probably
we
need
to
edit
it
in
redmi,
but
foundation
started
finally
to
publish
videos,
so
they
on
youtube
and
actually
a
video
from
what's
working
group
is
on
youtube.
So
notes
is
important,
but
finally,
we
have
like
no
notes
is
more
important
because
it's
distilled
version
but
full
videos
are
available
on
youtube.
B
B
A
Cool,
so
just
want
to
check
on
reviewing
the
agenda,
see
if
we've
got
everything
in
here
we
want
to
discuss,
I
mean,
did
you
have
something
else?
You
were
going
to
add
to
the
end
here
or
do
you
want
to
do
it
earlier.
B
C
A
B
A
A
A
So,
let's
continue
so
I
had
we've
changed
how
we
were
like
tracking
like
tasks
and
actions,
and
we
just
wanted
them
around
issues
within
github,
and
so
I've
organized
also
milestones
corresponding
with
our
next
meeting.
So
if
we
want
to
aim
to
do
an
action
by
the
next
meeting,
we
just
add
it
to
a
milestone
for
like
september,
for
example,
so
for
july,
we'll
close
this.
These
are
the
things
that
we
got
done.
We
migrated
to
the
graphql
foundation,
hooray.
That
was
good.
A
Thank
you
ivan
for
your
help
on
that,
and
thank
you
also
to
brian
as
well
for
his
confirmation
on
the
details.
We
needed
to
do
that.
A
So
that's
great
and
the
other
thing
that
we
got
done
was
finding
the
best
time
for
meeting
that
we
closed
that,
because
we
weren't
able
to
find
a
good
time
for
july,
but
carried
that
one
forward
and
august.
A
So
there's
a
couple
things
that
we
left
open
from
august.
I
know
that
I
think
this
adopts
spec
md
may
be
done
mostly,
but.
D
I
actually
stuck
that
later
on
the
agenda,
which
I
thought
would
be
very
quick.
I
just
wanted
to
know
like
yvonne.
If
you
tell
me
what
needs
to
be
done
yeah,
I
didn't
know
if
people
are
ready
to
put
the
generated
result,
also
somewhere
up
as
a
as
a
spec
or
if
you
don't
want
it
to
be
that
visible.
Yet,
if
we
are
ready,
then
I
thought,
maybe
you
could
tell
me
how
to
do
it.
B
No,
no,
no,
it's
actually
one
thing
with
github
actions:
it's
like
hard
to
debug,
if
you
don't
have
commit
access
and
basically
it's
like
it's
like
you're
doing
something.
You're
testing
is
the
only
way
to
test
it.
It's
actually
like
measured.
So
if
somebody
like
doing
that
without
commit
access,
it's
like
taking
a
lot
of
time.
B
We
can.
We
can
like
figure
out.
So
basically
I
was
trying
to
sound,
because
I
have
a
surgery
and
I'm
like
right
now
recovering
so
I
finally
get
back
to
open
source.
So
I
will
be
more
responsive
to
issues
and
stuff,
so
I
think
we
can
discuss
it
inside
an
issue
but
basic
idea.
We
need
to
copy
how
it's
done
for
graphql
specification,
but
using
hit
connections,
because
graphql
specification
use,
travis
and
obviously
right
now,
it's
better
to
if
we
add
something
new,
it's
better
to
use.
Github
action
from.
B
D
B
A
I
wonder
whether
we
should
advise
people
not
to
adhere
to
the
spec.
You
know
not
to
spend
time
to
get
compliant
with
the
spec,
whilst
we
still
may
be
changing
it
under
them,
some
sort
of
language
that
would
just
indicate,
let's
you
know,
everything's,
subject
to
change.
So
if
you,
if
you
want
to
do
work
based
on
it
cool,
but
it's
subject
to
change,
I
think
that
let's
just
make
sure
that
we've
got
verbiage
like
that
in
there.
A
B
D
Yep
all
right,
I
can
try
to
add
something
quick
like
that.
Get
you
back
is
there.
I
know
you
said
you
talked
about
images.
Are
there
you.
B
Do
you
actually
want
like
a
warning?
No,
I
think
we
can
add
the
mojo
if,
if
there
is
like
warning,
if
it's
rendered
normally
inside
the
html
by
spec,
md
yeah,
okay,
so
we
can
just
see
if
second,
he
has
something
like
that.
So
you
know
and
because
the
mods
attract
your
eyes,
attract
your
attention.
So
it's
yeah.
D
B
Yeah,
you
can
try
it
under
a
fork,
so
we
can
synchronize
inside
the
issue.
I
think
it
would
be
more
efficient
than
to
discuss
it
yeah.
B
D
B
A
Cool,
I
also
just
moved
that
to
the
september
milestone
so
that
actually
moves
out
of
this
milestone.
This
one
needs
to
move
there.
I
don't
think
these
other
ones
that
we
have
help
wanted
for
have
got
any
help,
so
those
are
just
kind
of
aware
that
they're
open,
I
think,
there's
things
that
we
could
progress.
D
A
D
I
think
that
I
think
it's
the
bottom
one
that
I
said
I
could
work
on
and
I
put
it
on
the
agenda.
I
meant
to
have
something
to
show
people
before
the
meeting,
but
I've
been
busy
on
other
things
and
I
didn't
get
to
it,
but
I
do
have
on
the
agenda
just
to
ask
a
few
questions
going
into
this.
One.
A
A
B
Yeah,
so
basically,
I
think,
like
name
can
be
name
is
like
not
as
straightforward
as
rfc
is
itself
because,
like
as
community,
we
discuss
stream
and
defer
for
like
years
lee
like
three
years
ago.
He
showed
in
his
talk
as
one
of
the
experimental
features
that
facebook
working
on,
but
for
years
it
was
just
like
experimental
feature
inside
facebook
that
nobody,
like
kapoor,
had
some
experiment,
but
basically
it
was
abundant.
B
Everybody
discussed
it.
People
had
it
in
their
head,
but
no
way
they
actually
implemented
until
away
at
the
support
for
it
and
some
initiative
group
from
company.
I
forget
name
for
companies,
actually
implemented,
rob
in
lillian.
They
spend
like
time
and
they
create
not
only
like
spec
proposal,
but
they
created.
B
B
B
Basically,
it's
used
multi-part
http
multipart
for
for
deliver
a
multi-part
response.
Jaden
have
some
question
about
how
it's
interact
with
his
multi-part
for
fibo
ports
and
basically
it's
like
totally
separate
because
the
multi-part
file
port
is
for
requests,
and
this
thing
is
for
response,
so
it
doesn't
interact
with
it
in
any
way,
shape
or
form.
So
nobody
opposed
for
it
and,
like.
B
A
So,
as
far
as
like,
this
is
maybe
kind
of
a
point
of
order,
but
we've
got
if
we
add
an
rfc
here
for
incremental
delivery.
A
B
A
Request
for
commons
yeah,
so
I
mean
like
in
that
sense
like
we
need
to
leave
this
open
just
for
comments,
so
it's
not
actually
like
merging
into
the
specs.
So
I
feel
like
it's
it's
much
more
lower
risk.
This
is
just
the
beginning
of
a
process,
so
it
makes
sense
to
me.
B
We
have
a
discussion
for
graphql
spec
repo
also
have
rfc
folder,
and
we
had
exactly
the
same
discussion
and
idea
was
that
we
want
too
much
stuff.
That
makes
sense.
We
had
enough
time
to
discuss
it
and,
like
community
is
generally
interested
in
that,
so
it's
basically
to
protect
against,
like
people
put
weird
stuff
inside.
B
A
B
B
Ideally
we'll
probably
need
to
maintain
an
issue
I
think
it's
just
like.
I
don't
want
to
book
change
so
what
booked
with
pr
so
imagine
it,
it
will
give
it
more
visibility
and
it's
increase
its
status.
It's
not
like
some
some
proposal
that
somebody
just
prepared
it's
like
it
was
review.
It
makes
sense.
It's
not
part
of
respect,
but
it's
you
like
documented
and
implemented,
especially
since
idea
is
implemented
in
express
graphql.
Express
graphical
is
reference
rocket
server.
So,
ideally,
we
wouldn't
implement
anything
that
is
not
documented
under
foundation.
D
Yeah,
I
I
mean,
I
think
that
all
sounds
good
like
rfc,
it's
not
actually
part
of
the
specs,
so
it
doesn't
need
to
have
had
so
much
discussion.
Yet
I
know
some
of
the
stuff
we've
been
saying
for
this
spec
for
http
is
stuff,
that's
not
implemented
in
any
in
any
code.
Today
at
all,
I
wonder
like
how
would
this
so,
I
think,
two
months
ago,
for
example,
we
talked
about
somebody's
talking
about.
Could
you
use
websockets
for
queries,
mutations
and
not
just
subscriptions?
D
So
if
you-
and
I
think
that
was
left
is
optional
two
months
ago.
So
if
you
used
website
what
websocket,
I
don't
know,
how
would
you
handle
websockets
with
different
queries
with
different
different
later
responses?
Maybe
it's
the
same
like
multiplexing,
it's
not
a
big
deal
anyway.
I
just
remember
like
there
might
be
more
to
think
about
for
this,
or
maybe
not
I
haven't
thought
about
it.
D
B
B
So
maybe
it's
not
covering
all
the
cases
like
web
sockets,
but
basic
functionality
for
http
and
inside
graphql
spec
is
more
or
less
production
ready,
at
least
for,
like
one
company,
and
I
think,
like
some
other
companies
using
railway,
also
implement
streaming
g4.
So
I
feel
like
yeah.
That's
why
it's
experimental
so
we're
not
sure
it's
covering
all
the
cases
and
no
situation,
but
it's
kind
of
production
already,
and
we
want
to
test
it
in
more
companies.
B
Yeah
and
actually
it
will
help
us
to
identify
real
issues
if
somebody
using
yeah,
I
suspect
somebody
actually
using
graphql
over
web
sockets
right
now
at
the
moment,
have
enquiring
mutation,
because
graphql
is
right.
Now
it's
like
widespread
and
people
do
some
kind
of
experiments,
so
by
promoting
streaming
before
this
person
will
come
back
with
a
question
how
I
should
implement
it
to
our
web
circuits.
So
actually,
like
questions
that
you
ask,
is
the
purpose
of
making
it's
experimental.
A
All
right,
so
we
have
a
it
seems
like
we're:
okay
like
merging
it.
That
kind
of
is
the
the
main
thing
that
we
need
to
decide
about
for
it
right
now
and
then
just
kind
of
open
pr's
with
or
issues.
I
guess
with
more
comments
I
mean,
did
you
want
to
open
an
issue
just
to
track
conversation
about
it?
You
kind
of
alluded
to
that.
B
B
Please
also
open
an
issue
because
I
think
a
person
it
should
be
started
by
a
person
who
actually
create
pr
and
have
necessary
contacts.
I
don't
I
kind
of
understand
this
pr
and
this
proposal,
but
I
don't
have
a
lot
of
context.
I
think
rob
is
the
right.
Robo
lillian
is
the
right
people
for
this
issue.
B
Maybe
we
can
a
little
bit
formalize
it,
because
it's
like
secondary
so
not
to
have
discussion.
You
know
like
wait
technically,
it
can
be
merged
by
anybody
who
have
like
much
permission,
but
at
the
same
time
we
are
groups.
So
we
need
like
some
kind
of
rules
for
doing
that.
So
I
I
propose
like
criteria
that
it
should
be
open.
B
It
should
be
discussing
working
group,
so,
like
person
present
his
rfc,
we
are
on
a
working
group.
We
discuss
it
and
and
also
it
should
be,
some
phase
of
like
grammar
check,
technical
checks
and
after
that
we
just
measured
so
criteria
is
to
like
review
process
like
any
other
rfc
and
also
person
presented
on
working
group
and
nobody
object
merging
it.
B
I
mean
like
people,
it's
not
like.
We
support
it,
but
it's
not
like
it's
not
it
feed
definition
of
what
we're
doing
so
like
if
somebody
propose
something
that
is
not
part
of
http,
for
example,
something
over
tcp
websocket
is
over
http
because
connection
is
established.
So
it's
kind
of
touching
this
topic,
but,
for
example,
pure
tcp,
is
outside
of
a
scope,
so.
A
A
D
Go
ahead
mars
so
like
in
this
case
it's
already
in
an
implementation.
I
think
you're
saying
that's
not
generally
required,
but
do
you
want
to
be
explicit
whether
or
not
that's
your
turn.
D
B
A
good
idea
because,
like
it
will
put
right
threshold
yeah,
I
think
it's
actually
yeah.
B
A
A
A
All
right,
so
is
that
good
for
this
topic,
this
agenda
item,
so
next
up
benedict,
asked
me
to
bring
up
his
pr
on
clarifications
that
used
to
be
status,
codes,
and
so,
after
the
last
meeting,
he's
kind
of
clean,
clean
this
up
and
reduced.
What's
what's
in
here,
yeah,
so
splitting
the
pr
keeping
minimal
agreed
upon
changes
and
so
he's
made
those
changes
ivan.
You
had
had
a
comment
here.
A
A
If
those
changes
were
addressed,
do
you
agree
ivan
or.
B
Yeah,
I
agree
except
like
with
this
point,
because
I
don't
think
we
need
to
duplicate
the
spec.
Spec
is
pretty
clear
on
what
why
data
have
a
certain
value,
so
spec
describe
why
it's
snow
and
why
it's
missing
and
I
think
like
we
should
either
remove
it
or
reference
the
sparkle
just
not
to
mention
it
here
or
so,
like
I
don't
like
duplication.
A
Inside
the
specs,
so
I
think
what
you're
saying
is
you
prefer
a
statement
along
the
lines
of
if
their
response
has
content
graphql
and
has
a
non
to
xx
status
code.
The
data
entry
must
be
either
null
or
not
present,
yeah
and
delete
this
little
chunk
here.
Is
that
right,
yeah?
Okay?
So
that's
really
simple.
Just
kind
of
reduce
some
like
these
parenthetical
explanations,
right,
yeah,.
B
C
B
Point
I
actually
wanted
to
add
in
this
pair.
I
would
change
it
to
non-normative
node
like
an
old,
not
because
it's
like
even
texas,
formulated
more
like
nodes
and
requirements.
I
think
it's
useful
to
have
clarification
on
some
stuff
like
because
responses
like
prescribing
graphql
spec.
B
I
think
like
having
non-normative
node
here
is
good,
especially
since
actually
support
nodes.
A
A
A
So
that's
that
okay
number,
nine
morse.
I
think.
B
A
A
D
Oh
yeah,
so
I
I
I
this
doesn't
have
to
be
much
discussion
for
now.
I
just
I
mean
kind
of
like
we
look
at
benedict's
pure
we've
gone
through
a
whole
lot,
where
there's
actually
lots
of
disagreement
on
the
where
we
should
be
going
with
the
what
kind
of
stuff
should
be
in
the
spec,
and
so
I'm
I
wonder
if
we
can
get
some.
I
don't
know,
there's
not
so
many
of
us
right
now,
but
get
some
agreement
like.
What
do
you
guys
want?
D
Is
they're
they're
different
like
to
be
more
so
this?
This
is
all
about
how
to
how
can
the
server
know
that
the
client's
in
graphql,
in
my
experience,
there's
there's
at
least
two
different
scenarios,
which
is
one
is
when
you
are
expecting
graphql
how
you
would
decide
if
it
is
or
not
and
the
other
is
when
you're
not
sure
what
you're
getting
whether
you
decide,
whether
it's
graphql
or
not?
D
D
Well,
I
I
guess
some
of
this
gets
into
the
general
question
of.
Is
it
you
want
to.
You
know
how
previous,
how,
how
strict,
how
strict
or
how
like
lenient
should
the
spec
be
I
mean
if
I,
if
I
know
if
I've
got
a
graphql
endpoint,
where
I
know
I'm
expecting
graphql
and
I
don't
know
any
client
might
be
contacting
my
server
and
different
clients
might
be
different
and
I
get
say
something
that
pretty
much
looks
like
graphql.
D
So
it's
got
application
that
I'm
getting
a
json
payload
in
and
it's
got
a
query
and
an
operation
name
and
and
variables,
but
it
also
has
three
other
things
you
know.
Should
I
assume
that
that
is?
It's
got
things
that
I
don't
recognize
at
all.
Should
I
assume
that
it
is
graphical
or
that
it's
not
graphql?
B
B
I
think
we
actually
agreed.
If
we
could,
we
go
in
the
way
of
register
like
claiming
my
my
type.
It's
like
most
of
my
types
used
both
ways,
so
you
can
send
them
and
you
can
receive
them
so
from
what
sense,
like
we
just
say,
stuff
that
mark
with
certain
mime
type,
should
follow
our
spike
stuff.
That
is
not
mark.
By
with
my
type,
we
don't.
D
Yeah
yeah,
no,
that
that
makes
it
much
easier
if
we
can
use
that
mime
type
yeah.
I
think
it's
the
same
mime
type,
even
though
you're
expecting
a
different
kind
of
data
in
the
request
and
response,
I
don't
I
don't
I
just
I
don't
actually
remember
like.
There
are
many
mind
types,
they're
used
request
and
response,
but
are
there
mic
types
that
are
used,
request
and
response
where
the
actual
data
would
look
different.
B
Yes,
so
actually
like
we
return
back
to,
I
don't
know
like
half
a
year
ago,
discussion
and
banjo
actually
benj
pioneer
was
topic
of
mime
type.
So
if
you
look
in
other
protocols
like
grpc
and
swap
they
use
my
type
for
a
question
response
and
format
for
question
response,
obviously
different.
So
like
mime
type,
we
have
like
prior
art
of
of
using
my
type
for
protocols.
D
Perfect,
perfect,
okay,
all
right.
In
that
case
I
mean
so
in
that
case
it's
very
simple.
If
you
see
like
you,
said
yvonne,
if
you
see
the
mime
type,
then
you
know
it's,
then
you
know
the
request
and
that's
about,
and
then
I
I
can
try
to
write
up
some.
I
assume
just
like
these
other
things.
We
don't
want
to
be
too
specific.
If
you
don't
see
the
mind
type,
leave
it
up
to
the
servers
right,
yeah.
B
But
since
we
discussed
it
with
lee
and
like
a
general
discussion,
working
group
was
to
try
to
instead
of
documenting
stuff,
try
to
make
specs
describing
how
stuff
should
be
done.
We
need
a
clean
breaking
way.
So
it's
it's
not
theoretical
issue.
It
it
becoming
a
practical
issue
that
existing
servers
need
to
serve
respect,
prospect
and
prospect
clients
in
a
sense
like
they
need
a
way
to
distinguish
like,
for
example,
if
we
extensions,
if
we
specify
that
you
cannot
put
additional
field
except
inside
extensions,
it's
make
like
a
lot
of
existing
stuff
in
invalid.
B
So
like
and
other
things
by
the
way
like
mime
types
will
answer.
Another
question
like
how
you
would
discover
if
we
store
a
server
support,
graphql
or
not
without
sending
the
request,
and
there
is
options,
not
options.
I
think,
like
head
head
options,
some
http
work
for
getting
list
of
mime
types
supported
by
supported
by
this
url.
B
D
A
Cool,
I
also
just
left
a
comment.
While
I
was
talking
there,
there's
an
open
pr
that
talks
about
content
types,
mime
types
and
there
could
be
some
overlap
with
this-
so
right
might
not
even
need
a
separate
viewer
right
yeah.
Maybe
we
can
just
alter
that
pr
or
you
know
yeah,
so
maybe
have
a
look,
read
and
see
what
you
think
comment
on
that:
okay
cool.
I
think
that's
everything
on
the
agenda.
Anything
else
that
we
want
to
discuss.
A
There
is
one
thing
that
I
would
like
to
discuss
so
over
on
the
slack
channel.
There
was
a
discussion
about
the
timing.
We
we
don't
have
a
perfect
time
really
that
that
works
for
jaden
who's
in
australia,
and
so
I
think
he
was
not
able
to
make
it
today.
So
we've
got
to
figure
out
as
a
group
what
we,
what
we
do
to
make
sure
that
it's
possible
for
everyone
who
wants
to
join
to
join.
A
I
was
going
to
ask
you
what
is
you
know
the
working
group,
the
main
spec
working
group?
How
do
they
make
that
inclusive
for
people
who
are
in
other
time
zones.
B
We
also
have
like
andy
and
he's
from
australia,
and
he
constantly
have
a
trouble
joining
this
working
group,
but
we
we
tried
to
discuss
something,
but
this
basically,
we
died
in
a
sense
with
discussion.
B
B
If
we
open
this
issue
a
week
before,
like
two
weeks
before
working
group
and
have
like
four
for
one
week
to
choose,
choose
a
time
and
like
whatever
times,
what
take
most
most
voids
win,
and
we
just
do
it.
A
B
So
maybe
we
can
find
like
second
time
zone
and
switch
between
one
one
month
with
one
time
zone
another
month.
That's
another
time
zone.
A
B
Yeah
like
I've
one
thing
I
would
actually
love
to
do,
I
think
like
I
would.
I
will
try
to
ask
somebody
from
linux
foundation
to
connect
me
to
somebody
from
other
organizations
like
not
foundation
or
others.
So
I
cannot
actually
ask
these
questions
because
I
think
it's
not
that
easy
to
find
on
the
internet
answers
to
this
question,
but
I
don't
think
we
are
first
organization
facing
these
issues.
A
I
mean
just
thinking
about
it.
I
think
one
possible
solution
would
be
to
go
to
to
find
a
way
to
do
a
more
asynchronous
working
group
so
that
we
don't
have
to
meet
up
all
the
same
time.
I
don't
know
exactly
if
they're
people
who
are
doing
that
successfully,
but
that's
a
possible
way.
Sorry
dennis,
I
think
you
were
maybe.
C
C
B
It's
like
it's
same
for
me.
It's
actually
like
for
me
like
every
day,
is
the
same
because
I'm
like
don't
have
official
job
so
like
I
don't
care
it's
working
day
or
weekends,
but
some
people
like
how
families
not
my
case,
but
people
have
a
families
and
basically
it's
like
it's
in
through
the
work-life
balance.
B
B
C
D
A
B
A
C
B
Work
when
I'm
not
sleeping,
but
at
least
we
make
a
pose.
So
initially,
I
think
like
is
a
meal
sam
just
pick
a
random
type
so
having
this
paul
confirms
that
it's
like
at
least
like
this
time
fits
majority.
So
I
think
paul
was
useful
in
a
sense
that
it's
not
random
time.
It's
at
least
it's
time,
but
maybe
random
time
is
more
fair.
C
C
B
Attempts,
but
there
is
like
one
one
thing
before
we
forget
it.
I,
like
some
suggestion
of
doing
it
more
more.
B
A
A
I
think
we
have
to
get
better
at
communicating
through
things
like
github
and
slack
and
change
how
we
organize
things
like,
I
think,
that's
a
possibility.
Like
you
look
at
companies
like
automatic,
for
example,
you
know
who
support
wordpress
and
they
do
a
lot
of
asynchronous
work,
barely
have
any
like
synchronized
calls
or,
or
anything
like
that,
and
so
I
think,
that's
a
possibility,
but
we
just
have
to
kind
of
change
how
we
think
about
things
and
how
we
communicate
and
maybe
like.
If
someone
wants
to
present
something
well,
do
a
screen
share.
A
A
B
Like
it's
good
to
do
to
have
a
live
session
for
question
and
answer
and
for
presenters,
but
I
feel
like,
for
example,
for
proving
stuff.
We
can
go
asynchronous.
So,
like
one
of
the
things
we
have
with
least
interested
developers,
which
is
which
was
shared,
but
it
was
some
someone
idea
to
actually
create
this
list.
B
B
And
in
that
case,
we
will
still
have
like
working
group
calls
for
click
back
and
forth,
but
person
don't
feel
like
the
only
way
for
his
voice
to
be
heard
is
by
being
here-
and
this
is
also
unboxed
unblocks
like
stuff.
So,
for
example,
pharisee
instead
of
presenting
here
person
can
create
rfc.
We
can
send
this
email
or
like
mention
on
github
all
the
developers,
or
we
can
do
both,
send
the
email
and
match
them
on
github
and
the
person
that
needs
to
present.
B
A
Well,
do
you
want
to
talk
more
about
that
now?
Should
we
just
kind
of
close
the
conversation
now
we
can
kind
of
keep
talking
about
improvements
to
that,
maybe
over
slack
as
well
in
the
interim.
B
Yeah
like
if
you're
interested
it's
actually,
you
suggested
asynchronous
stuff
like
we
can
have
issue.
We
can
start
discussing
that
on
your
stuff
and
self-processing.
Instead
of
waiting
for
next
working
group
called
to
discuss
it
yeah,
because
it's
like
right
now,
it's
just
like
brainstorming,
and
it
was
my
just
right
idea
from
top
of
my
head.
It's
not
necessary.