►
From YouTube: Service APIs Office Hour 20200812
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
All
right
welcome
to
office
hours
for
service
apis
on
august
12..
I
added
a
lot
to
the
agenda
today.
I
somehow
doubt
we'll
make
it
through
all
that,
but
that's
fine.
We
can
always
push
some
to
tomorrow,
but
I
guess
since
we're
getting
close
to
v1
alpha
1,
we
might
as
well
take
a
look
at
this
to
start
off
every
every
call,
I
think
we're
making
good
progress
here.
A
Although
we
didn't
move
anything
down
this
week,
I
think
we've
made
thanks
to
harry
some
great
progress
on
tls
config
advanced
routing,
but
we
I'm
not
as
familiar
with
where
you
are
on
service
level
config.
I
know
that
I
know
there's
a
doc
here,
but
I
I'm
not
sure
if
it's
been
updated
recently.
A
All
right:
well,
we
can
come
back.
James,
isn't
here
to
talk
about
status
and
conditions
and
well
actually,
while
I'm
thinking
about
it.
Let
me
go
ahead
and
link
these
two
together,
because
I
have
made,
I
think,
decent
progress
on
conflict
handling
or
we
have
made
decent
handling
and
conflict
handling.
But
I've
left
that
until
closer
to
the
end
of
today's
meeting
but
yeah
okay.
So
I
think
I
think
these
are
all
moving
forward
and
we'll
leave
it
at
that.
A
For
now,
I
actually
got
some
great
feedback
on
this
pre-alpha
api
review
and
I
did
update
it
today,
so
this
should
be
should
represent
the
current
status
of
our
api.
A
A
I've
tried
to
highlight
some
of
them
in
the
actual
agenda,
but
I
didn't
get
all
of
them
so
if
you're
interested
feel
free
to
read
through
I'm
hoping
we'll
get
some
more
reviewers
as
well
as
time
goes
on,
but
yeah.
I
thought
I
thought
this
initial
round
was
very
helpful.
A
There's
this
fun
one
that
dan
brought
up
that
conditioned
no
such
gateway
class
doesn't
really
ever
make
sense
or
not
that
I'm
aware,
because
it's
it's
not
like,
there's
going
to
be
a
single
controller
responsible
for
implementing
this
I
mean
I
I
don't.
I
don't
even
know
how
this
we're
imagining
a
world
where
there
are
potentially
multiple
controllers
implementing
gateway
class
so
which
one
would
be
responsible
for
this.
It
seems
like
a
really
potentially
unhelpful,
well
obscure,
maybe
an
unclear
status
condition,
so
my
theory
would
be
that
it
should
be
removed.
A
All
right,
so
we
default
this
to
on
and
then
yeah
okay.
I
remember
that
now,
okay,
so
this
would
be
admission,
controller
or
mutating
web
hook,
depending
on
what
component
like
it
sounds
like
we'll
already
have
a
mutating
web
hook,
which
I
think
could
accomplish
this,
but
in
mission
controller
yeah,
some
link
in
that
space
that
makes
sense
and
then
finally,
the
gateway,
spec
go
doc,
hasn't
been
updated
to
match
the
new
structure.
I'd
missed
that
previously,
but
that
was
a
good
catch
by
dan
in
in
here
somewhere.
A
There
there's
a
few
other
things,
but
those
are
those
were
the
things
I
thought
more
interesting
and
worth
highlighting.
There
are
more.
D
C
In
the
http
host
in
the
http
host
structure
yeah
there,
if
you.
A
C
Yeah
so
his
his
point
was
here:
it's
weird:
it
has
the
same
semantics.
A
A
All
right
so
encourage
anyone
to
to
take
a
look
here,
if
anything
seems
larger,
and
I
haven't
already
captured
it
here.
I
encourage
just
a
a
follow-up
issue
on
the
repo
itself
yeah,
so
I
just
wanted
to
highlight
briefly
the
things
that
actually
made
it
in
the
past
week.
There's
a
typo
fix
an
http
route.
A
The
default
route
match
type
is
finally
prefix.
Thanks
drop
the
default
host.
That's
great,
I
think,
and
then
move
tls
minimum
version
outside
of
being
a
core
field
into
just
options.
Well,
as
in
it
could
be
specified
in
options
and
then
reordering
the
make
targets
by
damian.
So
some
some
good
progress
here,
but
I
think
we
have
a
lot
of
bigger
pr's
that
are
currently
in
progress
that
I'd
like
to
get
in
soon,
and
so
that
brings
us
to
pr
and
issue
triage.
A
This
is
not
an
exhaustive
list,
but
I
think
these
are
the
most
recent
ones.
As
always,
if
you
see
your
pr
or
issue
isn't
on
this
list,
feel
free
to
add
it
to
this
list
at
any
point
and
we'll
get
to
it,.
A
E
Know
it
makes
sense,
I
just
yeah,
we
just
need
to
make
sure
it
doesn't
get
out
of
sync
or
something.
A
A
C
Okay
harry,
would
you
mind
updating
when
you
that
go
doc
with
your
comment
there
just
to
make
it
explicit
that,
if
that
the
rule
won't
match,
if
there's
and
an
empty
http
route
rule
doesn't
match
any
request.
C
Cool
thanks,
I
just
had
the
same
because
there
is
on
the
http
route
match
object.
It's
the
same
thing.
A
Okay,
so
that
means
that
you
would
have
to
specify
a
match
of
path:
yeah,
yeah;
okay,
that's
fine!.
E
A
E
E
A
All
right,
the
next
one
was
also
from
harry.
This
is
hp
route
filter.
I
know
this
had
a
decent
amount
of
comments
on
this
already,
I'm
just
trying
to
remember
the
current
status
of
this.
I
think
you've
resolved
most
most
comments
and
discussion
at
this
point
right,
harry.
B
E
I
just
I
I
think
it's
it's
going
to
be
hard
if
we
say
it's
part
of
the
staple
api
to
not
actually
have
it
in
there.
I
can't
true
the
struct
will
get
big.
E
A
A
Let
me
go
over
to
the.
A
A
E
Feels
like
it
is:
okay,
oh
no
pulling
it
up
to
the
top
means.
We'd
have
to
talk
about
it
as
a
group
anyways,
because
we'd
have
to
talk
about
sort
of
things
happening
and
either
modifying
the
request
or
response.
A
Yeah,
I
think
one
key
bit
is:
if
this
were
top
level,
you
a
list
might
make
sense
if
this
were
not
top
level
like
this
is
a
list
within
a
list
right,
so
you
could
probably
make
this
not
a
list.
You
could
have
a
request,
headers
that
allowed
you
to
add
or
remove,
and
you
could
put
multiple
of
those
transformers
or
whatever
we
want
to
call
them
in
a
row
instead
of
having.
A
Yeah
yeah,
I
guess
I
guess
it
depends
on
on
how
on
on
the
use
case
here
right
like
if,
if
filters
are
meant
to
be
sequential
or
whatever
we
end
up
calling
this
concept,
then
you
know
if
it
were
possible,
you
may
want
to
add
a
filter
perform
some
other
kind
of
action.
Like
add
a
header
perform
some
kind
of
action
and
then
remove
that
header.
This
seems
like
a
real
stretch,
but.
A
B
The
simpler
case
for
at
least
the
core
api
people
can
still
use
it.
People
can
still
specify
multiple
filters
with
you
know,
even
in
this
form
right
like
because
the
filters
itself
is
a
list
and
then
they
can
not
send
to
that,
but
that
won't
be
supported
by
most
implementations
right,
like
a
specific.
E
Yeah,
I
think,
like
the
most
implementation
is
having
multiple
of
those
is
just
probably
is
an
error.
B
A
Yeah,
okay,
that
that
works.
So
then,
this
this
suggestion
is
really
just
a
slight
rename.
E
B
B
E
B
E
E
So
let's
get
this
pr
in
and
then
we
can
talk
about
sort
of
the
names
independently,
because
that
thing
will
just
be
a
pr
and
if
it's
just
renaming
it,
if
we
rename
it.
B
C
Okay,
one
thing
with
this
pr
I'm
skeptical
about
is
that
it
will
gracefully
extend
to
more
filters
so,
and
I
think
the
nature
of
the
filter
concept
is
you
have
lots
of
possibilities
right
so
because
filters
is
this
generic
thing
you
go
well,
I
want
a
field
to
do
this.
This
this
this
say
say
we
end
up
with
like
seven
or
even
seven
or
eight
filters
like
what
would
that
look
like
in
in
this
filter
struct.
C
Does
it
end
up
with
you
know
a
field
each
has
its
own
struct
field
in
there,
or
do
we
end
up
with
like
cid
just
using
the
cid
stuff?
So
I
think
that's
my
concern
around
this.
E
C
B
But
there
is
no
like
we
had
a
config
which
was
removed,
which
was
similar
to
the
raw
extensions
thing,
but
we
removed
that,
for
I
think
a
very
good
reason
was
we
want
the
same
same
semantics
everywhere
we
have
like
extensions
everywhere.
We
don't
have
like
a
raw
extension
anywhere
so
yeah
I
mean
I
totally
hear
you
james.
The
only
thing
is
like
which
trade-off.
Do
we
make
in
the
either
of
two
proposals
that
you
have?
E
They
definitely
have
to
appear
here
and
I
would
I
would
not
like
to
have
to
require
people
to
use
crds
just
to
do
those
things
for
something
as
simple
as
header
manipulation
to
be
fair,
like
eventually,
this
thing
will
kind
of
grow
a
lot,
but
in
some
sense
that's
unavoidable,
because
you
have
a
lot
of
choices.
Anyways
and
if
you
split
them
into
crds,
the
this
struct
will
be
small,
but
the
list
of
crds
actually
is
pretty
hard.
And
then
you
don't
get
any
type
guidance.
When
you
let's
say
you
use
some
autocomplete.
B
B
Yeah
yeah,
so
you
have
a
union
discriminator
which
is
like
you
know
the
discriminator
itself,
and
you
have
like
these.
One
of
these
trucks
can
only
be
said,
so
we
have
the
larger
filter,
struct
and
inside
those
all
the
core
or
extended.
Filters
will
have
like
a
struct
for
like
the
configuration
of
it,
which
can
be
inline
and
the
open
api
cube
like
format
or
validation
inside
crd,
takes
care
of
like
making
sure
that
the
user
sits
only
one
of
those
yeah.
A
That
makes
sense
I
mean
my
my
take
on
this-
is
that
it's
it
is
not
ideal,
but
it
feels
like
the
best
option.
We
have
right
now
to
allow
these
kind
of
custom
filters
or
actions
in
the
sense
that
core
capabilities
can
be
represented
as
trucks
and
extended
ones
can
be
represented
as
references
to
crds.
A
It's
not
ideal,
but
I
think
that's
probably
sufficient
for
v1
alpha
1,
and
maybe
there
will
be
some
great
movement
in
the
community
or
whatever
to
support
better
ways
of
doing
this.
I
don't.
D
D
B
C
I'm
not
sure
that
cids
will
be
all
that
attractive
to
implementers,
but
it
is
how
we've
extended
other
things.
A
I
mean
it
does
depend.
You
know
that
that
could
potentially
be
helpful
if
you
have
some
generic
filters
that
can
be
represented
as
crds
that
you
want
to
use
across
multiple
routes.
This
could
actually
be
a
positive,
but
you
know
it
depends
so
much.
Maybe
it
would
be
helpful
to
to
spend
a
bit
more
time,
thinking
through
or
gathering
a
list
of
potential
custom
filters
and
understanding
how
that
might
work
here.
E
Yeah,
let's
we
have
to
see
also,
this
is
the
alpha.
It
feels
like
the
most
natural
from
user
writing
stuff,
although
it's
not
helpful
for
validation
is
going
to
be
the
raw
extension
the,
although
we
should
see
how
terrible
the
crd
option
is,
given
that
it's
the
most
well
typed.
A
Yeah,
which
was
my
on
my
request,
suggestion
whatever,
because
I
thought
well:
okay,
there's
three
different
ways
to
do
things
here.
We
should
probably
get
rid
of
at
least
one
of
them,
but
you
know
that
the
the
the
map
string
string
is
great,
but
it
does
mean
you
lose
all
validation.
You
lose.
You
know,
I
guess
it's
the
same
thing
with
the
raw
extension
you,
you
lose
the
benefits
of
a
crd,
but
you
also
lose
the
all
the
overhead
of
crd.
So.
E
C
As
far
as
I
can
tell,
I
I've
seen
it
like
the
tess
operator
uses
it.
It's
the
only
thing.
I've
ever
seen
found
it
the
only
place.
I
could
find
it
and
I
couldn't
find
a
yamaha
example.
It
looks
I
from
the
description.
I
think
it's
you
basically
in
line
a
whole
cid
like
including
the
api
group
and
kind
which
interesting,
which
doesn't
seem
like
quite
what
we
want.
It
doesn't
seem
like
quite
what
we
want
here.
C
So,
if
I
think
about
what
I
would
in
the
absent
in
in
a
perfect
api,
if
I
had
everything
I
want.
E
C
The
api
server,
what
I
would
want
from
this
kind
of
api
is
the
type
name
which
could
be
a
kind
name
and
a
raw
extension
which
the
api
server
would
know
how
to
validate,
because
it
would
dynamically
match
against
the
kind
name,
that's
kind
of
what
I
would
ultimately
that's
kind
of.
Ultimately,
what
feels
like
the
right
option
here.
It's
like.
I
want
the
raw
extension,
but
I
want
it
with
validation,
which
is
associated
by
the
type
name.
C
Yeah
sort
of
yeah
almost
and
I
think,
embedded
resource
is
almost
there,
except
instead
of
except
instead
of
just
raw
extension.
You
need
to
put
like
the
whole
thing,
so
you
you
would
need
to
put
the
api
version
and
kind
and
then
the
whatever
the
fields
are
for
the
crd
in
there
too,
there's
basically
in,
I
think
it's
in
it's
basic.
I
think
it's
basically
in
lining
a
cid
resource.
A
And
like
it
still
does
feel
helpful,
and
I
guess
I
guess
we
don't.
At
least
I
don't
completely
understand
all
the
potential
use
cases
here,
but
you
know
like
authentication
or
some
other
common
filters.
It
does
seem
helpful
to
have
a
single
crd
that
defines
how
that
works
and
just
okay.
I
want
this
specific
plugin
to
operate
this
way,
pluginism
filter
whatever
it
is.
A
That
seems
useful
in
the
sense
of
a
proper
crd
ref,
but
I
realize
other
filters
here.
Other
plug-ins
here
are
going
to
be
more
specific
to
a
a
a
specific
route,
but
I
I'm
having
a
hard
time
picturing
exactly
what
those
might
be
where
you
really
want.
The
inline.
E
C
I
can
totally
get
on
board
with
merging
this,
as
is
with
the
under
with
the
intention
to
revisit
on
the
next
on
the
next
version.
A
Yeah,
I
think
at
this
point
that
would
be
my
preference
as
well
just
in
the
sense
that
this
feels
like
a
a
good
starting
point
and
the
two,
the
two
things
we
have
defined
right
now.
A
I
think
we'll
likely
want
to
keep
the
idea
of
referencing
a
crd
and
the
idea
of
an
internal
struct
or
set
of
structs
that
we
can
use
that
are
core
and
maybe,
in
the
future,
instead
of
referencing
a
crd,
we
can
embed
one
even
better,
but
that's
a
relatively
minimal
api
change
that
I
think
could
be
backwards
compatible
or
you
know,
at
least
at
least
there's
a
clear
upgrade
path.
E
Okay,
yeah,
like
I
think
we
should
definitely
do
more
thinking
about
the
raw
extension
stuff
yeah.
At
the
very
least,
we
should
probably
put
some
library
code
to
make
the
handling
consistent.
A
C
Are
we
definitely
going
to
ship
a
validating
web
hook
or
something
like
that.
E
E
A
A
I
like
shared
standard
code
for
that,
and
I
think
I
added
this
as
a
note
on
my
conflict
resolution
item,
which
I
don't
know
that
we'll
get
to
today,
but
just
there's
a
lot
of
things.
There
there's
some
other
issues
that
have
come
up
that
all
are
things
of.
A
But
yeah
I
I
would
like
to
track
all
the
different
web
hook
requirements
so
when
it
comes
time
to
actually
implement
that
web
hook,
we
know
what
it's
going
to
do
and
it
seems
likely
that
at
you
know
at
least
right
now,
we
have
not
made
the
web
hook
a
requirement
for
v1
alpha
one,
but
I
think,
even
if
it's
not
a
requirement,
we
should
we
should
describe
what
this
web
hook.
E
E
C
From
the
probably
bowie
just
to
thumbs
up
it.
A
Okay,
good,
I
will
I'll
follow
up
on
this
one,
but
yeah
I
will.
Even
if
we
don't
have
you
know,
it
seems
unlikely
that
we
will
have
a
web
hook,
implementation
complete
by
the
time
we
release
v1,
alpha
1,
but
I'd
like
to
have
the
scope
and
requirements
for
our
web
hook
complete
by
that
time.
So
it's
clear
what
implementations
should
be
trying
to
focus
on
and
what
will
be
handled
with
shared
code.
A
All
right,
the
next
one
I
think,
is
from
james,
and
I
think
this
one
may
also
be
yeah
this.
This
is
just
about
it,
so
I
don't
know
that
there's
much
to
to
talk
about
on
this
one
I
know
initially,
I
thought
that
this
should
wait
for
another
pr,
but
I
I
think
these
are.
This
is
isolated
enough,
that
it
makes
sense
on
its
own
james.
Is
there
anything
more
to
say
on
this
pr,
or
is
it
basically
good
after
a
rebase.
C
A
E
A
All
right
this
one,
this
one
will
probably
require
some
more
discussion.
I
I
don't
know
how
to
feel
about
this,
and
I
I
appreciate
your
response
and
it
makes
sense-
and
I
don't
like
any
of
the.
A
I
don't
like
any
of
the
options,
but
this
is
this
is
the
one
where
you're
pulling
out
both
path
and
headers
to
their
own
structs
and
having
at
least
in
in
your
pr
right
now
would
be
a
header
section
and
a
path
section
with
value
and
path
match
type,
correct.
E
I
guess:
what's
the
doesn't
this
match
the
design
pattern
that
we
have
in
the
filters
if
we're
going
to
loft
those.
C
C
It's
a
little
different,
I
think,
because
it's
not
a
union
so
harry's
other
pr
kind
of
defines
the
semantics
of
the
match.
C
In
oh,
the
one
that
that
got
merged
241
updates
the
dock
around
the
matching.
Let
me
just
find
that
that
diff.
C
Yeah
so
the
in
the
match
itself,
it's
an,
and
so
you
can
have
multiple
fields
specified
and
if
multiple
and
if
and
the
results
of
matching
against
each
field
in
the
http
rap
match
are
ended.
But
then
each
the
route
match.
When
you
have
multiple
route
match,
structs,
it's
an
or
so
any
one
of
them
matching
selects
the
route.
But
within
each
match
element
you
have
to
match
all
of
all
the
specified
conditions.
E
A
I
I
think
my
hesitancy
towards
the
path
match
type
is:
it
complicates
our
simplest
use
case.
It
means
that
there's
one
extra
level
of
nesting
like
you,
have
to
do
path,
value
slash
instead
of
path,
slash
which,
but
admittedly
this
looks
really
funky.
I
I
can't
argue
with
that.
The
idea
that
we
have
path
match
type
here
and
then
header
match
type
here.
A
A
A
I
guess
examples
are
usually
closer
to
yeah
there
we
go
here
yeah
and
in
in
these
examples.
Like
this
example
looks
perfect
to
me,
I
get
it
when
you
have
headers
and
path
matching.
I
get
why
they're
both
nested
where
it
gets
funky,
is
this
where
you
have
match
path,
value
bar
assuming
that
you
even
you
know
this
is
probably
going
to
be
optional
and
left
out
plenty.
A
E
Path
type
path,
value
path
match;
it
feels.
E
At
least
it's
like
consistent,
yeah,
consistent
yeah,
like
let's
say
the
user,
because
the
api
is
like
the
user,
eventually,
hopefully
internalizes
a
little
bit
so
like
they
just
cannot
write,
write
it
out
autopilot
and
if
you
have
a
consistent
way
to
do
things,
then
there's
just
fewer
surprises,
so
it's
sort
of,
like
you
know,
safely,
programming
in
c
or
some
lower
level
language.
It's
like
you
have
this
like
consistent
way
to
do
things.
C
A
Yeah,
that's
fair,
and
you
know
I
don't
know
how
common
that
use
case
is
but
or
or
how
broadly
supported
it
is,
but
it
just
yeah
that
that
is
a
good
point.
If,
if
we
do
expand
matching
this
gives
us
a
lot
more
flexibility.
E
But
yeah,
I
think,
let's,
let's
go
with
this
one,
because
it
just
is
more
consistent.
I
feel
like
if,
if
the
state's
based
inside
the
user's
head
has
a
smaller
number
of
rules
that
they,
even
though
it's
a
little
bit
more
indented
or
verbose,
it's
not
as
like.
It's
not
as
surprising
to
deal
with,
because
they
don't
have
to
look
in
the
docks
to
see
what
something
is
named
per
se
yeah.
C
That
makes
there
sense
in
that
one
comment
here,
which
I
resolved
by
saying
that
it's
illegal
to
have
all
the
fields
in
the
header
match
all
the
fields
in
the
route
match
to
be
nil,
so
we
might
want
to.
I
think
we
want
to
probably
just
discuss
that
just
briefly.
E
A
A
A
more
confusing
state
than
just
default
to
match
all
and
actually
have
those
you
know
like
slash
and
prefix.
That's
pretty
clear
to
me
at
least,
and
I
don't
think
that's
going
to
conflict
with
any
other
kind.
That's
not
going
to
conflict
with
header
matching
as
an
example.
C
So
we
can
probably
default
all
this
stuff
so
that
you
get
a
prefix
match
on
slash
yeah,
and
you
could
probably
do
that
at
the
match.
The
route
match
the
top
level
route
match.
Slice
you'd
have
to
you'd,
have
to
add
a
default
there
and
then
you'd
have
to
add
the
default
inside
the
http
route
match
struct
as
well.
A
C
A
Okay,
great
james,
do
you
need
anything
else
here?
You
have
a
good
direction
to
go
forward.
A
A
I'm
gonna
leave
this
one
until
well.
I'll
mention
it
briefly,
but
this
is
another
pr
from
harry
that
I
think
is
going
to
be
worth
talking
about
in
more
detail
on
tomorrow.
So
I'll
mostly
leave
it.
A
But
if
anyone
wants
to
take
a
look
before
we
get
to
tomorrow,
it
is
relatively
significant
and
that
we're
adding
well
harry
is
adding
tls
mode
and
also
which
is
terminate
or
pass
through
and
certain
matching
behavior
for
s,
and
I
it
seemed
reasonably
straightforward
to
me
but
harry's
not
here,
and
I
think
it
would
be
good
to
get
a
larger
audience
tomorrow,
anyways
on
this
one.
A
I
just
want
to
mention
this
one.
Anyone
who's
watching
the
repo
may
have
noticed
this
conversation
months
ago
now
it
feels
like
forever
ago.
I
added
this
pr
to
allow
referencing
namespace
scoped
resources.
A
This
was
part
of
a
much
larger
discussion
and
I
did
not
do
good
at
keeping
this
pr
updated
and
more
context.
Part
of
this.
This
discussion
went
off
base
and
went
into
why
we're
using
object.
A
Reference
and
type
local
object
reference
and
all
these
other
things,
but
I've
added
an
update
all
the
way
at
the
end
as
of
today
on
this
pr,
because
it
it
got
brought
up
more
recently
by
chris
who,
who
was
interested
in
it
from
an
ingress
perspective,
because
whatever
we
do
here
should
probably
mirror
whatever
we
choose
to
do
in
ingress
class,
and
that
got
me
to
digging
back
through
exactly
when
this
was
followed
up
on
and
and
it
turns
out
on,
may
28
so
again
forever
ago.
A
I
added
all
the
rationale
behind
that
here
and,
unfortunately,
the
meeting
for
some
reason
wasn't
recorded
or
uploaded.
I'm
not
sure
what
happened
there,
but
this
is
what
I
remember
coming
from
from
that
discussion.
So
if
anyone
cares
about
this
definitely
come
back
and
follow
up
here
or
on
the
associated
issue.
A
A
A
Yeah
I
was
going
to
follow
up
briefly
on
this,
but
I
think
I'm
gonna
push
this
to
tomorrow
as
well.
Udp
route
looks
pretty
close.
It
just
had
some
feedback
that
needed
some
responses.
I
think
the
last
thing
that
I
again,
I
think
conflict
resolution
is
going
to
get
pumped
to
tomorrow.
A
At
this
point,
the
last
thing
I
want
to
mention
on
this
call
is
the
idea
of
milestone
and
org
maintainers,
which
I
think
it
might
have
been
harry's
idea
that
it
would
be
helpful
to
have
a
milestone
concept
and
service
apis
and
be
able
to
label
specific
prs
or
issues
as
something
that
belonged
in,
say.
The
v1
alpha
1
milestone.
A
A
So
I
I
wanted
to
get
a
few
active
people
that
were
interested
in
being
maintainers
on
this
list,
so
we
had
more
people
who
could
be
maintaining
milestones
and
whatever
else
went
along
with
that
that
role
and
yeah.
So
if,
if
you're
interested,
let
me
know
I
guess,
and
if
you're
not
already
a
six
member
and
are
interested
chances
are
you're,
probably
already
active
in
this
repo,
which
I
think
is
about
all.
A
You
need
to
be
to
be
a
sigs
member,
so
I
can
help
with
that
as
well
yeah,
I
think
that's
all
I've
got
to
say
on
that
one.
I
would
like
to
get
that
milestone
set
up
pretty
soon,
so
that
we
can
start
triaging
issues
and
understand
whether
or
not
something
belongs
or
needs
to
be
solved
in
time.
For
this
p1
alpha
1
release.
A
Yeah
right
now
say
it
right
now,
if,
if
anyone's
interested
that
that
works
too
I'll
probably
provide
another
chance
tomorrow,
you
know
I
I'm
hoping
for
people
that
that
have
been
active
and
involved
in
in
the
in
the
project
which
we
have
a
good
good
community
representation,
and
just
you
know
to
have.
I
don't
know,
maybe
three
two
three
maintainers
on
this
list-
maybe
I
don't
know,
maybe
that's
a
reasonable
starting
point.
You
can
always
add
more.
A
That
was
my
initial
thought
here
very
open
to
volunteers.
On
this
one.
I
know
we
don't
have
too
many
people
on
this
call.
So
I
will
mention
again
tomorrow,
but
yeah
I'll
be
happy
to
think
about
it.
Okay,
great
yeah,
are
you?
Are
you
already
in
or
I
was
thinking
that
would
be
a
good
fit?
Are
you
already
an
org
number?
A
A
C
A
Yeah
yeah
yeah
I'll
I'll
message
you
on
slack,
it's
pretty
easy
cool
thanks
cool
all
right.
Well,
I
think
that's
it
for
today,
thanks
so
much
everyone
for
your
feedback
and
great
participation.
I'll
move
a
few
of
these
things
on
to
the
next
meeting
and
we'll
talk
to
everyone
soon,.
E
Yeah,
if
you
are
blocked
on
your
prs,
just
ping
on
the
slack
and
should
be
able
to
look
at
them,
yep.