►
From YouTube: API Vision working group 03/06/2023
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).
A
Yeah
I
think
this:
is
it
I
suppose
we
have
five
participants
in
total.
Let's
get
started
so
I'm,
urvi,
cheddah
I,
don't
think
I've
met
a
lot
of
people
on
this
call
except
Michelle,
so
I
am
group
manager
for
manage
stage
on
product
side
and
I'll
be
facilitating
this
meeting
today.
Grant
is
out
of
office
and
I
think
there
are
also
some
real
changes
that
we
are
working
through.
So
kind
of
you
know
understanding
what
the
API
Vision
will
look
like
going
forward.
A
So
yeah
I
think
that
part
is
really
of
interest
to
me.
So
it's
good
that
you
know
I
get
to
know
that
a
little
bit
better
as
part
of
this
meeting.
A
So
let's
get
started
I'm
going
to
skip
the
introduction
here,
just
keeping
it
read
only
there
is
a
bit
of
a
context
that
Grant
has
outlined
in
the
second
point
of
the
agenda,
so
I
believe,
like
everyone
else
on.
This
call
probably
has
a
good
idea
about.
You
know
what
the
purpose
of
this
meeting
is
and
and
why
you
all
are
having
this
working
group,
but
I'll
just
highlight
it
probably
voice
over
it
here.
A
So
there
is
gqr
gql
issue
that
he
is
linked
here
and
how
we
can
create
a
light
rust
wrapper
over
our
gql
apis
to
accelerate
the
development,
reduce,
maintain
and
submit
our
customers
where
they
are
API,
replication
and
life
cycle
policies.
That's
another
one
and
then
developing
a
more
robust
API
for
programmatic
access
to
our
apis,
which
will
also
support
the
federal
affordance.
A
So
these
are
the
three
main
things
and
I
think
this
is
narrowing
it
quite
a
bit
as
compared
to
what
I
see
in
the
handbook,
because
there
are
a
lot
of
there
are
about
eight
criteria
listed
as
exit
criteria,
siding
with
this
three
as
the
main
focus.
We
can
revisit
that
to
your
point.
As
well
later,
here,
Mishra,
so
probably
something
to
take
away
as
an
action
item
from
here,
and
we
can
look
into
it.
A
We've
also
explored
and
learned
a
lot
from
our
users
of
our
apis
and
exploratory
research.
There
are
Links
of
API
users,
survey,
internal
team
members,
survey,
learning
paths
for
contributors,
okay,.
A
Grant
is
also
proposing
that
we
identify
a
location
to
Define
our
plans
and
ideas,
which
is
great,
so
yes,
I
mean
ultimately,
as
we
find
answers
to
the
questions
that
we
set
out
to
you
know
answer
as
part
of
this
working
group.
We
should
record
that
somewhere
and
that's
the
proposal
here
so
I
I
agree
with
that
I'm
happy
to
discuss
this
more
okay,
so
yeah
I
think
it
makes
sense
up
until
D.
Here
we
will
continue
to
kind
of
write
what
we
find
in
API
blueprint.
B
Yeah
and
then
my
question
is
around
really
I
think
the
exit
criteria
so
I
I,
really
love
these
there's
links
here
to
like
the
user
survey
and
the
internal
survey
and
I
really
love
these
presentations
and
the
goals
set
out.
But
then,
when
I
look
at
the
Epic,
we've
got
one
two:
three:
four:
five:
six:
seven,
eight
you're
right:
eight,
open
nine
total
exit
criteria,
epics
I,
think
the
dris
need
updated,
but
total
there's
305
issues
and
so
in
terms
of
narrowing,
like
what
does
that
look
like
and
how
do
we
get
there.
C
Yeah
I
think
that
that's
a
great
idea
to
narrow
the
stone
I
was
just
I
was
mainly
looking
to
the
documentation,
part
and
I.
Think
there's
there's
some
yeah.
We
can.
We
can
probably
improve
the
exit
criteria
because
also
launches
improved
the
documentation
of
the
API,
but
Improvement
can
be
like
we
can
improve
forever.
So
maybe
we
just
should
be
like
a
more
defined
thing.
So
I
think
that's
that's
a
great
idea
to
to
start
there
and
narrow
the
exit
criteria
down.
A
Okay
so,
let's
start
with
I'll
open
an
MR
to
kind
of
revisit
the
exit
criteria,
and
we
can
take
our
discussion
there.
Does
that
sound
good.
D
A
All
right
anything
else
on
this
point.
A
No,
let's
go
all
done.
E
Oh
thanks,
I
think.
My
next
point
is
mine,
I'm
from
plantim,
and
we
are
thinking
about
adding
arrest.
Api
supports
for
work
items,
which
is
a
new
feature.
We
are
developing
cut
plant
team
and
currently
we
have
already
implemented
graphql
API
for
this,
which
is
not
very
simple
and
it's
safe
to
explain
that
rest
API
will
not
be
easy
or
trivial
to
implement
too.
E
So
we
are
invest
investigating
options
how
to
implement
rest
API
or
this
new
work
items
feature,
ideally
in
the
way
that
we
don't
have
to
double
our
efforts
going
forward
having
both
graphql
and
trusty
API.
So
I
wanted
to
sync
up
with
this
working
group
and
basically
find
out
what
is
basically
current
stage
of
this
working
group
if
it
was
already
decided
whether
we
go
with
generating
Crest
API
from
graphql
or
the
opposite
way
to
find
out
what
are
estimated
dates
for
having
something
done.
E
In
other
words,
if
it's
reasonable
to
think
out
that
to
think
that
we
could
basically
generate
rest
API
from
our
existing
graphql
and
if
so,
if
we
can
help
somehow,
or
rather
if
we
should
just
try.
Implement
rest
API
svr
used
to
do
for
other
resources
and
do
basically
two
separate
implementations
both
for
graphql
and
Forest,
going
forward.
E
C
C
So
we
decided
to
keep
rest
API
and
it's
I'm
just
I'm,
just
trying
to
recall
what
we
talked
about
it's
probably
documented
somewhere
and
that
we
with
the
next
rest
API
version.
We
want
to
have
it
generated
from
graphql,
but
I
will
have
to
look
up
if
we
have
something
written
there.
There
are
probably
some
issues
or
something
about
this
yeah,
but
this
is
just
what
I
recall.
E
Oh
thank
you.
Yeah
I
went
through
a
couple
of
related
issues
today,
and
it
seemed
to
me
that
there
are
some
performance
concerns
regarding
this
generating
test
API
on
top
of
graphql,
which
are
not
solved
yet.
So
it
seems
to
me
that
we
are
still
in
early
phase
when
we
are
investigating
all
options
or
so
I
understand
that
the
most
probable
would
be
to
go
with
generating
this
rest
from
graphql
or
is
still
in
game.
The
other
option,
like.
E
C
Yeah
I
think
that's
that's,
probably
a
larger
topic.
I
guess
it
would
be
probably
hard
to
to
implement
all
of
the
rest
API
from
graphql.
It
should
be
possible,
but
it
sounds
like
a
like
a
huge
effort.
C
E
Okay,
cool
yeah
so
probably
no
need
to
figure
this
out
call
and
is
there
some
estimated
timeline
when
you
expect
we
could
get
to
the
point
where?
Okay,
at
this
point,
we
are
able
to
Auto
generate
at
least
specific
endpoints
rest
and
API
endpoint
from
graphql
or
I.
Think
someone
mentioned
three
to
five
years
vision
from
now,
which
is
quite
far
but
I,
guess
that
it's
General
Vision
of
of
API
going
forward
so
I
wonder
if
there
is
more
specific
time
estimation
or
having
some
partial
goals.
E
Also
like
that
I
mean
if
the
point
should
be
okay,
let's
now
wait
another
year
or
two
or
having
this,
it
might
make
sense
to
another
Implement
rest
API
for
work
items,
the
old
way.
C
Yeah,
that's
a
good
question.
I
think
I
think
I
think
at
the
moment
it's
probably
easier
to
generate
it
the
old
way,
but.
C
Yeah
I
can
look
into
this
a
bit
more
async
I
believe
I've
seen
some
enzymes
that
was
generating
from
rest,
API
already
I
think
we
had
some
trial
and
point,
but
yeah
I
can
I
can
look
into
this
async
and
then
maybe
create
an
issue
for
this
or
yeah
drop.
Your
message:
if
I
find
this
at
Point
but
yeah
in
terms
of
timeline,
I,
don't
think
there
was
a.
There
was
a
timeline
for
this
as.
E
A
management
would
be
happy
to
invest
some
effort
to
this.
Is
there
some
way
how
we
can
contribute
or
engage
in
this
effort
and
help
with
this
or
there's
some
specific
points
we
could
help
with.
C
Like
and
in
terms
of
generating
rest
from
graphql
I
think
if
you
yeah.
E
If
that
would
be,
if
that
would
be
the
decided
by
to
go
forward,
then
probably
yes,
so
I
mean
with
the
overall
effort
with
going
in
this
direction.
Yes,.
C
I
think
I
would
say
you
can
probably
just
go
ahead
if
you
have
a
specific
endpoint
in
mind
and
generate
this
from
from
graphql
already
so
I
think,
there's
I
think
that
wouldn't
be
rejected
and
probably
work.
So
maybe
that
would
be
a
good
proof
of
concept
for
for
the
rest
of
the
API.
If
we,
if
we
have
like
something
working
with
the
method
already
so
I
would
say,
just
just
go
ahead
and
get
started
and
then
yeah
we
can
give
it
a
try.
E
Okay,
that
sounds
like
like
a
good
idea.
D
E
C
Yeah
I
think
I've
seen
one
but
I
have
to
I
have
to
find
it
again.
Yeah.
E
D
C
Cool
yeah,
that's
the
next
Point
it
says,
can
be
read
only
so
I
thought,
maybe
if
we
are
short
on
time,
can
be
async.
It's
just
a
very
quick
thing:
I
just
created
a
merch
request
to
come
up
with
a
vision
for
the
open,
API
documentation.
C
The
reason
is
because
I
was
working
on
an
open
API
but
keep
coming,
keep
finding
blockers
or
things
that
delay
it.
So
I
thought,
maybe
maybe
we
should
start
with
the
vision
and
explain
what
we
want
to
achieve
with
open,
API
and
then
yeah
and
then
work
towards
it,
because
that
will
probably
take
a
bit
more
time
that
we
have
something
documented
already
so
yeah.
If
you
have
some
early
feedback
on
this,
that
would
be
nice,
but
I'm
still
in
draft
mode.
C
F
Thanks
Andy
I
also
just
note
there.
If
you
wouldn't
mind,
if
you
could
ping
Evan
Reed
for
a
review
on
that
at
some
stage,
Evan
is
going
to
be
the
dri
for
the
new
merged
import.
Integrations
group
I
forget
what
that
group
will
be
called,
integrate,
I
think
but
I
think
ultimately
he's
going
to
own
that
page
going
forward.
So
I
think
he
would
be
a
good
person
on
the
tech
writing
team
to
review
that
as
well.
A
Okay
and
I
checked
in
the
last
agenda.
There
was
some
discussion
around
generating
open
apis
spec.
So
I
was
wondering
if
that
is
in
progress,
is
it
still
aligned
with
where
we
want
to
go
with
this
working
group?
Or
you
know
what
are
your
thoughts
if
any
on
that.
C
If
you,
if
you
could
link
this
action
item,
it
would
be
nice
I
couldn't
find
it
right
now,
but
I
think
I
think,
like
I
said,
generating
the
rest.
Api
takes
longer
than
I
expected,
like
building
just
generating
functionality,
so
I
I
would
maybe
propose
to
not
make
it
as
part
of
the
working
group
to
to
finish
this
generation
and
just
like
yeah
at
the
vision
and
roadmap
for
it
and
yeah.
Then
that's
it
for
the
working
group
and
then
we
can
continue
working
on
this
roadmap.
C
That
would
be
I
think
there
will
be
a
more
yeah,
a
result
that
we
can
can
have
faster
and
yeah.
The
whole
generating
thing
might
take.
Take
a
bit
longer.
A
Sure
that
makes
a
lot
of
sense.
Mastermind.
Is
that
I
think
there
are
a
lot
of
in
general?
There
is
a
lot
of
content
on.
You
know
what
this
group
wants
to
achieve,
but
was
there
did
you
like
discuss
some
goals
around?
A
What
will
this
accomplish
like,
for
example,
having
a
method?
Maybe
an
automated
method
of
converting
gql
to
rest
API
will
expedite
50
of
all
the
API
work.
That's
being
done
were
there
some?
A
C
Yeah
I
think
this
will
probably
a
question
that
we
should
ask
grants
because
I'm
I'm
not
entirely
sure
I,
just
look
mostly
into
the
documentation
part
of
the
working
group,
but
they're
not
super
familiar
with
the
rest
of
the
documentation.
So
maybe
we
can
at
least
this
question
for
a
brand
to
to
answer.
When
he's
back.
A
No
all
right,
then,
yeah
I'll
follow
up
on
my
action
items
here
and
we
can
collaborate
on
the
Mr.
Thank
you
all.
Thank
you.