►
From YouTube: API Vision working group | 01/23/23
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
A
B
Yeah,
maybe
we
can
give
it
just
another
minute
and
see
if
anyone
else
is
able
to
hop
in.
C
A
Yeah,
otherwise
we
can
jump
in
into
our
next
meeting.
A
Yeah
I
think
I
don't
have
something
to
add
to
the
agenda
as
well:
I
just
yeah.
There
was
just
a
threat
on
Slack
from
the
technical
writing
team
I
think
they
had
some
more
demand
for
open,
API
and
yeah
auto-generated
docs,
but
I
think
there
are
no
there's,
no
nothing
new
and
there
are
just
discussing
this
again
and
there's
a
I
think
there
would
be
we'll
be
happy
to
see
this.
B
B
Looks
like
Alex
will
join
too,
so
maybe
we'll
wait
on
him
and
then
run
through
the
agenda,
which
I
don't
think
we're
gonna
have
too
much
today.
We.
B
Okay,
well,
I
think
he's
on
his
way,
but
I'll
just
go
ahead
and
jump
in
all
right
so
and
I
mean
for
your
benefit
Annie,
of
course,
but
I
guess
for
anyone
else,
who's
jumping
in
on
the
recording
on
my
ends.
B
As
far
as
like
dri
items,
I'm
continuing
on
the
effort
to
refresh
our
API
personas,
so
I've
been
mentioning
that
in
in
the
past
few
meetings,
but
was
able
to
connect
with
uxr
this
past
week
and
we're
starting
the
planning
process
for
that
defining
kind
of
the
the
questions
and
the
target
audiences
which
which
personas
so
we've
got
customer
personas
already
defined
for
git
lab.
B
So
we're
kind
of
trying
to
come
up
with
an
approach-
that's
not
too
too
cumbersome
so
that
we
can
make
some
progress
so
we're
thinking
about
maybe
focusing
on
the
Sasha
and
Sydney
personas
initially
and
then
also
doing
looking
at,
like
kind
of
like
broadly
with
these
different
trying
to
validate
broadly
what
these
different
personas
might
be
as
far
as
like
customer
versus
partner
third
party
maintainer,
if
they
identify
otherwise
so
going
to
be
continuing
on
that
one
item
two
so
yeah
for
awareness
in
this
group
I
know
I.
B
Think
for
for
you
guys
on
the
call
I've
shared
this
already
in
our
own
channels,
but
I've
been
working
on
an
opportunity.
Canvas
light
for
maturing
our
web
hooks
in
gitlab,
so
I
think
it
would
be
of
interest
to
others
in
the
API
working
group
or
those
who
are
kind
of
following
what
we're
working
on
it
might
be
getting
a
little
feedback
on
your
end,
Alex.
B
But
yeah
so
so,
yeah
I
think
the
way
I'm
kind
of
viewing
priorities
with
webhooks
is
I.
B
Think
that,
like
for
one
for
manage,
Integrations
We've,
updated
our
categories
to
the
apis
web
Hooks
and
Integrations,
or
integration
tooling,
is
really
what
I'm
I'm
seeing
us
prioritizing
there
in
the
in
the
in
the
in
the
future,
at
least
and
I
think
that
for
web
books,
we're
approaching
maturity,
I
think
that
we're
close
to
feature
complete,
but
we've
been
seeing
lots
of
gaps
and
when
we're
comparing
against
other
other
similar
businesses
or
competitors.
B
So
so
that
kind
of
highlights
a
number
of
the
different
areas
we'd
like
to
improve
there.
But
I
think
it's
interesting
for
this
group
just
to
kind
of
consider
what's
important
in
git
live
when
we're
thinking
about
apis
versus
web
hooks
or
other
Technologies,
and
then
as
we
as
we
kind
of
Define.
What
our
plans
are
in
terms
of
our
apis,
as
we
have
more
clarity,
I
expect
that
our
team
will
start
to
balance
priorities
between
web
Hooks
and
get
lost
and
apis.
B
But
in
the
meantime,
yeah
there's
some
clear
steps
to
be
taking
with
our
web
hooks,
and
the
last
note
on
that
is
that
two
two
different
issues
that
I
see
I,
feel
like
we
do
have
Clarity
on
in
terms
of
apis
would
be
improving
our
open,
API,
spec
and
automated
docs
and,
and
you
were
kind
of
highlighting
some
feedback
on
that
specific
point,
so
I'm
hoping
that
we're
able
to
still
incorporate
that
soon
and
then
completing
the
rest
of
our
graphql
POC,
which
I
know
we
have
priorities.
B
That's
that's
taking
precedence
for
that,
but
I
do
think
that
we
have
Clarity
on
completing
that
POC
and
then
we'll
learn
from
that.
So
yes,
as
soon
as
we're
able
to
incorporate
that
in
our
plans,
that
would
be
great
and
then
for
anyone
watching
the
recording
or
who
wants
to
participate.
You
know
there's
opportunity
there
as
well
everything
so
any
any
thoughts
or
feedback
from
YouTube
on
one
and
two
before
I
move
on.
A
Yeah
I'm,
looking
at
the
webhooks
the
opportunity
canvas
for
web
maternity
and
as
interesting
to
see
that
we
have
like
one
top
webhook
user.
That's
like
pretty
large
there's
this
pie
chart.
A
So
this
is
comparing
all
all
webbook
users,
or
is
it
just
like
a
if
you
yeah
picked
a
few
users
to
compare.
B
So
that
was
you
know
for
the
span
of
time
when
I
I
ran
that
query,
that's
that's
what
we
could
see
like
there.
There
was
one
one
or
two
customers
that
were
I,
think
an
overwhelming
amount
of
the
usage.
B
But
my
hypothesis
is
there
too,
like
I've
spoken
with
at
least
one
of
those
customers
that
they
were
using
our
apis
and
their
volume
of
of
requests
to
the
API
also
impacted
at
times
our
performance
for
SAS,
like
it
would
slow
down
our
apis
if
they
sent
too
many
requests
and
and
ultimately
they
weren't
optimizing
their
workflows
like
there,
there
were
potentially
better
ways
either
for
for
apis
to
be
optimized
or
for
them
to
approach.
It
I
think
you
know.
B
Ultimately,
they
started
exploring
using
web
hooks
in
cases
that
they
could
and
that
kind
of
cut
cut
down
on
the
number
of
requests.
I
think
graphql
is
another.
Another
Avenue
like
I,
think
that
was
something
they
were
exploring,
but
you
know
they
ultimately
started
using
web
hooks
for
for
some
of
those
use
cases.
So
I
think
that's
I
think
that's
a
pattern
that
I
could
anticipate
for
especially
larger
customers.
B
C
B
I
know,
there's
there's
been
some
discussion
about
some
different
techniques
for
for
managing
events.
So
that's
one
thing
that
I
want
to
be
cognizant
of
and
learn
a
little
bit
more
about
and
see
see
how
that
affects
web
books.
But
at
the
same
time,
like
I
think
you
know,
looking
at
the
industry
is
kind
of
like
table
stakes
in
my
opinion,
to
have
apis
and
web
hooks
at
a
mature
level,
and
then
we
can
start
exploring
where
we
go
from
there,
but
I
feel
like
we.
D
Right,
my
audio
is
sounding
a
bit
rubbish
coming,
so
it
might
be
bad
going
out.
Just
let
me
know
if
that's
the
case,
yeah.
What
you
said
makes
sense.
D
D
So,
yes,
I'm
suddenly
trying
to
polish
them
and
address
the
gaps
there.
Then
I
can
so
yeah
I.
B
Cool
awesome,
yeah,
and
it
is
part
of
our
Direction
already
and
in
a
category
for
managed
Integrations,
but
I'm
also
open
to
critical
feedback.
If
there,
if
there's
anything
that
is
missing
there,
so
yeah
feel
free
to
take
a
look.
Take
a
closer
look
if
you
have
a
chance
and
look
looking
forward
to
any
feedback
from
YouTube
and
from
others
on
the
I
guess
reviewing
the
recording,
okay,
I'll
move
on
to
the
third
point:
oh
I
was
sharing
this
and
then
I
didn't
add
the
link.
B
Yeah,
so
this
was
an
issue
Archer
I'd
ping
me
on
this
end
of
last
week,
but
just
some
recent
feedback
from
user.
A
customer
I
don't
know
the
exact
details
of
how
they're
using
gitlab
today,
but
they
had
a
couple
comments:
I
guess
regarding
graphql
documentation
about
using
graphql
as
as
primary
of
a
rest,
so
I
thought
that
might
be
interesting
to
the
group
I'll.
Let
you
guys
take
a
look.
B
B
And
that
is
that's
all
I
have
for
the
agenda.
On
my
end,
Andy
you
added
0.4.
A
Yeah
that
was
just
like
yeah,
maybe
a
thing
could
we
could
look
at
async
I?
Just
according
to
the
discussion
on
slack
I
got
pinked
into
certainly
technical
writing
team
and
the
the
bottom
line
is.
They
would
still
be
happy
to
see
the
the
full
open,
API
documentation
and
then
also
Auto
generated
markdown
documentation
for
the
rest
API,
because
that's
a
pain
point
for
them
and
yeah
I
thought
it's
worth
sharing,
because
we
it
would
do
a
lot.
A
A
lot
of
work
for
federal
and
yeah
and
I
think
we
all.
We
just
have
to
take
it
from
there
and
yeah
build
the
rest
of
the
open,
Adi,
spec
and
then
yeah.
We
can
look
into
how
to
automate
the
documentation
from
it
right.
B
Okay
and
what
was
remind
me,
what
was
the
most
logical,
Next
Step
for
that.
A
I
think
the
most
logical
next
step
is
to
to
yeah
generate
the
open,
API
documentation.
We
we
pretty
much
got
the
the
API
in
shape
for
it
and
then
for
fat
ramp.
We
we
just
did
a
local
or
generated
this
file
locally
because
it
needs
some
fixes
and
I
think
the
next
step
is
to
get
to
use
our
fixed
grabs
record
Gem
and
then
generate
the
dock
and
also
have
it
in
our
repository
yeah.
Maybe
that's
something
to
do
for
me.
A
B
I
think
that
would
be
helpful.
I
think
we
have
some
some
open
issues
or
epics,
but
maybe
breaking
it
down
or
or
maybe.
A
But
yeah
putting
it
in
order
somehow
and
yeah,
seeing
what's
so
relevant.
What's
not.
B
What
do
you
and
when
you
say
we
exposed
this
internally
I
think
that's
something:
I
was
or
not
necessarily
internally
but
locally,
except
for
fedramp.
We
we
generated
the
open
APS
back
locally.
A
Yes,
I
I,
don't
know
that
much
about
it,
but
I
think
so
we
had
someone
working
on.
So
the
idea
for
federal
was
that
we
would
do
some
automated
scanning
for
the
API
and
for
this
scanner.
We
needed
this
open,
API
file
and
then
I
think
there
were
some
problems
generating
it
and
putting
it
in
the
OR
automatically
generating
it.
So
someone
took
that
and
applied
some
fixes
locally
and
then
got
a
working
or
a
file
that
the
scanner
was
happy
with.
A
Okay,
I
wasn't
good
enough
to
to
have
it
in
the
repository
into
yeah
to
keep
it
up
to
date
because
yeah
there
were
some
manual
steps
involved
and
the
idea
was
that
developers
once
they
changed
something
in
the
API.
They
can
just
run
an
auto
generate
script,
and
this
would
update
the
open,
API
documentation
manual
steps
and
that
it
probably
would
work.
B
B
A
A
I
think
yeah
one
one
thing
would
be
to
get
to
have
some
pipeline
or
some
some
pipeline
drop
in
place.
That
reminds
people
of
doing
it,
like
maybe
something
that
fails
if
the
Ethiopian
API
spec
is
not
up
to
date.
So
people
can
then
run
the
automation
script
on
their
machine
and
then
commit
the
yeah.
The
updates
to
the
file
I
think
that
that's
probably
the
main.
D
Thing
that
that's
what
we
that's,
what
we
do
for
graphql,
so
we
expect
a
manual
update,
but.
B
A
Yeah
right,
so
that
was
what
elements
so
something
that
yeah
prevents
people
from
updating
the
API
without
updating
the
open,
API
spec.
B
Is
there
a
next
step
to
that
to
where
we
could
fully?
Are
they
updating
this,
the
spec,
or
at
least
like?
Maybe
it
still
needs?
You
know
a
review
to
see
if
everything's
correct,
but
like
is
there
something
that
would
you
know,
automate
some
steps
for
developers
and
getting
the
spec
updated
itself
or
versus
like
having
to
make
changes
to
the
spec
as
an
additional
effort.
A
Yeah
we
already
have.
We
already
have
this
task,
that
that
people
can
run
so
the
script.
So
it's
just
like
a
command
line
tool
that
people
can
run
and
it
automatically
Updates.
This
okay
and
I
think
Sean
also
had
a
had
a
version
of
this.
That
would
also
also
run
a
test
so
to
make
sure
the
open,
API
file
is
also
valid.
A
I'm,
not
sure
if
this
is
this
is
ready
to
use
yet
but
yeah.
So
basically
the
automation
is
already
in
place.
We
just
need
something
to
remind
people
of
and
then
also
before
we
can
start
reminding
people
of
that.
We
need
to
generate
the
profile
because
yeah
so
to
have
to
have
it
synced
once
and
then,
and
then
we
can
roll
out
this
rule
for
people
to
to
update
it.
A
Yeah
we
so
at
the
moment
we
have
I
think
like
two
or
three
endpoints
in
the
open
API
level
like
in
the
in
the
repository
and
if
someone
runs
the
script
now,
this
will
generate
like
a
very
large
diff
because
it
adds
all
the
other
endpoints.
A
So
we
do
need
to
do
this
once
or
maybe
step
by
step.
So
we
can
review
and
yeah.
So
people
don't
end
up
with
a
huge
difference,
need
to
figure
out
what's
relevant
for
their
Metro
Quest
and
what's.
B
Not
right,
okay!
Well,
it
seems
like
that
would
be
a
pretty
logical
first
step
for
us
to
like
just
like
start
batching
that
out
because
I
mean
it
seems,
it
sounds
like
the
effort
isn't
entirely
on
manage
Integrations,
for
example
like
if
we
could
kind
of
come
up
with
a
process
to
start
doing
like
generating
the
spec
and
then
kind
of
batch,
maybe
the
diffs
or
even
if
it's
once
I,
don't
know.
If
whatever
makes
the
most
sense,
but
like
seems
like
that
was
something
we
could
do
where
it's.
B
A
No
that's
right,
so
we
yeah,
basically
that's
it.
So
we
can
yeah
do
some
kind
of
batching,
maybe
like
endpoint,
bandpoint
and
then
yeah
I.
Think
that
would
be
pretty
easy
to
maybe
open
merch
requests
ever
once
every
every
few
days,
with
a
new,
open,
API,
difficult,
reviewed
and
then
open
the
next
one.
Until
we
have
the
full
full
API
covered.
B
Yeah,
okay,
cool
well
yeah
I'll,
put
some
thought
into
that
on
on
my
end,
because
it
could
be
just
a
small
issue
that
we
can
include
in
upcoming
Milestones
right.
A
B
Yeah,
just
we'll
have
to
consider
I
know,
there's
lots
of
different
priorities
to
balance,
but
that
could
be
a
pretty
small
step.
B
Cool
yeah,
thanks
for
talking
through
that
I,
have
a
better
understanding.
Now,
oh
all,
right
anything
for
you
to
add
Alex
any
agenda
items
or
topics.
D
That
addressing
a
it's
I
didn't
end
up
with
web
books.
We
range
a
retrospective
to
work
out
where
exactly
that
came
in
either
I
have
a
hypothesis
when,
but
we
need
to
check
but
yeah.
So
if
you
have
any
particular,
if
you
have
any
other
ways,
you'd
like
to
run
that
rich
detective
and
do
it
as
an
normal
async
ones.
But
just
let
me
know.
B
Yeah
and
and
I
mean
these
things
happen,
so
when
wouldn't
wouldn't
take
it
too
hard,
yeah,
we'll
we'll
kind
of
just
see
well,
where
things
came
about
I
know
from
a
PM
standpoint,
there's
some
checks
that
I
feel
like
I
could
be
doing
to
think
about,
and
that's
one
thing
I
was
actually
working
on
is
getting
access
to
a
licensed,
gitlab
account
that
has
like,
like
it's
a
full
group
like
SAS
group,
so
like
right
now,
I
can't
go
in
and
actually
check
what
some
of
the
functionality
looks
like
at
the
group
level
and
the
initial
one
I
set
up
with
a
license
was
actually
just
under
my
username
account.
B
So
I
realized
that
that's
limiting
so
yeah
I
think
there's
there's
a
lot
of
different
angles
to
look
at
this
from
and
yeah
we'll
kind
of
focus
on
on
getting
getting
caught
up
on
that
end
and
then
yeah
hope
hoping
to
really
get
that
rest
over
graphql
POC
back
into
the
plan
soon,
once
we're
once
we're
kind
of
complete
on
work.
D
Exactly
it
just
keeps,
it
keeps
getting
keeps
keeps
getting
by
other
things.
Basically,.
B
Yeah
I
feel
bad
about
it.
Well,
like
I
want
to
work
on
it,
but
you
know
we
do
have
some
of
these
things
that
are
just,
unfortunately,
we
need
to.
We
need
to
knock
out
first,
so
yeah
thanks
thanks
for
raising
that
and
I'll
definitely
I
I
was
thinking.
It
may
be
just
an
async
issue.
That's
specific
to
to
that
problem
as
a.
D
Retro
on
anything,
great
price
should
be
fine.
Yes,
if
you,
if
there's
anything
else,
you
want
to
do
or
if
you
want
to
Loop
any
customers
and
whether
we
want
to
do
any
backboarding
at
a
thing.
That's
a
bit
complicated,
but
we
don't
normally
Bank
poor
bug
fixes,
but
it
depends
when
it
also
depends
when
it
came
in
that
we
need
to
double
check
that
yeah.
B
Well,
I'll
get
caught
up
of
on
on
that.
If
there's
anything
I'm
missing
and
then
yeah
get
an
issue
started
and
I
think
we
can
go
from
there.
If
we
need
to
have
some
conversations,
we
can
do
that,
but
it
I
think
it's
a
good
way
to
like
make
sure
anyone
who
wants
to
contribute
feedback.
We
can
have
it.
You
know
completely
open
public
and
share
with
with
anyone,
who's
interested
cool
all
right.
Well,
thanks.
B
Everyone
for
for
joining
and
Alex
for
hopping
on
after
a
ping
I
know
sometimes
like
might.
B
Yeah,
no
no
worries
I
know
it
can
be
like
jarring
to
be
like
oh
I
need
to
hop
on
the
call.
So
thanks
for
hopping
on
yeah
and
I
hope
you
all
have
a
good
week
and
I'm
sure
I'll
see
you
see
you
on
a
call
here
soon,
all
right.
Thanks
and.
B
Then
I'll
jump
on
that
other
invite.