►
From YouTube: API Vision working group #11
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
I
was
going
to
give
it
just
another
minute
and
see
if
anyone
hopped
in,
but
we
can
go
ahead
and
get
started.
So
I
think
this
is
actually
our
12th
meeting.
So
thanks
everyone
who's
continued
to
participate.
I
think
we've
got
that.
We've
made
some
good
progress.
I
think
there's
there's
still
a
good
ways
to
go.
So,
let's,
let's
keep
up
the
momentum.
B
Sorry
so
can
I
have
like
a
quick
summary
of
the
last
two
three
months
like
about
the
progress
of
the
group,
just
in
one
minute
you
know
like,
and
then
I
can
go
into
the
details.
Reading
the
you
know,
documents
and
issues
and
all
the
things,
but
in
one
minute
like
what?
What
is
the
state
at
the
moment
of
everything.
A
Yeah,
so
I'll
jump
in
and
hit
hit
a
highlighter
too,
I
think
maybe
fabio
and
alex
you
guys
might
want
to
want
to
share
as
well.
I
think
the
the
main
area
we've
been
really
focused
in
is:
is
this
idea
of
of
setting
up
a
a
wrapper
around
our
graphql
apis
and
really
trying
to
to
explore
pocs
with
that
so
alex
put
together
a
poc
for
that
marshall
has
a
second
approach
as
well.
A
So
I
really
think
that
that's
kind
of
the
crux
of
our
next
steps
is
really
vetting
that
out
trying
to
understand.
If
that's,
you
know
going
to
be
a
valid
approach,
moving
forward,
which
would
help
us
to
then
kind
of
alleviate
teams
in
terms
of
really
focusing
foremost
on
on
the
graphql
api
and
then
leveraging
this
rest
wrapper
to
more
efficiently
contribute.
C
C
Some
context
on
that.
The
reason
that
this
is
being
approached
in
the
first
place
was
thanks
to
grant
brown
did
some
some
really
good
survey
work,
trying
to
work
out
what
the
consumers
and
the
clients
needed,
and
it's
pretty
clear
that
the
big
conclusion
from
that
is.
We
can't
really
abandon
either
of
these
approaches
at
risk
or
graphql.
You
need
to
support
risk
for
a
for,
especially
for
third-party
consumers,
and
but
on
the
other
hand,
we
don't
want
to
duplicate
all
that
work
internally.
C
A
Exactly
yeah,
thanks
for
for
sharing
that
alex
so
yeah
we,
you
know
we
have
done
the
user
survey,
we're
continuing
to
have
interviews.
Sometimes
scheduling
has
been
a
challenge
there
trying
to
get
especially
larger
enterprise
companies
pinned
down
to
to
talk
through
this,
so
so
working
on
that
continuously-
and
I
would
really
point
out-
and
this
is
something
I
was
going
to
touch
on
today-
might
find
the
issue
you
know.
We
also
try
to
summarize,
I
think,
or
let
me
let
me
put
another
way
I've.
A
I
have
tried
to
summarize
where
I'm
seeing
us
going
what
the
direction
is
looking
like
into
this
api
vision,
prioritization
proposal
and
what
I'm
hoping
is,
is
that
we
could
use
this
as
kind
of
a
discussion
issue.
You
know,
make
some
tweaks
and
then
moving
into
mr,
I
was
gonna.
Ask
the
question:
do
I
just
need
to
go
ahead
and
move
this
to
an
mri
and
have
the
discussion
there?
A
That
might
make
the
most
sense,
but
haven't
haven't
seen
a
ton
of
engagement
there
yet,
but
to
me
this,
I
think,
breaks
down
a
lot
of
of
where
we're
seeing
things
from
my
perspective.
So
again,
I
think
it
does
require
a
little
more
feedback.
I
think
we
are
identifying
that
some
of
this
hinges
on
how
this,
what
we're,
calling
the
raisin
poc,
how
well
that
that
will
work
to
solve
the
problems
that
we've
highlighted
so
yeah
anything
else
that
we
would
point
out,
maybe
fabio.
I
know
you've
been
really
engaged.
D
Yeah,
I
I
think
you
pretty
much
summarize
well
and
I'm
not
sure
there
is
anything
else
we
can
add
at
the
moment.
I
think
definitely
the
next
step
would
be
to
refine
the
plc
and
do
some
testing
and
make
progress
on
that.
I
would
say,
but
that
would
probably
be
the
biggest
kind
of
chunk
of
work
and
other
issues
that
I
remember
seeing
on
the
board
are.
D
More
kind
of
like
smaller
aspects
and
more
specific
aspects
to
fix,
and
we
I
think
we
might
need
to
discuss
how
we
want
to
tackle
those
and
whether
they
fit
in
the
roadmap,
maybe
of
the
division
but
yeah.
I
I
think
that
the
over
there.
C
A
Yeah,
I
will
highlight
that
too,
so,
we've
captured
feedback.
There
were
a
couple
of
product
teams
that
have
contributed
to
that,
especially
with
with
fabio
your
your
help,
kind
of
getting
it
out
there.
I
think
on
this
one,
so
there
should
be
a
link
here,
yeah
to
the
spreadsheet,
where
we
can
start
to
see
oops,
I
didn't
mean
to
go
new
window,
so
we
can
start
to
see.
A
You
know
what
gaps
have
been
identified
that
exists
today
for
these
groups
and
where
possible,
I've
tried
to
capture.
You
know
some
some
level
of
estimation
back,
so
I
think
a
next
step
on
this
one
is
trying
to
think
about
how
to
scale
this,
to
share
more
broadly
across
the
team
or
across
sorry
across
gitlab,
and
some
of
the
feedback
has
been.
A
That
could
change
what
the
really
what
the
effort
would
be,
or
there
might
be
some
other
approaches
so
trying
to
look
at
this
more
holistically.
I
think,
is
where
to
take
this
next,
but
that's
something
we
haven't.
We
haven't
gotten
too
much
further
on
yet,
but
yeah
the
feedback
we've
gotten
has
been
really
good.
I
really
appreciate
all
the
teams
that
participated
in
that.
I
think
it's
just
now
a
matter
of
kind
of
putting
our
heads
together
and
thinking
about
what
does
the
next
step
look
like
for
this.
This
piece.
D
You
know
what
we
need
to
kind
of
solve
all
this
gap
analysis,
because
what
we
notice
is
like
the
three
main
categories,
but
one
is
we
have
some
functionality
rests
and
we
don't
have
the
existing
functionality
graphql,
the
vice
versa,
and
in
certain
case
we
have
functionality
in
both
cases,
but
the
implementation
differs,
and
definitely
you
know
using
the
wrapper
would
definitely
improve
having
that
at
least
like
having
all
the
scenarios,
where
anything
that
we
implement
in
rest
will
have
an
automatically
something
implemented
in
graphql
and
and
we
can
decide
to
have
the
vice
versa
when
wherever
we
want,
but
for
sure,
then
we
can
guarantee
that
implementation
is
identical,
at
least
from
from
the
logic
perspective.
A
That
that
does
remind
me
of
one
other
point
which
we,
I
don't
think
we've
fleshed
out
too
much
further.
Yet
is,
is
this
opportunity
to
add
includes,
and
now
I'm
just
going
to
blank
on
the
other
approach,
the
other
kind
of
rest
kind
of
implementation,
that
better
maps
to
graphql
includes
and
someone
help
me.
D
A
Yeah,
so
that's
something
else:
we
were
exploring
that
that
could
could
make
a
little
bit
easier
to
support
the
rapper
and
and
for
rest
users
rather
than
having
to
say,
like
go
use.
Graphql,
that's
going
to
help
you,
you
know,
pull
together
various
resources.
A
Instead,
you
can
use
rest
to
solve
that
problem
and-
and
we
just
can
start
supporting,
fill
sets
and
includes
in
the
rest,
endpoints.
D
C
I
think
is
a
rising
is
making
it
is
coming
forward
as
the
the
primary
area
of
incompatibility,
especially
when
it
comes
to
replacing
existing
v4
services,
because
a
lot
there's
a
lot
of
offset
pagination
there.
If
we're
looking
at
moving
forwards,
we
can
replace.
We
can
harmonize
and
synchronize
on
keyset
pagination,
but
so
I
don't.
I
don't
think
that
you
know.
I
don't
think
it's
a
blocker
in
the
future
necessarily,
but
it's
definitely
a
would
be
one
of
the
biggest
engineering
challenges
with
trying
to
replace
existing
services.
D
A
Cool
yeah,
so
yeah.
I
think
we
covered
a
lot
of
the
items
off
the
cuff
trying
to
try
to
do
a
quick
review.
I'm
sure
there's
a
few
other
items
there
and
I
know,
for
example,
docs
is
something
I
wanted
to
cover
and
katie
was
going
to
talk
through
that
here
in
a
minute
as
well.
Yeah
does
that?
Does
that
help
archero
anything
else?
We
can
catch
you
up
on.
B
No,
no,
no,
that's
totally
fine,
more
or
less.
I
know
you
know
from
the
activity
that
I
know
what
is
going
on.
I
think
that's
I.
I
was
getting
a
very
good
idea
about
this,
but
yeah
I'd
love
to
see
that
you
know
that
we
are
starting
doing
like
proof
of
conflicts
and
about
really
complex
things,
and
I
think
that
this
is
going
to.
If
we
achieve
something
like
this,
I
think
this
is
going
to
to
make
a
very
big
impact.
B
You
know
so
yeah.
Thank
you
for
the
update.
A
Yeah
very
much
agree
thanks
for
drew
cool,
so
yeah,
maybe
I
don't
know
if
anyone
took
notes
somewhere.
I
didn't.
I
wasn't
able
to
keep
up
with
that,
but
I'll
try
to
go
back
and
add
them.
A
The
next
item
I
had
added
here
yeah
is
that
I
think
maybe
some
of
you
might
be
familiar.
It's
just
an
issue
kind
of
covering,
I
think,
a
really
good
example
case
of
where
we
have
some
inconsistency.
In
this
case
it
says
api
documentation,
but
I
think
it's
a
mix
of
documentation
and
our
api
behavior.
A
So
I
just
want
to
make
sure
that
everyone
was
aware
of
this.
I
think
trying
to
consider
if
what
we're
working
on
helps
to
address
this
or
if
this
is
something
new
that
we
need
to
account
for,
but
there
are
a
number
of
issues
that
were
highlighted
here,
just
as
examples
of
where
apis
are
not
consistent
in
and
how
we
deal
with
delays
or
asynchronous
tasks,
primarily
that
we
might
have
created
an
object,
and
then
we
we
say
it's.
We
say
that
it's
created,
but
it
actually
has
not
gotten
created
yet.
A
So
I
think
in
this
discussion
we
were
talking
about
well,
we
need
to
use
better
status
codes,
saying
that
this
is
accepted
not
that
it's
been
created
yet.
So
I
think
these
are.
You
know,
I
think,
there's
a
lot
of
these
out
here.
Just
trying
to
narrow
them
down
and
really
highlight
the
use
cases
and
think
about
how
do
we
update
our
standards?
What
do
we
need
to
also
include
in
our
style
guys
to
say
this
is
what
we
need
to
consider
when
we're
building
our
apis
so
yeah?
A
I
think
I
think
this
was
a
really
good,
really
good
summary,
whereas
we
have
lots
of
individual
issues
floating
around
timo,
as
was
a
frequent
contributor
who
pulled
these
together
and
it's
a
really
good
summary.
So
I
want
to
highlight
that
for
everyone-
and
maybe
I'll
ask
the
question,
you
know:
is
everyone
here
aware
of
these
cases
and
do
we
feel
like
we're
on
a
path
to
help
address
these
any
actions
we
can
take
away
from
that?
I
know.
A
E
Yeah,
I
think
we
we
probably
have
a
lot
of
those
inconsistencies
and
I
think
yeah.
The
reason
for
this
is
that
we
don't
have
a
automated
documentation,
so
basically
documentation
needs
to
be
done
by
hand,
and
yes,
I
think
sometimes
this
is
just
forgotten
when
updating
api
endpoints
to
also
update
the
documentation
and
yeah.
I
I
think
this
could
be
one
reason
there
are
inconsistencies
and
if
we,
if
you
find
a
way
to
draw
to
automate
the
documentation,
we
would
probably
find
many
more.
I
guess.
C
Also,
the
fact
that
the
kind
of
things
that
are
being
dressed
in
that
issue-
I
agree-
this
is
very
impressive
collection
of
stuff
that
yeah
states
and
whether
whether
when
you
return,
whether
it's
created
or
accepted,
or
what
back?
What
that,
what
data
consistency
you
can
expect,
I'm
not
even
sure
if
we
can
automate
that,
because
well,
that
has
involves
having
to
know
a
lot
about
the
state
of
the
world.
It's
I,
I
think
a
lot
of
that's
going
to
interest
you.
C
I
don't
think
that
I'm
glad
it's
been
raised
because
that's
something
we
really
need
to
have
a
discussion
about
as
a
developer
community
or
make
somebody
needs
to
make
decisions
on
in
order
to
decide
what
we
mean
by
return
codes
and
how
we
communicate
those
kind
of
things
to
the
client,
because
that's
a
very
I.
I
definitely
want
to
have
a
look
at
that
issue,
because
that
is
that's
going
to
be
interesting.
A
D
Yeah,
I
think,
like
having
some
even
a
guideline
on
what
we
want,
as
consistency
internally
will
be
good.
For
example,
there
is
sometimes
inconsistency
between
using
four
or
four
or
four
four
or
three.
Sometimes
you
know.
Do
we
say
something
is
forbidden
or
is
not
found
and
like
if
you
don't
have
access
to
a
project,
sometimes
we're
2404,
which
makes
sense
in
a
lot
of
cases,
but
in
certain
scenarios
for
permission
level
we
return
forbidden
and
in
which,
like
do.
C
Yeah,
that's
a
very
good
question.
I
I
noticed
as
myself
when,
when
re-implementing,
even
just
a
very
simple
endpoint,
just
the
metadata
endpoint
using
the
graphql
wrapper
the
different
access
levels
and
the
ability
to
to
read
the
metadata
was
represented,
as
represented
currently
in
the
rest,
api
using
403
permission
errors
and
in
graphql.
We
are
very
consistent
about
that,
but
we
render
permission
access
errors
as
as
null
data,
so
we
have
even
between
those
two
apis.
C
A
Great
cool
yeah
good
points,
so
yeah,
I
think
we
can
carry
that
forward,
have
some
more
discussion
on
it.
I
know
katie
had
already
jumped
in
here
and
maybe
a
few
others
so
we'll
we'll
leave
that
one
there
and
let's
continue
discussing
in
the
issue.
A
F
Yeah,
so
I
did
leave
some
detailed
notes
in
the
agenda,
so
I'll
try
not
to
talk
too
much
because
I'm
conscious
of
time
but
right
at
the
beginning
of
this
working
group,
we
identified
that
there
were
some
opportunities
to
clean
up.
Our
api
style
guides
opportunities
to
clean
up
some
low-hanging
fruit.
Basically,
because
we
noticed
a
lot
of
inconsistencies
in
our
api
documentation,
especially
the
rest
api
docs,
simply
because
they
are
authored
by
hand,
and
we
didn't
always
have
good
guidelines
about
how
to
write
those.
F
So
we
identified
some
issues
that
we
could
fix
up
in
the
style
garden.
Over
the
last
few
milestones,
we
have
been
trying
to
make
those
fixes.
F
Everything
from
you
know
just
how
to
document
descriptions,
how
to
document
responses,
how
how
to
document
version,
history,
deprecations
and
so
on
and
so
forth
and
and
then
the
remaining
work
there
is
to
decide
on
a
few
other
standardization
items
like
what
standardizing
on
terminology
and
investigating
some
more
consolidation
work,
because
we
seem
to
have
several
different
pages
that
call
themselves
api
style
guides
and
it's
not
clear
what
the
purpose
of
each
is
so
there's
some
renaming
work.
There
and
possibly
some
consolidation
work
there.
F
So
some
of
the
learnings
from
this
is
that
a
updating,
the
api
documentation
style
guide
has
been
useful
for
doing
documentation,
reviews
because
it
gives
you
something
to
point
back
to
and
it
has
been
used.
So
that
has
been
quite
a
nice
improvement,
and
so
there
has
been
some
value
in
doing
that,
and
also
if
we
we
can
also
use
that
to
feed
into
our
documentation,
ultimate
automotive
automation.
F
Efforts
in
that
in
that,
if
we
have
a
style
guide
in
place,
it
can
help
us
to
design
the
automation
as
well,
to
a
certain
extent.
A
A
F
F
A
The
api
reviews
kind
of
what
does
that
look
like
from
your
perspective,
I'll
stop
there.
F
F
Yeah
I
was
looking
for
an
example
before
this
meeting
and
I
couldn't
find
it,
but
it
was
on
an
mr
that
I
reviewed
recently
where
there
was
a
question
about
how
to
document
version
history
for
a
particular
attribute
and
how
to
do
it
because
it
was
behind
a
feature
flag
and
because
I'd
recently
updated
the
api
documentation
style
guide
to
include
that
kind
of
information.
I
could
then
point
back
to
it
and
say:
here's
here
are
our
guidelines
for
doing
that.
So
I
will
go
back
after
this
and
I'll.
F
Try
find
that
mr
and
I'll
link
to
it
from
this
agenda
just
to
show
that
it
it
does
help
with
those
kind
of
things,
especially
especially
when,
with
the
more
subjective
information.
So
there's
quite
a
lot
that
we
can
achieve
through
automation.
But
there
is
some
subjective
reasoning
we
have
to
apply
and
that's
where
style
guide
does
come
in
extremely
handy.
A
Cool
yeah-
and
I
was
I
was
asking
that
because
I
was
wondering
like
when
we
are
making
changes
to
our
apis
from
a
development
standpoint.
Is
there?
Is
there
like
a
checkpoint
where
our
developers
go,
do
refer
to
this
documentation?
Is
that
built
in?
So
I
was
wondering
if
there's
maybe
an
opportunity
to
utilize
our
bots
for
that
to
like
identify
like
you're
touching
the
api
and
we're
working
right
now
on
making
these
fixes
so
like
making
sure
that
they
see
the
most
recent
updates,
while
they're
making
while
they're
touching
the
api.
F
Well,
for
for
rest,
api
updates,
it's
treated
as
any
other
documentation
update
because
it's
part
of
the
part
of
the
the
docs
directory
in
the
in
the
gitlab
project,
so
by
default,
a
technical
writer
will
review.
So
I
guess
it.
It's
also
a
case
of
making
sure
that
the
technical
writing
team
is
aware
of
our
api
documentation
style
guides
and
are
able
to
apply
those
rules
when
they
are
reviewing
api.
Mrs,
that
introduce
new
api
documentation.
F
Yeah,
I
would
say
so
I
would
say
in
terms
of
the
clean
up,
we're
we're
getting
there.
We've
we've
done
a
fairly
good
job
of
cleaning
it
up.
We
obviously
now
have
a
significant
backlog
of
documentation
that
needs
to
be
fixed
in
order
to
adhere
to
the
new
style
guide
rules
not
to
the
new
style
guide
rules,
but
to
standardize
according
to
it,
but
that
that
is.
That
is
not
something
that
I
think
anyone
on
the
technical
writing
team
has
got
the
capacity
to
handle.
F
A
Yep
good
good
note
there
yeah,
maybe
that's
something
we
can
figure
out
how
to
crowdsource
and
as
as
we
start
sharing
more
of
this
back
to
other
teams.
I'll
keep
that
in
mind.
You
know,
we've
got
the
api
gap
analysis.
I
think
this
is
another
opportunity
to
say
if
you
want
to
contribute,
here's
a
place
to
start
doing
that,
and
I
like
this
idea
of
maybe
a
hackathon
or
I've,
seen
the
pajamas
day
kind
of
contribution
approach.
D
Even
if
we
are
going
to
introduce
the
wrapper,
we
probably
want
the
rest
version
of
the
endpoints
to
still
be
documented
in
similar
places
where
the
current
rest
documentation
is
so
may
want
to
somehow
automate
part
of
that
documentation,
because
at
least
like
in
the
last
year
at
least,
I
found
at
least
two
end
points
that
were
not
documented
and
one
though
that
was
partially
documented,
and
so
it
definitely
is
a
challenge
to
keep
things
insane,
because
it's
all
manual
work.
C
Yeah,
I
think
I
agree
the
more
automation
we
can
do
here.
The
better
I
mean
perhaps
the
lowest
hanging
fruit
is
a
ci
job
that
looks
at
all
our
roots
under
under
the
under
the
api
namespace
and
then
looks
in
our
in
our
documentation
to
ensure
that
we
have
examples
of
at
least
one
of
each
all
of
these
roots.
I
mean
that
would
help
us
find
undocumented
endpoints,
perhaps
even
if
it
wouldn't
write
the
documentation
for
us
in
the
first
place,
which
is
I,
which
would
be
the
ideal
endpoint
there.
D
E
Yeah
think
that's
a
good
idea,
one
challenge
that
is
to
find
the
like
the
documentation.
It's
not
really
linked
to
routes
for
an
api
and
pencil.
We,
I
think
yeah
every
piece
of
documentation
needs
some
kind
of
yeah
identifier,
that
maps
it
to
a
route
in
the
api,
but
I
think
that's
a
good
idea
to
find
the
undocumented
ones.
C
A
Good
feedback,
I'm
seeing
that
we're
at
almost
9
30
and-
and
I
guess
technically
we're
supposed
to
end
at
9
25.,
so
maybe
I'll
pause
for
a
second.
I
know
mike
you
joined,
and
you
are
a
newcomer
to
this
meeting.
So
maybe
I'll
give
you
just
a
few
minutes
to
share
and
I'm
happy
to
stay
and
go
through
the
last
bullet
here
for
those
who
are
able.
G
Thanks
grant
and
for
anyone
who
I
haven't,
met
already
mike
lebeau
senior
technology
partner
manager
on
the
alliance's
team.
I've
been
working
closely
with
grant
over
the
past.
Well
ever
since
he
joined,
get
lab
and
appreciate
all
the
work
and
the
effort
that
the
ecosystem
engineering
team
has
done
for
alliances
and
our
partners,
so
we're
in
the
process
of
re,
doing
a
complete
rebuild
of
our
program.
G
You
know
we
would
have
a
program
fee,
we
would
charge
for,
and
then
we
would
offer
a
lot
of
different
go
to
market
activities
in
exchange.
For
that
one
of
the
requirements
we're
thinking
of
is
making
it
a
requirement
that
our
technology
partners
integrate
with
gitlab
premium
or
ultimate.
So
the
integration
that
they're
building
requires
the
customer
to
have
premium
or
ultimate
and
they're,
integrating
with
maybe
one
of
those
ultimate
premium
features
and
right
now
we're
just
kind
of
ideating
and
want
to
confirm
the
feasibility
of
this
idea.
G
Do
we
have
the
api
documentation
available
that
we
could
make
this
requirement
of
our
partners
for
all
of
the
you
know,
I
know
that
we
have
like
streaming.
Audit
events
and
features
like
that
that
are
ultimate
features
are
the
docs
that
we
currently
have
today.
Would
they
make
this
a
fees
reasonable
requirement
to
put
on
our
partners
or
not
that's
kind
of
the
question.
A
I'll
jump
in
first
I
mean,
I
think
I
think
we
all
have
the
goal
of
having
our
api
features
exposed
via
api.
I
think
that
there
just
are
cases
where
that
may
not
happen.
I
think
that's
part
of
what
we're
trying
to
solve
for
is
to
reduce
the
number
of
gaps
that
may
exist
in
our
apis
and
in
some
cases
we
may
have
features
in
graphql
that
don't
exist
in
rest
or
vice
verse.
A
So
we
might
have
some
endpoints
that
are
only
exposed
in
rest
and
not
graphql,
and
so
that
could
be
an
inhibitor
to
partners
who
maybe
you're
not
as
as
familiar
or
willing
to
use
graphql.
A
It's
usually
not
the
other
way
around,
but
you
know
there
may
be
some
cases
that
you
know
rest
isn't
getting
the
job
done
and
they
need
they
need
better
performance
or
for
their
case
they
need
graphql
and
that
feature
may
not
exist.
So
there
are
challenges
that
we're
working
to
solve,
but
I
think
you
know
ultimately
a
lot
of
the
features
that
that
we
have
are
reflected
through
our
docs
and
then,
as
we've
discussed
today.
A
To
you
know
sometimes
documentation
updates
are
a
little
bit
may
lag
behind,
so
maybe
our
certain
behaviors
may
not
get
reflected
and
stay
in
sync
and
that's
something
we're
trying
to
solve
as
well.
G
A
I
I
think
one
thing
that's
interesting
as
well
is
like
I
guess
this
depends
on
the
you
know
the
I
guess
the
user
has
to
generate
like
an
oauth
app
or
they
have
to
have
a
user.
That's
calling
the
api
that
has
these
permissions,
so
maybe
the
workflow
I'm
not
sure
what
what
the
entirety
of
what
you're
thinking,
how
this
is
going
to
pan
out
how
this
looks,
but
there
could
be
some
implications
involved,
I'm
just
not
yet
familiar
with.
G
Makes
sense,
okay
sounds
like
initially
it's
more
of
a
green
light.
B
A
A
All
right,
well,
I
know
we're
over
time
at
this
point.
So
if,
if
anyone
needs
to
leave,
feel
free
I'll
hit
on
these
last
few
points
and
then
we
can,
we
can
close
it
out
so
automated
documentation.
My
question
here
is
as
we're
thinking
about
this:
is
this
kind
of
dependent
on
where
we
take
things
with
the
raising
poc?
A
You
know:
does
this
change
our
approach
when
we
look
at
automated
documentation?
Let
me
let
me
stop
with
that
question.
So.
C
I
think
it
it
kind
of
it
somewhat
depends
which
approach
we
take
to
wrapping.
If
we,
if
we
do
the
wrapping
in
in
workhorse,
then
we
need
to
then
we
would
need
some.
C
Either
way
we
do
the
wrapping,
we
have
enough
information
to
generate
documentation.
If
we
do
the
wrapping
in
workhorse,
then
we
would
need.
Then
we
couldn't
share
the
mechanism
for
generating
documentation
between
our
legacy
roots
or,
however
many
hundreds
of
them
there
are
and
any
new
ones
that
we
had.
C
If
we
did
it
in
ruby
with
the
the
gym,
then
we
can
perhaps
share
some
of
that
implementation
by
going
through
things
like
the
great
swagger
gem
for
us,
for
example,
if
we,
if
we
can
basically
push
the
information
through
the
same
place,
either
way,
we
get
the
information
in
the
same
in
the
same
format,
but
we
have
enough.
We
have
all
we'll
have
we'll
know
about
the
return
value,
we'll
know
about
the
parameters
we'll
know
about
the
possible
status
codes.
C
A
C
Yeah
exactly
so
how?
Yes,
exactly
how
we
generate
the
documentation
depends
on
how
we
generate
the
apis
right.
Okay,.
A
And
so
I
asked
this
question:
is
this
issue
so
relevant?
This
is
the
one
that
we
had
kind
of
checked
to
say
like
this
is
this:
is
the
one
we're
working
on
so
andy?
You
had
a
comment
there,
I'll.
Let
you
vocalize.
E
Yeah,
so
this
is
basically
the
issue
is
basically
about
putting
some
document:
automation
on
our
existing
rest,
api
documentation
and
yeah
at
the
discussion
with
evan
here,
and
I
linked
it
there
and
yeah.
I
think
it's
still
very
relevant
and
yeah.
My
plan
is
to
find,
like
alex,
suggested
above,
to
find
some
yeah
low-hanging
fruits,
where
we
can
add
automation
without
yeah,
doing
the
all
of
the
documentation
all
over
again.
E
A
A
Anything
else
you
want
to
add,
I
mean:
have
you
run
into
any
challenges
with
this
one
yet,
or
is
it
still
just
need
to
find
time
is
ultimately
it.
A
All
right
and
then
my
last
question
on
this
was
we've
had
some
requests
about
how,
as
contributors,
how
can
a
contributor
make
updates
for
open
api
spec
they
they're
kind
of
waiting
on
this.
A
lot
of
people
think
are
kind
of
waiting
on
more
automated
docs.
A
So
is
this
something
that
makes
sense
to
to
put
out
there?
I
created
an
issue
and
asked
alex
I'd:
ask
some
questions
your
way
and
and
kind
of
capture
that
in
an
issue
to
hopefully
be
able
to
share
with
contributors
who
want
to
start
working
on
this
now?
Does
it
make
sense
to
to
push
this
in
this
direction?
A
E
I
think
we
probably
will
do
this,
but
yeah
I'm
not
entirely
sure,
and
your
thinking
was
that
if
we,
if
we
ask
contributors
to
work
on
this
and
then
a
few
months
later,
throw
it
all
away.
That
would
be
a
good
experience
right.
A
Yeah,
I
mean,
I
think,
that's
the
risk,
I
think,
but
I
could
also
see
this
working
as
as
to
say:
well,
we
have
up
to
date,
spec
like
an
up
to
date,
specs
sooner
and
and
then
once
we
get
the
automated
docs,
we
can
start
to.
A
You
know,
identify
and
address
the
gap
so
like
I
could
see.
This
is
something
that
converges
at
some
point,
but
you
know
from
a
technical
standpoint.
I
could
be
missing
the
point
on
this.
So
if
it's
it's
a
lot
of
wasted
effort,
I
don't
want
to
ask
contributors
to
to
build
something
out
that
we
then
just
kind
of
wipe
away.
E
Yeah,
but
I
think
yeah,
I
think
it's
very
unlikely
that
we
that
we
would
wipe
it
away.
I
I
think
this
will
probably
be
useful
in
any
case
so
yeah,
I
think,
even
if
we
have
automation
on
our
existing
documentation,
it's
probably
still
useful
to
have
open
api
and
then
at
some
point
we
can
maybe
like
yeah
link
them
together
to
make
sure
it's
consistent.
A
C
Have
no
problem
with
people
starting
to
to
write
completely.
You
know
handcrafted
open
api
documents.
Documentation
like
we
currently
have
like,
like
you
say,
perhaps
we'll
end
up
deleting
some
of
it
and
replacing
with
automation
as
long
as
it's
broadly
equivalent.
I
don't,
I
don't
think
it's
a
big
problem.
C
The
the
the
benefit
of
having
a
better
open
api
spec
would
be
significant
enough,
even
if
some
of
that
work
does
get
deleted
in
the
future
that
the
benefits
were
of
having
that
spec
sooner
would
be
a
good
thing,
so
I
I
think
I'd
be
completely
fine
with
it
and
it
would
give
us
us
something
to
target
towards
when
it
comes
to
generation.
So
I
think
that's
broadly.
Okay,.
A
That
that's
kind
of
what
I
was
envisioning
and
it
helps
to
have
that
validated,
and
I
think
that
in
the
last
the
last
idea
here
is
that
we
could
potentially
nurture
this
issue.
A
bit.
Add
an
implementation
guide
and
be
ready
to
support,
and
that
might,
I
think,
really
help
us
as
we're
working
on
the
raising
poc
and
automated
docs,
so
that
we
can
be
aware
and
kind
of
bring
this
all
together
towards
towards
a
future
point.
A
And
does
anyone
want
to
raise
their
hand
on
this
call,
and
this
is
recorded,
so
we
could
also
see
if
someone
who
hasn't
been
able
to
participate
as
much
as
those
on
the
call
have.
It
would
be
great
to
see,
see
someone
contributing
from
our
list
of
attendees.
A
Okay,
let's,
let's
see
if
anyone
can
jump
in
who's,
watching
the
recording,
all
right
and
so
two
more
points.
I
know
we're
going
over
time,
but
this
is,
I
think,
been
really
valuable,
so
we'll
try
to
hit
these
quick.
I
talked
about
the
api
vision
proposal.
This
is
my
view
of
the
world
and
I
I'm
sure
I'm
missing
things
so
would
really
appreciate
some
discussion
in
there.
C
I
think
it's
an
excellent
proposal.
I
apologize
for
not
commenting
on
it
profusely
I'll,
try
and
find
some
time
to
do
do
that
this
week,
but
it's
it's
looks
fantastic.
A
A
He
did
have
to
pop
off
all
right,
so
I'll,
just
vocalize
for
him.
I
can
see
that
other
working
groups
are
tracking
percentage
of
completion
and
dris
of
each
exit
criteria.
Here's
an
example:
shall
we
copy
this
approach
and
to
that
point
I
will
say
yeah.
That
sounds
like
a
great
idea
archero,
and
it
would
be
great
if,
if
you
can
help
take
the
lead
on
that.
A
No
other
opinions
all
right.
Well,
I
know
we're
over
again
really
appreciate
everyone
who
hung
out
and
look
forward
to
meeting
next
time.
I
think
we
do
have
some
ptos
and
things
that
may
conflict
with
that.
So
I
might
tap
someone
on
the
shoulder
and
see
if
anyone
can
help
on
the
facilitation
thanks.
Everyone
appreciate
it.
Thank
you.