►
From YouTube: API Vision working group | 10/03/2022
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
C
C
Okay,
I
think
we
we
can
start
so
I
was
not
here
last
week,
so
I'm
not
sure
about.
If
we
are
going
to
do
this
like
more
I
think.
But
my
idea
is
like
to
list
here
like
a
at
the
beginning,
the
exit
criterias
and
where
we
are
so,
we
have
a
couple
of
updates.
C
One
is
for
the
for
the
documentation
that
Katie
and
axel
they
are
going
to
catch
up
out
the
next
steps
for
the
API
docs
and
cleanup
assisting
user,
a
issues
related
to
the
Creative
Learning
paths
and
contents
to
contribute
to
the
API
and
the
dri
of
that
one
and
I'm
going
to
start
I
haven't
started
yet
so
before
next
meeting
I'm
going
to
see
where
we
are
and
I'm
going
to
list,
like
all
the
content,
assisted
content
that
we
have
I
know
that
there
are
like
YouTube,
playlists
and
other
things
to
contribute
to
the
API
graphql.
C
A
Yeah
I
pulled
my
my
note
up
into
the
extra
Crusher
your
list
here
so
for
the
things
I've
been
focused
on
as
dri
prior
I've
been
prioritizing
the
internal
API
user
survey.
So
this
is
kind
of
an
Extinction
of
API
Gap
analysis
and
I
have
had
a
lot
of
feedback
from
the
team
here
and
and
others
with
as
I've,
been
developing.
That
survey
so
finally
completed
that
and
sent
it
out
through
a
couple
of
slack
channels
and
through
the
engineering
week
in
review
doc.
A
I
don't
know
if
that's
like,
if
there's
a
a
video
or
conversation
that
happens
around
the
week
in
review,
so
I
was
going
to
ask
a
question
about
that,
but
I
think
in
in
any
case.
So
far
the
response
has
been
pretty
minimal,
so
I
would
like
to
I
think
we'll
have
to
do
some
reminders
and
and
nudge
some
people
to
participate
or
put
it
into
additional
channels.
A
But
we've
got
to
start
here
and
so
I
think
it
would
be
helpful
for
for
folks
to
pitch
in
and
kind
of
nudge
it.
You
know,
share
to
your
teams.
Anyone
on
the
team
here
and
encourage
participation.
C
C
B
Basically
done
with
the
weight
book
stuff
those
the
deliverable
stuff
on
a
plate,
but
basically
what
we
need
to
do
with
that
is
prove
that
it
makes
sense.
So
performance
issues
were
raised
whether
this
is
actually
feasible,
Beyond
sort
of
toy
examples
for
real
things,
like
fetching
lists
of
issues
and
stuff
like
that,
so
what
we
need
to
do
is
we
need
to
basically
I.
C
B
The
appropriate
thing
to
do
here
is
working
on
on
a
defined
Scopes
like
list
of
issues
is
a
good
example,
because
it's
quite
complicated
and
attempting
to
bring
it
as
CL
as
close
as
possible
to
the
performance
of
the
other
rest
API.
B
If
there
are,
you
know,
unhandled,
n
plus
ones
that
we're
not
dealing
very
well
with
in
the
graphql.
Basically,
can
we
get
it
as
close
as
we
can?
So
what
is
that?
What
are
the?
What
should
it
actually
be
if
we
did
things
as
as
well
as
we
know
how
to
do,
and
so
I
think
a
artistic,
a
test
case
like
that,
where
we
know
what
the
appropriate
performance
level
of
rest
is,
we
think
we
should
be
able
to
get
close
close
enough.
B
If
we
optimize
it,
we
don't
know
what
limits
for
optimization
are
so
I
think
possibly
that's.
The
next
step
is
an
optimization
effort
that
is
probably
going
to
be
a
case
of
try.
It
out
see
how
much
work
there
is
to
do
potentially
create
a
whole
bunch
of
issues
about
stuff
that
needs
to
be
fixed
up,
so
it's
likely
to
be.
If
there's
an
exploratory
effort
and
then
a
bunch
of
other
issues,
and
then
we
need
to
decide
how
much
work
we
want
to
put
into
this.
B
By
any
other
team,
I
think
we
know
what
the
work
to
do
is
well,
so
I
I
think
it's
sort
of
anyone
is
able
to
go
and
optimize
different
parts
of
our
graphql
schema.
So
that's
not
that's
not
a.
C
So
in
the
maybe,
the
next
steps
here
is
to
make
progress
on.
This
is
like,
if
you
can
list
what
what
you
are
saying
and
maybe
if
we
can
split
that
into
different
issues,
then
we
can
distribute
the
work
into
different
people
and
we
know
what
are
exactly
the
next
steps
there
right.
B
Yeah
we,
this
was
discussed
a
little
bit
on
the
performance
testing
issue.
I
can
I'll
spread
I'll
split
that
out
and
CCU
there.
C
C
Maybe
some
weeks
is
just
organizing
work,
maybe
others
are
like
Distributing
work
or
maybe
you
know
it
depends,
but
I
like
to
see.
You
know
that
every
every
couple
of
weeks
we
are
making
kind
of
progress.
So
if
I
mean
we
got
missed,
you
know
we
we
had
a
busy
on
holidays
for
two
weeks.
It's
fine
but
I
want
to
see
like
that.
We
are
making
price
in
every
single
exit
criteria,
and
maybe
we
have
like
a
small
task
or
issues.
Maybe
we
can
like
also
engage
with
other
team
members.
C
A
I
had
a
question
too:
maybe
I
missed
some
of
the
conversations,
so
the
performance
testing
issue
did.
Was
it
the
memory
team
that
was
supporting
a
little
bit
there?
Did
they
did
they
do
some
some
testing
or
is.
D
B
Yes,
I
suppose,
although
who
was
it,
who
was
doing
some
of
the
testing
with
us?
Sorry
I've
forgotten
his
name.
A
Okay,
I'll
pull
up
the
issue
as
well:
I'm
kind
of
blanking
as
well,
but
I
remember
they
were
participating,
I
thought
they
had
just
kind
of
slated
it
for
maybe
15
4,
and
so
then
maybe
we
can
Circle
back
and
see
if,
if
that
happened
or
if
there's
still
appetite
to
to
help
with
some
of
the
testing
aspects,
okay,.
C
So
we
have,
we
have
an
issue
that
is
to
do
that.
Yes,
let
me
let
me
link
this
here.
C
And
this
is
the
issue
here
so,
but
basically
I'm
not
sure
if
we
are
blocked
by
that
issue
or
like
is
a
he's
saying
like
how
we
can
organize
this
for
to
make
progress
during
the
next
two
weeks.
You
know.
A
C
D
Make
memories
so
currently
no
progress
from
my
side,
because
one
week
I
was
like
a
PTO
and
last
week
we
were
good
to
get
together
in
with
the
with
the
rest
of
the
team.
So
I
haven't
done
any
work
like
in
the
last
two
weeks
but
like
as
we
were
discussing
in
the
merge
request
for
for
the
executive
criteria.
D
I
think
it
makes
sense
to
discope
some
parts
of
the
Epic
that
are
related
to
deprecations,
that
we
want
to
add
to
V5
in
terms
of
you
know,
functional
they're
currently
having
before,
but
we
don't
need
to
add
them
to
V5
and
I
think,
because
the
progression
is
different
than
design
and
maybe
a
blueprint.
We
want
to
write
for
V5
and
yeah,
so
I
think
those
at
least
could
be
the
scoped
and
but
for
the
rest,
I
need
to
catch
up
with
the.
D
So
primarily,
we
would
like
to
do
two
blueprints
one
for
graphql
and
one
for
rest
V5
and
understand
what
what
are
the
gaps
there?
What
are
the
functionality
we
need?
D
A
D
To
understand
we
was
the
state
of
graphql
is:
is
it's
I'm
a
lot
more
familiar
with
the
state
of
rest,
but
a
lot
less
with
graphql,
so
am
I.
Yeah
am
I
paying
Alex
every
now
and
then,
if
I
have
any
questions
and
we
can
figure
things
out
from
there.
C
D
So
the
next
two
weeks,
let's
just
have
a
I'll,
try
to
have
like
a
plan
of
what
makes
sense
to
tackle
first
by
next
week
and
and
catch
up
with
all
the
discussions
that
we
have
in
the
Epic,
because
at
the
moment
seems
a
bit
too
big
and
I
need
to
figure
out
who's.
Gonna
do
what
work
or
what
issue,
because
some
of
them
are
assigned
to
to
different
teams
for
what
we
have
in
the
in
the
Epic.
D
C
Someone's
good
so
basically
in
these
two
issues
that
we
discuss
it
like
Alex
and
Fabio,
is
basically
to
organize
things
and
see
where
we
are
right
in
order
to
move
things
forward,
cool.
C
So
the
next
point
that
we
have
here
is
basically
I
mean
I
want
to
involve
more
people,
and
this
is
a
question
not
for
anyone
here
in
the
call,
but
is
basically
a
for
those
that
they
don't
have
like
any
tasks.
If
there
is
any
exit
criteria
or
maybe
an
easy
that
they
want
to
contribute,
I
think
that's
if
a
if,
as
we
are
doing
here
like
if
we
make
plans
and
steps
for
the
next
two,
the
two
weeks-
I-
think
that
probably
is
going
to
be
easier
for
people
to
jump
into
things.
C
So
I
think
that
if
we
continue
that
way
like
saying
okay,
this
next
two
weeks,
I'm
going
to
do
this
so
I
created
this
issue.
So
anyone
can
take
then
I
think
that
is
going
to
be
easier
for
people
to
say.
Maybe
you
can
say:
hey
I
organized
this
work
about
the
graphqlb
blueprint.
So
maybe
it's
easier
for
anyone
like
go
and
take
a
look
into
that
and
maybe
get
involved.
C
D
D
Can
probably
share
in
the
engineering
week
review
that
we
are
looking
for
other
working
group
members
to
collaborate.
D
D
So
I'm
not
sure,
like
I,
know
the
work
that
Alex
is
doing
and
what,
if
certainly
the
the
two
epics
that
I
have
are
quite
large
and
and
I
would
probably
need
to
pick
what
are
the
best
issues
to
tackle
first
and
then
just
focus
on
certain
things,
rather
than
try
to
tackle
the
entire
epic,
with
multiple
issues
from
basically
try
to
tackle
the
problem
from
different
angles.
D
So
I
don't
know
whether
it
makes
sense
to
maybe
pick
some
top
items
and
Tackle
those
kind
of
in
group,
but
yeah
I
would
like
to
understand,
like
you
know
what
what
are
they,
what
other
people
think
about
that
I
have
the
feeling
that,
if,
if
we
spread
ourselves
to
too
thin,
we
will
have
like
a
lot
of
discussions,
especially
with
some
of
the
issues
related
to
whether
different
opinions
like
like
graphql
to
rest,
the
converter
and
also
what
are
their
the
design
for
V5.
D
For
rest
or
what
are
like
next
gaps
to
discuss
for
graphql,
there
could
be
a
lot
of
discussions
that
involved
and
if
these
things
can
can
go
on
for
for
for
quite
a
long
time,
so
I'm
wondering
whether
we
should
pick
some
some
specific
aspect
to
kind
of
prioritize.
What
we
want
to
focus
first
and
try
to
swarm
those
and
then
move
on
to
the
next
point.
C
Do
you
mean
like,
for
example,
I
mean
because
there
are
things
that
maybe
we
can
make
progress
in
parallel,
for
example,
documentation
or
things
like
that?
But
there
are
other
topics
like,
as
you
say,
related
to
architect,
organizations
graphql
blueprints
other
things
like
this,
like
you
want
to
go
more
like
as
a
group
like
say,
let's
focus
on
this
one
during
a
few
weeks
and
then
at
some
point.
Maybe
we
can
work
in
parallel
or
maybe
move
on
into
the
next
Exeter
criteria,
for
example,
right.
D
Certain
things,
like
a
you,
know,
architecture
blueprint.
It
tends
to
take
a
long
time
and
and
first
there's
going
to
be
a
lot
of
discussions.
Try
to
understand
like
involve
a
lot
of
Engineers
to
to
figure
out
different
points
of
view
and
then
put
them
all
together
into
a
a
blueprint
and
it's
a
process
that
normally
takes
like
a
long
time.
D
It
is
like
several
iterations
and
you
need
to
wait
for
feedback
which
might
take
like
a
week
or
two
and
then
like
integrate
that
so
they
tend
to
be
open
for
for
a
month,
certain
merge
requests
and
on
one
side,
you
can
give
us
an
opportunity
to
work
in
parallel
with
other
things,
but
having
too
many
open
topics,
it
can
be
also
a
problem
with
with
the
resources
and
with
contact
switching
and
considering.
We
also
have,
like
other.
You
know,
deliverables.
D
The
other
work
to
do
so,
I'm
wondering
whether
we
could,
if
we
pick
some
problems,
we
all
think
about
certain
problems
together
and
try
to
at
least
draft
like
80
percent
of
of
the
problem
and
and
solutions.
Then
we
can
maybe
iterate
on
blueprints
like
a
bit
faster
on
and
integrated
feedback.
D
A
little
bit
faster,
I
think
there's
definitely
something
some
tasks
that
can
be
done
in
parallel
and
we
don't
have
to
all
be
dedicated
to
one
single
thing
at
a
time,
I'm
more
concerned
about
the
more
technical
discussions
where
there
can
be
different
opinions
or
or
different
things
to
tackle,
basically
for
a
single
issue,
so
I
think
documentation
or
learning
material.
This
could
definitely
be
done
like
in
parallel.
C
Yeah
yeah,
so
so
because
you
are
going
to
and
where
you
are
with
them
with
your
epic
that
I
think
that
is
the
most
like.
You
know
and
talking
about
decisions
and
things
like
that.
Maybe
for
next
a
meeting
we
can
discuss,
you
can
say
yes,
which
one
do
you
think
is
the
priority.
D
C
Then
start
working
on
that
as
a
group
I
think
it's
a
good
idea
and
as
you
say,
there
are
things
that
maybe
we
can
do
in
part
like,
for
example,
learning
paths
or
maybe
documentation.
It
depends
what
we
are
doing,
but
other
like
architectural
decisions
or
blueprints.
Maybe
we
have
to
work
as
a
group
so
happy
to
work
this
way,
I
mean,
after
your
suggestions
about
what
should
be
the
priority.
I
think
it's
a
very
good
idea
to
to
do
that
way.
Okay,.
A
B
If
not,
I
ideally
know
because
the
point
of
that
is
simply
as
an
instrument
to
help
us
and
we
shouldn't
I,
guess
I,
don't
think
we
should
limit
our
the
way
we
want
to
design
these
apis
to
because
of
the
limitations
of
an
underlying
tool.
If
that
tool
is
under
the
Lang
limitations,
then
the
tool
needs
either
fixing
or
abandoning.
A
Got
it
yeah
just
wanted
to
check
on
that,
because
that
could
be
another
way
to
consider
how
we
structure
work,
otherwise,
I
think
priorities,
or
you
know
that
the
demand
from
customers
on
certain
items
or
yeah,
like
you,
said
it's
going
to
take
a
lot
more
time
with
the
blueprint.
So
maybe
some
things
could
be
a
lower
hanging
fruit
that
we
could
solve
and
and
start
addressing
customer
problems
in
the
short
term.
A
So
maybe
thinking
about
like
the
deprecations
aspect,
if
we
know
that
there's
going
to
be
a
lot
of
discussion
required,
but
yeah
I
I,
think
everything
we
just
discussed
that
you
just
shared
just
trying
to
come
back
next
next
time
with
a
clear
idea
of
like
the
different
items
and
topics
that
fall
under
that
umbrella
and
your
priorities.
I
think
that
would
be
a
good
start
yeah.
If
there's
anything
I
can
help
with.
Though
let
me
know.
B
Yeah
and
the
other
point
I
want
to
make
that,
because
it
lines
looks
similar
to
what
fiber
is
saying
is
these
are
big
issues
about
tourists
writing
stuff
there
as
well?
I
guess
it'd,
be
nice
to
find
ways
to
close
these
things
out
more
quickly
if
possible,
and
we
want
to
get
things
right.
So
a
lot
of
this
involves
a
significant
apparent
design
work
it'd,
be
nice
to
work
out.
How?
How
can
we
get
stuff
merged
and
moving
forwards
rather
than
lots
and
lots
of
discussion
that
yeah?
B
Can
we
can
we
cut
things
down
not
just
not
just
in
scope
and
Science
in
terms
of
lots
of
issues
to
try
and
get
stuff
moved
forward,
but
can
we
yeah?
Can
we
make
the
exit
criteria
itself
more
I,
don't
know
necessarily
whether
we
should
what
we
should
be
doing
there,
a
good
a
good
example
of
what
I
mean
by
that
is
say
with
the
whole
concept
of
rest
over
graphql.
Is
it
you
know?
Should
we
wait
until
everything
is
perfect?
B
We
know
it
works
for
large,
complex
routes,
or
is
it
fine
to
proceed
Now
by
introducing
this
for
smaller
routes
that
that
we
know
that
might
be
more
acceptable
for
performance?
There
are
pluses
and
minuses
then,
but
it
might
be
one
way
to
get
stuff
shipped.
A
Yeah
and
that's
that's
a
hard
question
to
answer,
I
think
one
of
my
thoughts
on
this
is
like
the
scope
of
of
the
exit
criteria
like
we're.
Not
the
the
outcome
isn't
to
build
a
new
API
like
V5
API
and
to
completely
have
every
API
rest
over
graphql,
but
but
to
make
decisions
about
how
we
want
to
move
forward
so
yeah.
How
do
we
I
think
it's
it's
kind
of
around
I
think
for
rest
of
our
graphql,
it's
kind
of
about
how
do
we
test
and
validate
that
this
should
work.
A
You
know
enough
well
enough
that
we
can
start
moving
forward
with
it
to
even
replace
some
some
endpoints.
So
maybe
I
don't
know.
A
Maybe
it's
not
a
100
solution
for
for
moving
to
grab
ql
of
graphql
first
approach,
but
if
it's
something
that
is
isn't
going
to
impact
us
negatively,
then
maybe
that
that's
enough
to
start
moving
the
needle
forward,
but
yeah
I
think
it
to
me
ultimately
depends
on
what
are
the
outcomes
from
these
performance
discussions
and
kind
of
relying
on
on
on
you
all
to
to
help
validate
that
but
I.
A
B
A
C
Yeah
I
think
for
the
next
meeting.
Really
what
we
can
discuss
is
a
five
years
going
to
bring.
What
are
the
main
topics
that
we
have
to
do
are
related
to
discussions,
and
you
also
Alex,
maybe
on
the
work
that
you
are
doing
related
to
like
cohesive
foundation
of
the
development
strategies.
Another
maybe
topic
so
basically
we
can
see
all
the
main
topics
and
obviously
we
can
discuss
things
I
think
where
we
are,
but
then,
after
that,
maybe
in
the
meeting
we
can
discuss
as
a
group.
What
is
the
priority
as
a
group?
C
A
Don't
believe
so
I
guess
so
we'll
expect
that
others
will
pitch
in
async
on
the
exit
on
this
point,
one
exit
criteria
updates
for
those
who
weren't
able
to
join
today.