►
From YouTube: API Vision working group | 11/28/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).
A
B
D
A
B
Yeah
I
managed
in
this
meeting
to
a
squeeze
between
other
things.
Do
you
know
that
I
have
so.
B
Okay,
I
think
that
we
can
we
come
minute
pass,
so
one
thing
do
not
I
think
we
are
kind
of
failing
is
that
we
Define
different
dris
for
the
exit,
criterias
and
I
was
expecting.
You
know
that
for
each
exit
type
criteria
we
get
an
update
at
the
moment.
There
is
my
update
here
at
the
top.
So
so
we
are
working
and
working
with
boyan
to
create
like
learning
paths
and
content,
to
contribute
to
the
API,
so
I
updated
a
how
we
are
with
this
exit
criteria
to
20
percent.
B
So
we
already
reviewed
the
existing
content
that
we
have
and
we
also
reviewed
the
competitors
and
we
get
a
lot
of
ideas
and
the
next
thing
for
us
is:
we
are
going
to
create
a
new
baits
that
is
going
to
be
kind
of
overview
with
all
the
informations
and
all
the
links
that
we
have
for
the
API.
B
And
then
we
are
going
to
create
different
small
issues
for
things
that
we
see
in
the
docs
that
we
can
improve
and
yeah
I
think
that's
probably
two
weeks
we
can
make
a
lot
of
progress
here
as
well
and
more
or
less
is
clear
for
us,
but
we
have
to
do
now
here
and
the
only
thing
is
maybe
missing
content,
maybe
I
have
to
catch
up
with
other
team
members,
but
in
general
is
looking
good
any
any
other
update
boy
I'm
from
you.
A
Items
assigned
to
me
one
is
to
find
the
vision
of
the
galab
API
for
the
future
years,
so
it's
pretty
comprehensive
and
depends
on
a
lot
of
the
other
work
that
we're
doing
so
I'm,
leaving
that
a
10
percent,
the
other
one
I'm
working
on
more
tactically
right
now
is
refresh
personas
to
account
for
users
of
our
apis,
and
so
that's
kind
of
my
update
here
is
that
we
now
have
a
ux
research
issue,
and
you
know
we've
done
a
number
of
surveys
previously
that
kind
of
feed
into
this,
but
this
is
going
to
be
really
narrowly
focused
on
any
kind
of
updates
to
our
existing
personas,
maybe
adding
some
content
about
how
they
interact
with
their
apis
yeah
and
any
questions
kind
of
really
related
to
the
API
personas.
A
So
if
there
are
any
thoughts
from
the
team
here
on
the
call
or
after
the
fact,
you
can
go
into
that
issue,
it'd
be
great
to
kind
of
get
input.
If
there
are
questions
or
topics
you'd
like
to
make
sure
that
we're
covering
in
that
process,
I
think
that'll
pair.
A
What
we
learned
through
this
process
will
pair
really
well
with
the
kind
of
external
API
survey
we
did
in
the
past
and
the
internal
survey
that
I'm
kind
of
working
through
as
well
I
still
need
to
kind
of
synthesize
and
share
share
some
feedback
from
that,
so
yeah
any.
If
you
have
any
thoughts
on
questions,
we
should
be
asking
around
API
personas,
please
please.
Let
me
know.
B
So
do
you
see
that
we
are
going
to
have
compared
to
the
personas
that
we
already
have
do
we
need
to
create
new
personas
or,
like
you
know,
is
something
because
this
is
very
concrete
to
the
API
right.
So,
for
example,
let's
say
other
people
is
using
CLI
tools,
for
example
parallel.
If
you
don't
creates
a
different
persona
for
that
you
know.
So
so
do
you
see
room
for
creating
new
personas?
You
are
always
just
I,
don't
remember
the
name
like
kind
of
developer,
Persona
or
like
or.
D
A
Gavin
yeah
I
think
that
this
will
accent
are
existing
personas
I've
noticed
in
in
some
of
the
personas
that
we
have
today
that
yeah
we'll
talk
about
tools,
for
example,
tools
that
these
types
of
personas
are
also
using
for
their
to
do
their
day-to-day
work.
To
me,
I
think
that's
kind
of
like
accenting
the
Persona
to
explain
kind
of
what
is
relevant
in
terms
of
Integrations.
So
that's
that's
interesting
input
for
from
an
integration
standpoint,
I
I,
say
something
similar
happening
from
an
API
standpoint.
There
could
be
a
case
I.
Think.
A
One
thing
that
maybe
isn't
captured
today
is
the
use
case
of
the
of
the
partner.
So
you
know
if
there
are
third
parties
that
want
to
leverage
your
apis
to
build
Integrations
or
if
we
have
the
the
third
party
maintainer,
you
know
maintaining
a
library
or
an
SDK,
I
I.
Don't
think
that's
really
capture
on
personas
today,
so
that
that
could
be
something
I'm,
not
sure.
A
You
know
how
we'd
want
to
treat
it,
but
I
think
that
through
this
process
you
know
we
can
really
narrow
down
the
types
of
personas
we're
seeing
and
see
how
they
overlay.
On
top
of
what
we
have
today,
I,
don't
know
what
the
next
step
would
be
if
we
needed
I
think
if
we
needed
to
add
personas,
there's
kind
of
a
rigid
process
today
for
how
we're
supposed
to
approach
that
so
I
wonder
if
there's
kind
of
like
a
subset
somewhere,
we
can.
A
We
can
reference
these,
at
least
in
internally,
as
we
move
forward
to
start.
You
know
as
a
starting
point
but
open
to
input
on
that
as
well.
A
You
have
any
thoughts
on
that
Tim
since
you
happened
to
drop
in
today.
C
A
Okay,
yeah
no
worries
all
right.
Thanks
I
guess
we
can
move
on
to
the
next
point.
D
A
The
call
today
she
wanted
to
leave
us
a
an
FYI,
so
she
created
an
issue
for
the
docs
epic
to
think
about
things
that
we'll
need
for
automated
API
docs
such
as
special
formatting.
So
we
can
keep
parity
with
the
handcrafted
docs,
so
Axel
and
Evan
have
been
helping
with
input.
No
action
is
needed
from
anyone
here
today,
but
hoping
this
will
help
guide
future
iterations
for
API,
docs
automation,
so
yeah.
That's,
that's
awesome.
I
really
appreciate
you
Katie
for
taking
the
lead
on
that.
Keep
us
posted.
A
Oh
I
have
the
next
item
as
well,
so
I
didn't
want
to
forget
this.
A
We
had
a
discussion
and
I
can
pull
in
the
slack
thread
link
as
well
here
once
I
find
it,
but
we
were
discussing
there's
interest
from
the
maintainer,
the
gitlab
library,
for
get
lab
to
take
ownership
of
this
from
an
Integrations
team
standpoint,
I
think
from
API
working
group
standpoint,
I
think
we've
been
at
least
myself
been
a
little
bit
hesitant
based
on
capacity
to
do
this
in
the
immediate
term
short
term,
but
I
would
like
to
see
a
gradual
process
to
where
we
can
start
to
get
involved.
A
I
know
in
this
particular
case
the
maintainer
is
no
longer
using
go,
get
live
themselves,
it's
a
bit
of
a
challenge
to
support
and
maintain
some.
So
in
the
the
slack
thread
we
talked
about,
maybe
having
some
kind
of
model
of
getting
gitlab
a
little
bit
more
involved,
bringing
maintainers
into
the
the
repo,
maybe
getting
a
little
bit
more
familiar
as
a
starting
point.
I
think
that
would
be
you
know
a
pretty
good
fit
so
definitely
open
to
feedback
on
that.
C
Yeah
I
think
it's,
it's
always
the
tough
one,
because
everyone
will
expect
more
if
we,
as
an
organization,
are
taking
care
of
stuff
compared
to
a
loan
person
who
is
doing
a
small
mini
Library.
So
if
we
are
moving
forward
with
this,
and
if
we
are
deciding
to
do
this
Kai
is
for
sure
I
would
say
the
best
candidate
take
to
talk
to,
because
he
has
done
this
for
the
vs
code,
plugin
back
then,
and
the
CLI,
and
so
he
knows
about
all
the
different
Hops
and
Hoops.
A
Good
good
point:
yeah
I'll,
definitely
keep
that
in
mind.
I
did
speak
to
Kai
sometime
back
just
at
that
time.
I
was
thinking
of
it
more
in
terms
of
like
what
do
we
need
to
validate
before
we
you
know
we
took.
We
take
something
on
like
this
and
not
really
considering
you
know
more
of
a
middle
ground
of
just
like
getting
more
familiar
rather
than
fully
taking
on
ownership.
So
yeah.
If
there
are
some
legal
implications,
I
can
definitely
explore.
A
You
know
kind
of
that.
What
that
gradual
process
looks
like
yeah
good,
good
point.
B
So
you
have
a
question
about
the
general,
a
strategy
that
we
want
to
take
here
at
Guild
lab,
because
supporting
different
libraries
could
be
a
lot
of
work
and
supporting
this
one
with
Go
I
mean
could
be
a
good
idea,
but
are
we
planning
to
support
another
for
Ruby
another,
for
you
know
main
languages,
so
the
the
thing
that
I
see
is
like
if
we
take
on
a
strategy
that
is
like
okay,
let's
go
and
build
up
his
officially
supporting
the
main
languages
or,
let's
say
five
languages.
B
B
You
know,
because
probably
we
don't
have
the
capacity
and
if,
if
it's
only
one
thing
is
going
to
be
kind
of
weird
as
well
right
like
why
this
I
need
not
this
other
language,
so
yeah,
so
in
general,
I
think
that
we
have
to
take
more
like
up
level
decision.
You
know
before
going
to
concrete
things
in
this
case
this.
This
is
my
opinion
at
the
moment,.
A
Think
the
difference
in
this
case
is
that
there's
a
quite
a
large
amount
of
usage
today
that
that
is
driven
through
go,
get
lab
in
terms
of
our
API
usage
and
the
fact
that
in
this
case,
there's
only
a
single
maintainer
and
for
whatever
reason,
they've
been
unwilling
to
to
to
allow
others
to
to
take
ownership
in
terms
of
being
a
maintainer
like
collaborating
as
maintainers,
so
he's
kind
of
been
covering
it
entirely
by
by
himself,
and
he
no
longer
needs
it
or
uses
it
today.
A
So
I
I,
don't
know
about
the
the
long-term
ownership
piece.
I.
Think
a
starting
point
is
that
it
would
be
helpful
to
get
familiar
with
it
have
get
a
lot
of
maintainers,
supporting
without
necessarily
owning
and
and
being
able
to
kind
of
fill
the
the
pain
that
third-party
maintainers
may
feel
when
using
your
apis.
A
So
it's
definitely
a
way
to
get
some
exposure
and
and
definitely
we'd
want
to
set
expectations
that
this
isn't
necessarily
something
we're
we're
trying
to
do
at
scale
today,
to
support
multiple
languages
and
for
multiple
libraries
and
sdks
I
think
that
this
would
be
a
pretty
limited,
set,
the
limited
scope
and
and
again
I,
don't
know
about
I
think
rather
than
committing
to
ownership.
It
would
be
more
so
short-term.
A
You
know
getting
access
as
maintainers
reviewing.
What's
there
and
providing
guidance
rather
than
committing
to
us,
you
know
set
capacity
and
owning
it
long
term,
at
least
for
now.
So
that's
where
my
head's
at
right
now
is
like.
Is
there
a
middle
ground
to
where
we
can
start
to
get
some
exposure
here
and
maybe
maybe
there's
a
better
smaller
step
with
fewer
implications?
So
that's
definitely
something
I'm
open
to.
We
could
also,
just
you
know,
start
without
maintainership,
just
reviewing,
what's
there
and
and
getting
more
familiar.
A
So
maybe
there's
a
that's,
maybe
an
even
more
tangible
small
step
we
could
take.
D
B
Yeah
I
mean
I
can
understand
the
point
like
to
to
have
more,
like
closer
relationship,
not
maybe
be
maintainers
of
of
those
tools.
But
another
thing
is
that
also
we
need
to
find
the
right
people
in
the
company
because
a
this
is
go
and
we
have
some
people
in
the
company,
but
the
interactions.
For
example,
we
we
don't
have
any
I
think
we
don't
have
any
engineer
that
they
are
like
an
expert
on
go.
B
You
know
so
so,
for
example,
if
I
have
to
make
a
commitment
here
like,
are
we
going
to
be
able
to
support
this
external
Library
for
an
interactions?
I
would
say
we
we
are
not
going
to
be
able
to
know,
because
we.
B
Skills
right
now,
maybe
we
can
give
some
feedback
or
contribute
to
smaller
things.
You
know,
but
at
the
end,
if
we
are
not
experts,
please
also
take
up
take
a
US
time.
You
know
to
skill
up
as
well
so
yeah,
so
so
we
we
also
have
to
find
the
right
people
in
the
company
also
to
give
that
support.
Okay,.
A
Yeah,
that's
a
good
point.
Would
it
make
sense
to
create
an
issue
exploring
yeah,
there's
kind
of
short-term
step,
because
I
know
we
have
a
few
issues
that
are
talking
about
owning
and
maintaining
the
entire
Library
from
a
gitlaw
perspective,
but
maybe
we
could.
We
could
create
an
issue
and
see
if
we
can
identify
those
those
folks
in
GitHub
who
would
be
interested
because
I
know
there's
interest.
I
know
there
are
people
that
would
like
to
do
this
already
so
I
don't
know.
B
Yeah
I
think
so,
and
there
is
also
a
slack
Channel
golang.
So
you
know
in
order
to
distribute
that
issue,
you
know.
Probably
this
is
the
place
to
go.
Okay.
C
A
B
Go
for
it
yeah
next
point:
I
have
the
next
point
that
I've
been
thinking
about
this
and
basically
I
mean.
Today
we
have
Team
here
so
I'm,
going
to
give
a
a
little
bit
more
of
context,
but
basically
you
can
see.
B
We
are
missing
a
lot
of
people
from
the
initial
working
group
these
two
days,
especially
normally
we
have
more
people
like
Alex
Andy,
but
Fabio
as
well,
but
you
know
today
is
especially
low,
but
basically
we
were
not
making
progress
as
much
as
we
we
want
on
the
group
and
at
some
point
we
Define
different
dris
for
the
its
exit
criteria.
B
So
that
way,
it's
like
okay,
I
expect,
like
you
know,
it's
dri
is
going
to
maybe
make
progress
on
that
or
or
coordinate
with
others
in
order
to
make
progress,
or
even
maybe
just
refined
issues.
You
know
to
about
every
two
weeks.
I
want
to
see
some
progress
and
I.
B
In
my
case,
for
example,
I
was
not
contributing
that
much
I
mean
I
was
facilitating,
but
now
I'm
the
dri
of
one
easy.
That
is
the
the
learning
paths
and
and
content
today
to
contribute
to
the
API
and
now
every
two
weeks,
I'm
making
sure
that
I'm
making
priorities
you
know
and-
and
the
question
they
have
is
helping
question
here-
is
like
I'm
thinking,
okay,
the
moment
that
maybe
we
finish
this,
maybe
I,
don't
know
in
two
months
a
because
there
are
like
Christmas
time
and
things
in
two
months.
B
Because
boyan
is
helping
me
here
so
I'm
thinking,
okay,
what
happened
if
we
go
not
that
in
parallel,
but
we
try
to
go,
go
more
as
a
group
at
Exit
criteria
after
it
SC
criteria.
You
know
we
go
and
say:
okay,
we
have
to
improve
the
documentation.
Let's
work,
everyone
do
not
together
on
the
documentation,
and
maybe
people
is
more
focused
on
that,
rather
than
you
know,
work
more
in
parallel,
because
I'm
not
sure
if
that
is
working
at
the
moment.
But
it's
just
an
idea.
B
C
I
I
will
take
a
look
at
it.
Maybe
we
can
also
facilitate
it
through
a
specific
project
so
that
we
have
better
organization
in
detail
with
assigned
issues
per
person
and
per
Stream
So
that
we
have
overview
there,
but
I
can
definitely
see
that.
Sometimes
it's
easier
that
everyone
focuses
rather
on
one
topic
gets
that
done,
never
thinks
about
it
again
and
then
we
go
over
to
the
next
topic.
I
would
like
to
understand
a
little
bit
better.
A
Yeah
I
would
say
in
general,
I
think
that
makes
sense.
I
I
think
that
the
challenge
has
been
work
like
dris
that
are
focused
on
these
tasks.
Like
you
mentioned,
Arturo
I
think
it's
just
that
we
we
all
have
day
jobs
as
well.
So
you
know
when
Milestone
planning
comes
up
for
me.
You
know,
that's
that
pulls
me
away
from
these
issues
and-
and
the
same
goes
for
like
various
deadlines
from
the
engineering
standpoint.
So
it's
definitely
understandable.
A
I
think
the
one
caveat
I
see-
or
maybe
it's
just
in
terms
of
like
how
we
would
order
the
work
is-
we've
been
I
I
think
a
little
bit
stalled
in
how
we
want
to
approach
the
rest
versus
graphql
question
like
how
we
want
to
simplify
the
user
experience
for
our
developer
personas
using
our
apis
who
depend
on
rest,
for
example,
but
reduce
maintenance
internally
in
terms
of
how
we
manage
these
two
different
apis
and
and
the
the
kind
of
the
Cornerstone
issue
that
we've
been
working
against.
A
Is
this
rest
over
graphql
POC
and
the
engineering
implementation
of
that?
The
next
steps
of
that
are
just
mostly
blocks
because
our
own
team,
the
Integrations
team,
is,
is
what's
working
and
we're
the
ones
working
on
it
primarily
and,
and
we
have,
we
have
priorities
that
that
are
kind
of
taking
precedent.
So
I
think
you
know
it
feels
like
once.
We
have
at
least
a
determination
on,
if
that's,
if
that's
a
workable
solution,
moving
forward
yeah
that
helps
us
to
to
kind
of
figure
out
where
we're
going
with
next
steps.
A
If
I
I
say
that
I
think
that's
one
of
the
main
issues,
I
think
the
other
is
considering
what
falls
in
like
a
V4
versus
V5,
rest
API
and
the
implications
between
rest
and
graphql
there.
So
so
those
are
the
big
hard
questions
to
answer.
It
does
require
some
engineering
effort
and
then
from
there.
I
think
we
want
to.
A
You,
know
really
more
so
have
a
defined
plan,
we're
not
trying
to
implement
everything
within
the
working
group,
but
these
are
kind
of
questions
that
require
engineering
effort
to
answer
so
yeah
again,
I
think
I'm
agreeing
with
you,
and
maybe
it's
just
the
order
in
terms
of
what
needs
to
happen.
First,
it
seems
like
those
are
the
big
kind
of
blocking
questions
about
how
the
next
Things
fall
in
place.
A
One
last
thought
that
comes
to
mind
is
also
the
automated
docs
generation.
We
kind
of
started
to
prioritize
that,
because
it
is
low
hanging
fruit,
there's
a
lot
of
value.
Add
a
lot
of
customers
asking
for
this
third-party
maintainers
asking
for
this
and
then
internally
we
have
we've
had
the
federal
pressure
for
that.
So
it's
just
seemed
logical
to
work
on
that
immediately,
but
I
don't
think
anything's
been
driving
necessarily
the
other
priority.
That's
that's
all
very
well
interconnected.
A
So
it's
been
I
think
a
bit
of
a
challenging
working
group
in
that
respect,
because
these
are
Big
lofty
questions.
We're
trying
to
answer
I
think
I
think
that
everyone's
been
really
contributing
the
best
they
can
it's
just.
It
can
be
slow
going
at
times,
so
so
yeah
I
think
Tim.
Anything
you
mentioned
recommunicating.
The
working
group
I
think
definitely
having
more
cross-functional.
A
Support
would
really
help
here
because
it
does
fill
that
the
Integrations
team
is
carrying
the
burden
a
bit
and-
and
we
don't
want
that-
I
mean
we
do
want
to
when
we
want
to
share
this
with
others
that
are
invested
in
in
the
decisions
we're
making
here.
C
Yeah
I
think
that
one
topic
that
we
definitely
could
do
is
also
take
a
look
if
we
basically
bundle
up
a
package
to
say:
okay,
this
is
how
we
envision
and
that's
the
work
that's
needed
to
get
us
to
a
level
of
rest
over
graphql.
That's
the
amount
of
work
that
we
are
expecting
and
that's
the
output.
C
This
is
what
Integrations
will
be
working
on
slack
integration
as
soon
as
their
first
MBC
round
is
done.
First
version
is
done
boom.
We
are
going
to
invest
half
of
the
team
on
this
topic,
but
I
think
it
needs
to
be
in
a
very
clear
and
precise.
Okay.
That's
that's
what
we
can
do,
that's
what
we
want
to
do
and
that's
the
benefit
that
we
can
get
from
and
I
think
this
might
be.
C
Something
really
December
is
funky
generous
funky,
but
it
might
be
really
now
the
time
that
we
prepare
this
to
have
this
ready,
that
we
have
something
actionable
for
q1
and
say:
okay,
we
are
going
to
execute
with
Integrations
team,
Integrations,
plus
team,
x
members
or
just
another
team
and
so
on,
but
basically
that
working
group
is
suggesting
a
plan
forward
and
that
we
really
take
this
on
on
a
different
level
to
get
this
buy-in
from
others.
A
Agreed
I
mean
I,
think
there's
a
lot
of
questions
and
comments
that
are
coming
to
mind
around
that.
But
I
think
that
is
the
ultimate
goal
is
that
we
have
this
package
to
take
to
share
that.
These
are
our
plans.
You
know
as
a
result
of
our
work
in
the
working
group
and
then
at
that
point
you
know
we
kind
of
would
close
out
the
working
group,
and
maybe
there
would
be
some
continued
discussion
or
format,
but
it
would
no
longer
be
a
working
group.
A
I
think
that
you
know
some
of
the
core
questions
we
wanted
to
Come
Away
with
some
answers
from
from
pocs
before
we
determine.
A
Forward
so
that
was
the
goal
first
and
then
we've
also
on
the
Integrations
team,
updated
our
direction
to
focus
more
on
apis
and
web
Hooks
and
tooling
for
building
Integrations,
whether
you're
an
internal
product,
team,
external
customer
or
partner,
that
that
we
can
help
kind
of
accelerate
the
process
of
building
Integrations
and
improve
the
experience
of
using
our
apis.
A
So
we
we
are,
as
a
team,
wanting
to
focus
our
effort
more
in
this
area
and
and
we
are
working
on
completing
some
work
around
slack
grn
servicenow
before
we
we
make
that
that
full
shift
so
and
then
the
line
where
that,
where
we
draw
that
I
think,
is
still
a
little
bit
in
flux
and
then
the
other.
The
other
thought
that
comes
to
mind,
too,
is
just
noting
that
I
have
seen
an
MR
and
some
discussion
around
a
core
core
platform.
A
Team
I
think,
is
the
the
terminology
so
kind
of
understanding
the
boundaries
of
that
I
think
would
be
helpful
as
well,
because
I
know
that
this
is
something
that
we're
we're
moving
our
focus
and
card
Direction
into
and,
and
there
might
be
some
some
shared
aspects
or
some
similar
aspects
to
what
they're
hoping
to
address
so
definitely
I
think
it
helps
to
have
you
here
Tim
and
have
have
your
involvement
support,
as
we
kind
of
figure
this
out,
because
yeah
understand
the
shape
of
that
package
and
aligning
with
you
I
think
would
be
really
meaningful.
B
Yeah
one
thing
is
they
they
I
I
can
compare
this
with
other
working
groups,
and
the
scope
of
these
working
group
is
huge
compared
like
maybe
it's
exit
criteria
could
be
a
working
group.
You
know
so
just
improve
the
documentation
is
like
automating,
hey,
Styles
different
things
can
could
be
a
working
group.
Do
you
know
that
they
are
working?
Something
then,
if
you
take
like
every
different
exit
criteria
is
like
the
scope
is
huge,
so
I
think
that
we
are
also
striving
with
that,
but
yeah
good
points
yeah.
Thank
you
very
much.
A
And
and
one
thing,
I'll
share
real,
quick
too,
as
as
well
Tim
I
have
an
issue
trying
to
hunt
down
well.
First
I'll
share
a
link
to
our
board
because
you're
kind
of
talking
about
a
different
project
I
think
our
board
is
pretty
well
structured.
That
is
pulling
any
each
of
the
issues
and
we
have
you
know
each
of
the
status
or
States.
So.
A
And
then
I
do
have
an
issue
where
we're
kind
of
like
I
was
trying
to
start
to
shape
what
this
package
would
look
like
as
far
as
like
the
proposal
and
I'm
just
having
trouble,
locating
it,
but
I
think
that
would
be
a
good
place
to
start.
I
think
that
we
were.
A
It
was
kind
of
on
pause
as
we're
working
on
some
of
these
pocs
and
answering
some
of
the
big
questions
about
how
this
should
look
moving
forward,
but
I
think
once
I
find
this
issue
I
think
it's
a
good
starting
point
to
get
a
sense
of
what
we
were
thinking
and
just
knowing
that
it
could
change
here.
It
is.
We
marked
it
as
closed.
A
D
A
And
Arturo
yeah
see
you
close,
we
promoted
static,
that's
why
I
couldn't
see
it
in
that
board,
because
it's
an
epic,
so
I'll
update
the
link.
A
Yeah,
if
you
have
any
questions
or
thoughts,
feel
free
to
jump
into
that
issue
Tim
or
feel
free
to
share
it
again,
it's
a
it's,
a
draft,
we're
still
still
learning
and
exploring,
but
I
think
this
kind
of
summarizes
some
of
what
we've
been
kind
of
coming
away
away
with
in
this
working
group.
C
Good
then
I
will
put
this
on
my
to-do
list
for
this
week
and
we
basically
move
forward
to
shape
this
up
and
I
will
start
preparing,
Christopher
and
David
that
we
are
going
to
propose
like
a
a
bundle
and
I
think
that
the
important
part
is
that
we
cut
some
parts
away
and
say:
okay.
This
is
perfect
work
for
Integrations
team,
many
how
this
is.
C
This
is
a
simply
prepared
and
suggested
by
the
working
group,
and
there
might
be
simply
something
topics
where
we
need
additional
support
from
team
members
of
the
working
group,
and
this
is
also
something
that's
what
I
mentioned
to
over
communicate
again
to
team
members.
Whoever
is
interested,
we
have
a
lot
of
new
team
members
since
we
started
they
might
be
totally
not
aware
they
might
have
completely
different
backgrounds
so
that
we
get
more
people
in
and
then
we
basically
say.
Okay,
we
don't
say
we
need
team
X
for
this
from
group.
Why?
C
But
rather
this
individual,
who
is
part
of
the
working
group
and
get
simply
their
work
for
a
month
to
focus
right?
One
percent
on
this
and
get
this
moving
so
that
we
have
this
combination
combined
effort
of
people
who
are
really
interested,
which
is
always
a
huge
motivation.
Boost
and
I,
have
already
the
full
insight
to
this
topic.
So
this
is
definitely
something
that
I
can
ask
for
and
but
the
better
we
are
prepared
in.
C
Okay,
that's
what
we
get
out
of
all
of
it,
the
more
the
higher
our
success
rate
will
be,
but
yeah
cool
I
will
put
this
on
my
to-do
list
to
read
through
and
work
myself
through
the
items,
and
then
I
was
following
in
the
slack
Channel
anyhow,
but
yes,
definitely
great.
That
I
have
now
highlighted
topics.
A
Yeah
that
would
be
awesome
and
feel
free
to
reach
out
to
me
if
you
want
to
chat
some
more
or
if
you
have
questions
happy
to
to
chat
and
John.
Thank
you.