►
From YouTube: API Vision working group | 10/17/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
A
All
right
so
SC
Arturo
is
not
here.
He
left
the
first
note
so
I'll
just
verbalize.
D
A
So
yeah,
the
first
note
was
left
was
from
Arturo
we're
talking
about
exit
criteria
updates
from
each
of
the
dris,
so
anyone
here
feel
free
to
start
filling
in
yours.
If
you
can
please
but
I'll
start
by
verbalizing
our
churros,
so
he
shared
that
under
create
learning
paths
and
content
to
contribute
to
the
API.
He
started
compiling
a
list
of
graphql
training,
videos,
so
I
think
that's
pretty
cool
I
was
looking
through
that
list
last
week,
he's
asking.
A
If
everyone
could
please
let
him
know
if
there
are
any
other
resources
that
he's
missing
from
that
list
for
rest
or
graphql.
On
the
issue
before
next
meeting
I
will
review
what
training
resources
are
provided
by
other
companies,
so
doing
a
full
comparison
for
our
API
state-of-the-art
in
the
industry
issue,
but
in
this
case
focusing
on
training,
resources
and
learning
paths.
A
So
we
have
28
responses
so
far,
I'd
like
to
keep
pushing
on
this
and
getting
you
know
a
little
more
of
a
representative
sample
from
internal
members.
So,
if
you
know
of
any
teams
have
any
personal
connections,
if
you
can
be
sharing
this
around,
that
would
be
really
helpful.
Anyone
else
catching
up
on
the
recording.
Please
share
with
your
teams,
I
think
the
data
that
we're
getting
is
actually
pretty
pretty
interesting,
getting
a
really
good
sense
of
some
of
the
key
challenges
our
teams
are
dealing
with.
A
So
that's
going
to
help
us
to
dig
in
deeper
on
those
items
and
explore.
You
know
areas
that
we
can
really
focus
for
our
team
and
yeah.
If
there's
anything
any
other
areas,
any
other
locations,
you
think
would
be
helpful
for
me
to
post
this
I'll
also
take
feedback
here
and
and
see
if
I
can
get
a
little
more
visibility
on
onto
the
survey.
A
Any
ideas
from
the
team
here.
A
Okay,
no
thoughts,
so
if
you
have
any
ideas,
please
let
me
know
any
other
updates
that
the
team
can
share
before
I
move
to
the
next
item.
A
I
think
Andy
you
were
most
recently
working
on
our
automated
API
documentation.
Is
there
anything
you
can
share
as
far
as
how
things
are
going
there.
C
Yeah
sure
yeah
I
can
give
a
little
status
update.
So
yeah
I
was
looking
into
this
and
this
and
then
it
suddenly
became
or
got
a
lot
of
attention,
because
this
was
apparently
important
for
the
fat
ramp
project
and
I.
C
Think
the
the
reason
for
this
is
because
we
have
have
a
a
API,
fuzzling
dust
scanner,
which
you
know
not
really
an
idea
what
this
is
doing,
but
it
can
use
this
automated
documentation
to
scan
our
API,
and
this
seems
to
be
important,
important,
so
I
prioritize
this
a
bit
and
we
now
have
a
rake
task
that
can
generate
the
open,
API
documentation
and
we
just
know
so.
There's
an
epic
I
can
try
to
find
and
Link
it
and
this
epic.
C
This
has
a
list
of
issues
for
each
issue
or
each
issue
is
for
one
API
endpoint
and
now
we're
basically
working
through
all
these
issues
and
looking
at
each
endpoint,
see
if
there's
if
we
can
add
it
to
the
documentation
or
if
it
needs
some
improvements,
and
then
we
add
it
to
the
documentation
and
the
idea
is
that
we
by
end
of
15.7,
so
the
next
Milestone.
The
idea
is
that
we
have
like
a
75
percent
complete,
open,
API
documentation.
C
There's
probably
can
probably
be
improved
for
quality,
but
at
least
it
will
be
kind
of
complete,
which
is
which
is
pretty
cool.
I
didn't
expect
this
to
go
that
fast,
yeah.
So
there's
a
lot
of
things
happened.
There.
A
Awesome
yeah,
that's
exciting
from
my
end,
I
think.
That's
really
cool
I'm.
Looking
forward
to
seeing
this
in
practice.
D
Yeah
me
too
I
also
I
I
was
following
along
with
that
issue,
and
then
suddenly
there
was
a
flurry
of
activity
there
and
things
just
started
to
happen,
as
you
said
so
yeah
so
I
I
that
actually
reminded
me.
There
were
a
couple
of
things
that
I
was
thinking
about
in
terms
of
that
that
whole
automation
process.
So
these
are
obviously
iterative
things
that
we
can
do
over
time
and
I'm
just
thinking
aloud
at
the
moment,
but
so
we
I
know.
D
In
the
graphql
side
we
have
a
number
of
tests
in
place
for
the
documentation
component
or
the
description
components
of
the
graphql
thinking
about
things
like
implementing
the
same
kind
of
tests
on
for
for
this
side
of
things,
simple
things
like
making
sure
that
all
descriptions
end
with
a
period.
You
know
things
like
that.
We
can
obviously
start
working
on
on
adding
those
kind
of
things
in
future.
D
I
was
wondering
if
maybe
I
should
put
together
an
issue
or
something
to
list
the
kind
of
things
that
maybe
we
can
Implement
from
that
side
in
future
for
future
iterations,
because
we
have
done
a
bit
of
work
on
improving
our
rest,
API
style
guide,
but
that
has
it's
very
much
with
the
focus
being
on
the
markdown
component
of
it.
Whereas
this
is
this
is
obviously
a
different
system
or
method
of
doing
it.
So
yeah.
D
So
I
was
just
thinking
about
that,
because
I,
because
now,
with
with
the
improvements
that
have
happened
in
this
area,
I'm
wondering
if
we
should
even
bother
going
back
and
fixing
our
existing
markdown
documentation.
That
was
the
other
point.
I
was
thinking
about
if
it's
worth
doing
that
or
if
we
should
rather
start
iterating
on
improving
on
the
automated
documentation
going
forward
because
I
was
thinking
about.
Are
we
going
to
have
these
two
systems
in
place
for
a
while?
D
C
Long
yeah
I
think
that
would
be
great.
So
the
the
first
point
about
having
tests
to
to
make
sure
to
Performance
is
right.
I
think
that's
a
great
idea
and,
like
I
said,
probably
not
add
tests
now,
but
it
would
be
nice
to
have
some
rules
in
place
that
we
can
work
on
that
Sean
from
our
team
who's
in
in
testing
automation.
Is
he
already
asked
me
about
how
we
can
test
this
and
I?
C
Didn't
really
had
an
idea
so
far,
but
I
think
those
those
are
good
points
and
I
think
it's
worth
noting
them.
C
The
probably
the
first
thing
we
want
to
test
is:
if
the,
if
the
open,
API
documentation
is
up
to
date
like
when
the
new
camera
Mr
comes
in
with
changes
in
the
codes,
is
it
really
reflected
in
the
open
eye,
documentation
and
then?
But
next
we
can
yeah
a
test
for
for
periods
or
something
like
this
and
about
markdown
and
open
API.
C
What
I
had
in
mind
was
that
we
maybe
can
generate
use
the
open,
API,
the
automated
documentation
to
generate
the
markdown
documentation,
but
I'm
not
sure
what
should
be
the
the
source
of
truth.
I
think
for
now,
at
the
moment,
probably
markdown
is,
is
better
documented,
better
written
everything
than
than
the
other
generator,
so
maybe
I
think
Mark
Jones,
probably
still
the
the
single
source
of
Truth,
and
maybe
we
can
copy
from
markdown
to
the
automated
documentation
but
yeah.
It's
it's
not
really
like
a
yeah.
C
Probably
just
think
about
this
a
little
bit
more,
but
would
be
nice
if
we
if
we
try
to
not
keep
both
systems
at
the
same.
D
Time,
yeah
yeah
exactly
so
I
guess
at
some
point,
switch
to
one
or
just
switch
to
one
as
the
the
authority
on
our
API
documentation.
It's
just
a
question
of
when
and
then
how
much,
how
much
effort
we
put
into
keeping
the
two
in
sync
in
the
meantime,
because
I'm
pretty
sure
that
those
descriptions
in
the
Ruby
files
I
doubt
technical
writers
have
had
much
have
had
much
influence
there
or
have
you
know.
C
D
C
D
C
Yeah,
those
are
the
thoughts,
and
this
is
what
What's
well
I
think
is
most
exciting
about
this,
that
we
will
be
able
to
generate
a
markdown
documentation
from
open
API
that
we
have.
A
A
Yeah,
thank
you.
Anyone
else
on
the
call,
maybe
Alex,
do
you
have
any
updates
as
dri.
B
A
B
And
Martin
Kepler
has
said
that
he
doesn't
have
the
time
to
make
progress
on
performance
testing
for
graphical
and
rest,
so
we're
deciding
how
to
make
progress.
There
I
suggested
two
or
two
options,
as
I
mentioned
on
the
issue
with
Arturo
today,
as
you
decide
how
much
basically
are
we
going
to
go
forwards
with
the
small
and
it's
with
what
we
have
now
at
iterate,
or
are
we
going
to
do
more
or
do
a
larger
hour
item
of
work
in
order
to
verify
that
this
works
for
all
use
cases?
B
So
I
think
well
I
think
there
is
really
reasonably
low
risk
resume
of
what
we
currently
have,
because
we're
just
replacing
a
an
existing
endpoint.
That's
already
implemented,
it's
already
implemented
biographical
underneath
so
we're
not
really
I
would
be
very
surprised
if
performance
is
going
to
be
impacted
by
what
we
cut.
What
we
currently
have,
so
that
might
be
a
more
iterative
way
to
proceed,
and
we
and
so
I
think
we
should
probably
consider
then
things
like
you
know
how
we
get
monitor,
performance
and
and
things
going
forwards.
B
Yeah.
It
brings
a
bunch
of
code
that
if
we
decide
in
the
future,
we
don't
want
for
all
the
rest
of
our
stuff.
That
could
be
a
bit
of
a
bit
of
a
thing,
but
I
think
if
we
want
to
make
progress
on
this
at
all,
that's
probably
the
most
iterative
way
to
proceed,
because
then
we
can
start
sort
of
it
would
be
easier
to
start
testing.
C
A
A
Okay,
any
other
dri
updates.
Were
there
any
others
from
your
end,
Katie
on,
maybe
you
mentioned
roughly
the
the
style
guide,
improvements
and
such
so
I
don't
know.
Is
there
still
work
being
done
there.
D
A
little
bit
I
think
at
this
point,
as
I've
briefly
mentioned,
we're
hesitant
to
go
back
and
see
documentation
because
I
think
it
might
not
be
worth
the
effort
to
do
that
at
this
point.
So
I'm
thinking
more
like
just
focusing
on
the
style
guide,
update
and
how
that
can
be
used
going
forward
for
our
open,
API
documentation
and
thinking
that
should
be
the
next
steps,
because
I
know
to
previously
we
discussed
you
know
just
fixing
up
all
of
our
markdown
documentation,
as
maybe
I,
don't
know
like
a
hackathon
thing.
D
For
example,
that
could
be
good
for
Community
contributors,
but
I'm
wondering
if
it's
worth
the
effort
now
to
to
do
that,
especially
if
a
lot
of
those
fixes
are
of
you
know,
markdown
fixes
that
would
be
fixed
by
automation,
anywhere
going
forward
right.
D
A
A
Yeah
I
do
also
like
this
idea
of
of
trying
to
use
some
type
of
like
a
hackathon
style
day.
B
A
Or
you
know
days
like
the
foundations
team
is
used
for
pajamas
to
get
attacks
on
these
iterative
updates.
So
maybe
thinking
through
how
we
could
leverage
something
like
that
would
be
useful.
Yeah.
A
A
Well.
The
last
item
I
had
is
just
kind
of
pulling
back.
I
know
we
had
a
discussion
on
what
was
it
September
recently
September
18th
or
something
we
talked
about
the
Cadence
and
and
adjusting
maybe
the
the
date
time
of
this
call
to
Monday,
Wednesday
or
Thursday
and
I
just
haven't,
haven't
gotten
to
that.
Yet
so
we'll
probably
work
on
that
before
the
next
several
meetings.
I
do
have
some
PTO
coming
up,
but
we'll
we'll
be
working
on
fitting
this
in
making
the
change
here
soon
so
yeah.
A
If
anyone
has
any
concerns
with
that,
let
me
know
beforehand,
but
probably
we'll
work
on
that
here
this
week
and
that's
all
that
we
have
in
the
notes
any
other
updates
before
we
end
or
we
can
end
a
little
early.
A
Okay,
I
know
we're
missing
a
number
of
people
on
the
call
today,
so,
if
you're
joining
in
on
the
recording,
if
you
could
please
share
updates
on
your
dri
items
in
the
notes
and
yeah
feel
free
to
add
any
other
items
and
let
us
know
in
the
docs
but
yeah
I,
think
that
covers
it.
For
today,
thanks
for
joining.