►
From YouTube: Kubernetes SIG Cluster Lifecycle 20190410 - Cluster API
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
If
you
are
joining
live
today,
please
go
ahead
and
add
yourself
to
the
attending
list
on
the
agenda
and
if
you
have
any
topics
that
you
want
to
bring
up,
please
go
ahead
and
I
see
a
question
from
somebody
in
the
chat.
If
you're
asking
about
the
heading,
your
name
and
the
attending
list
thing
go
ahead,
and
yes,
please
do
that.
C
So
that
the
PR
that
I
submitted
is
is
into
the
autoscaler
repo
and
is
a
cuts
of
the
openshift
cloud
provider
that
we
did
with
some
changes
to
accommodate
what
is
currently
master
upstream
in
the
autoscaler.
So
I
haven't
seen
any
feedback
on
that.
Yes
and
I
was
hoping
to
attend
the
Sigma
ting
this
week,
but
I
couldn't
make
it
so
I
was
going
to
go
talk
to
them
again
on
Monday
next
week
and
to
see
if
we
get
any
traction
with
appeal.
B
I
wanted
to
just
frame
the
discussion
because
we
had
this
at
the
broader
sig
level
too,
as
well.
With
regards
to
there's
a
lot
of
conversation
back
and
forth
with
the
requirements
talk
that
a
lot
of
folks
were
working
on
earlier
and
what
they
I
want.
People
to
realize
is
that
the
it's
not
a
end-all
be-all
and
it's
not
the
it's
a
it's
a
work
in
progress.
The
whole
purpose
of
that
document
is
essentially
for
us
to
frame
the
next
conversations
to
come
from
B
1,
alpha
2.
B
So
that
way
it
allows
us
to
have
meaningful
conversations
to
say,
like
the
boundary
line
stopped
at
some
point,
for
what
is
cluster
API,
so
I
think
with
that
context,
this
has
put
a
PR
for
a
folks
particular
review.
I
was
thinking,
maybe
like
a
one
big
timeout
for
feedback
and
then
just
kind
of
bridge
it
because
the
it's
meant
to
serve
as
a
as
guardrails
for
conversation
pieces
that
are
going
to
be
the
caps
or
the
follow-on
work
items
that
are
coming
for
the
modifications.
B
A
D
E
I
just
have
common
is
that
I
think
that
at
some
points
in
the
document
are
all
on
the
discussion
with
her,
we
kind
of
mix
the
API
and
the
reference
implementation
with
or
with
microscopy.
I
am
probably
in
your
mind
that
this
career
or
demanding
people
has
been
working
longer
than
this,
but
as
an
external
first
eye,
contact
probably
is
not
necessarily
hope
use,
but
the
different
needs.
E
It's
just
probably
something
that
to
keep
in
mind,
because
actually
the
object
is
say
that
we
offer
like
a
specification,
an
API
and
a
reference
implementation
for
comports,
and
also
we
have
like
external
component,
and
we
always
don't
like
API
in
the
document.
A
very
few
moment.
We
make
a
difference,
but
probably
I
suggest
a
problem
which
should
make
a
second
read
just
keep
in
mind,
while
we're
talking
about,
if
necessary,
make
a
specific
point.
If
this
is
the
specification
of
implementation.
A
So
I
definitely
think
that's
completely
valid.
One
of
the
other
things
too
is
one
of
the
goals
of
that
document
was
to
stay
relatively
high
level
and
not
try
to
get
into
implementing
implementation
details
as
much
and
I.
Think
as
we
continue
to
design
and
build
out
the
designs.
That's
that's
a
place
where
we
can
definitely
draw
that
clear
distinction
between
what
is
part
of
the
project
itself.
What's
reference
implementation
and,
what's
you
know,
on
the
individual
implementers
to
to
provide
as
well.
B
All
right
back
to
Tim
again
for
a
PSA
I
have
two
PSAs
one
is
that
there
is
a
new
contributor
meeting,
this
Friday
for
cyclists
or
life
cycles.
So
if
you
are
new
to
the
sake,
welcome
to
attend
feel
free
to
ask
any
questions
how
to
get
you
lined
up
some
background
information
of
how
the
Sigma
storm
house
ELISA
sub-projects,
exists
in
sort
of
the
what
falls
underneath
their
umbrellas.
B
The
second
P
I
PSA
I
had
was
there's
also
going
to
be
a
meeting
at
KU
con
Europe,
so
there
during
the
contributors
of
it,
there
will
be
a
separate
session
for
folks
who
look
to
get
together,
I'm
actively
soliciting
feedback
on
that
session.
Remember
that
this
is
a
mistake,
is
very
broad
in
scope.
So
we
want
to
have
discussions
that
kind
of
apply
to
several
of
the
subjects
underneath
the
umbrella,
and
we
might
you
know,
spin
off
subsections
for
cluster
it
behind
you
as
well.
A
On
that
note,
I
also
have
a
PSA
to
share.
I
was
able
to
reach
out
to
the
CN
CF
and
they
are
working
on
a
couple
of
designs
for
t-shirts
for
cluster
API
and
I've
also
been
able
to
talk
with
some
of
the
folks
inside
of
VMware,
and
we
are
able
or
we're
going
to
be
able
to
actually
give
out
t-shirts
to
contributors
of
the
project.
A
Unfortunately,
I
don't
yet
have
the
ability
to
share
the
designs
yet
because
I'm
not
going
to
have
those
until
later
this
week,
but
I
also
have
a
deadline
to
have
the
order
in
for
the
t-shirts
by
Friday.
So
if
you
are
interested,
please
go
ahead
and
add
remain
to
the
dot
that
I
linked
in
there
and
some
information,
and
if
you
are
not
able
to
attend,
keep
count
of
Barcelona.
A
A
A
And
another
one
for
me:
I
went
ahead
and
I
sent
a
PR,
and
the
PR
is
linked
in
the
notes
here
to
update
the
repository
owners
and
security
contacts.
I
noticed
in
particular
that
the
security
contacts
were
woefully
outdated,
referencing
old
sig
leadership
and
while
I
was
in
there,
I
went
ahead
and
kind
of
added
myself
to
the
list,
because
I've
already
had
kind
of
extended
HCL's
into
the
github
repo
anyway.
G
B
Technically,
there's
not
precedent
for
that,
and
there's
also
you'd
have
to
work
with
contracts.
So
the
problem
here
is
to
do
to
do
that.
You
need
to
talk
with
other
people
and
it
becomes
more
bureaucratic,
so
we'd
have
to
talk
with
pre,
trib
X
and
then
we'd
have
to
talk
with
the
people
who
run
the
community
stuff
and
update
Docs
to
make
all
this
go.
A
B
You
could
have
you
could
use
discuss,
which
is
more
broadly
applicable
and
would
have
a
better
searchable
history.
Google
Groups,
like
we
mentioned
earlier,
is
not
accessible
by
folks
in
China,
but
you
can
create
a
forum
on
discuss
and
that
might
be
a
better
venue
by
which
folks
could
communicate,
and
that
has
precedents
as
well.
It
wouldn't
have
all
the
issues
that
exist
around
trying
to
create
new
communication
lines.
G
I
F
H
Okay,
yeah
there's
just
there's
a
trade-off
between
you
know
having
having
one
place
where
all
the
discussion
is
as
opposed
to
having
a
bunch
of
different
place,
because
I
feel
I
feel
like
we
still
end
up
having
I
guess
some
discussion
in
github.
So
I'm
just
you
know
we
have
all
these
Google
Docs
so.
E
Yeah,
actually
that's
going
to
be
problematic
because
we
will
have
a
biggie
table,
but
it's
more
or
less
clear
what
you
will
find
her.
But
then
we
will
have
the
discussion
with
all
the
we
would
keep
the
the
mailing
list,
probably
and
being
a
slack
and
I'm
afraid
that
conversation
will
ferment
the
world
different
platform,
mostly
between
the
group,
maybe
mailing
list,
the
slack
and
the
discuss
as.
A
You
said
I
think
so.
I
think
one
thing
we
need
to
be
careful
with
is
to
try
to
avoid
using
relying
too
much
on
synchronous
method
of
communication,
especially
as
we
try
to
build
consensus
around
a
lot
of
this
stuff.
So
well,
slack
is
great
for
kind
of
that
synchronous
communication,
it's
not
so
great
about
kind
of
recording.
You
know
why
decisions
were
made
and
and
when
they
were
made,
and
things
like
that.
Mailing
lists
generally
fill
that
void.
A
But
I
do
worry
that
we
are
excluding
some
folks
in
the
APAC
region,
in
particular
by
doing
that,
and
we
have
been
seeing
some
increased
contributions
there
as
well
and
actually
well.
I
wasn't
even
aware
that
they
didn't
have
access
to
the
Google
group
until
today
and
that
actually
explains
why
we
didn't
actually
get
any
feedback
from
anybody
in
that
region.
When
we
were
trying
to
seek
out
times
for
the
goals
and
requirements.
The.
F
Nothing
disgust
is
great,
I,
think
I.
Try
that
and
see
how
it
goes.
You
have
is
definite
arable
place
to
have
threads
and
yeah
I
mean
we
already
have
discussions
that
are
like
non
searchable
non-indexed,
as
in
the
actual
videos
that
you
have
to
watch
to
find
out
what
what
what
was
actually
said-
and
it's
not
indexed
by
the
the
meeting
notes
or
anything
like
that.
H
B
Well,
I
I,
don't
think
that's
necessarily
true
I
think
if
it's,
if
you're,
making
broader
decisions,
you
know
I
think
there's
a
fine
line
between
what
should
go
in
an
email
thread
versus
what
goes
in
github
I.
Think
as
we're
broaching
a
lot
of
new
keps.
Those
are
the
high
level
design
decisions
and
discussions
having
those
in
a
discuss
thread
is
useful
not
only
for
understanding
but
for
posterity,
but
once
we've
set
a
little
design,
you
know
and
you're
breaking
down
the
work
items
for
execution
and
even
arbitrating
issues
there.
A
Yeah
and
that's
a
good
point
like
the
discuss,
wouldn't
be
to
kind
of
preserve
the
end
result.
At
the
end
of
the
day,
the
end
result
will
be
committed
to
the
repository
as
the
design,
but
as
we
try
to
work
through
some
of
the
issues,
especially
where
there's
potentially
contention
between
different
points
of
view
having
a
venue
to
where
we
can
actually
discuss
that.
As
is
what
we're
looking
for
right
now,.
D
Yeah
I
think
we're
proposing
as
like
an
alternative
it
to
the
mailing
list
right,
yeah
yeah,
so
one
thing
I
noticed
from
discuss,
is
alike.
Mm-Hmm,
there's
like
a
really
few
categories.
So
there's
just
like
a
general
discussion
to
you
know
where
we'll
be
file
like
there's
discussion
like
for
the
sake,
work
cost
their
API.
We.
B
F
G
So
the
last
thing
I
had
in
this
section
that
I
added
was
about
Google
Docs,
specifically
because
I
know
not
everybody
can
access
found.
So
if
we're
working
on
caps
for
cluster
API
features,
if
there's
something
else
that
works,
that
will
work
for
everyone
or
is
Google
Docs,
still
kind
of
the
best
thing,
even
though
it
excludes
some
people.
G
And
I
don't
think
that
discuss
is
likely
to
be
an
appropriate
avenue
or
venue
for
collaborating
on
a
cap.
I
mean
that
needs
to
be
something
like
Google,
Docs
or
hack,
MD
or
any
sort
of
collaborative
editing
platform
or
a
pull
request
to
github,
which,
admittedly,
is
harder
to
to
work
with
over
time.
As
you
get
more
and
more
comments,
but
presumably
it's
accessible
by
more
than
say,
Google
Docs,
the.
B
Standard
operating
procedure
for
every
other
project
that
exists
is
to
create
a
Google
Doc,
and
if
people
from
China
want
to
access,
they
always
there's
always
ways
around
that
portion
and
there's
always
the
once
you've
finalized
the
collaboration
point.
Then
the
pr4
has
to
occur
to
some
repository
and
that
PR
is
another
venue
by
which
they
can
often
communicate.
B
A
F
M
B
Yeah
we
should
probably
this
mentioned.
He
wanted
to
sync
with
Georgia.
If
you
wanted
to
take
point
or
anyone
to
pointers
what
he
must
take
point
and
then
write
up
a
summary
and
then
send
it
out
to
the
list
of
the
details
and
follow
George
I.
Think
that
seems
appropriate,
so
so
much
to
take
an
action
item
to
do
all
the
follow-up
and
logistics
yeah.
D
L
A
D
D
We
added
four
work
streams
for
now
but
like
we
should
because
they
for,
if
we
need
more,
we
have
the
name
of
the
work
stream,
the
facilitators
and
the
meeting
minute,
which
probably
linked
to
a
Google
Doc
with
meeting
notes
and
its
facilitator
should
like
actually
sent
out
a
probably
a
doodle
at
some
point,
to
align
on
some
million
times
on
in
zoom
or
like
like
a
discuss
as
we
as
we
mentioned.
Please
add
yourself
as
participants
or
if
you
want
to
be
a
facilitator
at
your
name
to
to
the
list.
D
The
facilitator
role
is
mostly
to
organize
the
like,
as
I
mentioned,
like
the
Google
Doc,
or
just
like
pretty
much
the
logistics,
it's
like
shouldn't
be
seen
as
like
kind
of
like
a
lead
or
anything,
but
it's
more
like
a
representation
of
the
group
and
as
with
that,
like
I,
can
share
my
screen.
We
can
go
over
if
we
want
to.
But
let's
see,
can
you
buddy
see
this
so
or
proposing?
Here
is
like
for
work
streams.
We
have
extension
mechanism
which
we
have
discussed
a
lot.
D
B
Like
right
now,
for
those
who
are
new
to
this,
like
there
should
be
an
overview
like
at
least
understanding
of
like
high-level
review
of
what
the
different
work
streams
are,
because
the
context
of
extension
mechanism
is
so
broad.
I
know
what
you
need,
because
I've
been
around
this
project
from
the
beginning,
but
I,
don't
think
people
who
are
new
to
this
others.
What
that
actually
means.
B
D
We
can
go
one
by
one
and
discuss
them.
I
was
hoping
to
actually
do
that.
A
synchronously
though,
but
Jason
you
wanna,
give
like
a
brief
description.
A
Yeah
sure
so
for
the
extension
mechanism,
what
we
were
looking
at
is
we
want
to
try
to
isolate
the
discussion
around.
How
do
we
extend
cluster
API
as
far
as
interacting
with
provider
implementations,
and
this
would
cover
both
kind
of
like
bootstrapping
providers
and
infrastructure
providers,
wherever
we
need
to
kind
of
provide
like
a
plug-in
model
that
that's
what
we
want
to
cover
with
the
extension
mechanism,
work
stream
so
far,
you
know:
we've
had
high-level
discussions
around
that
potentially
being
web,
hooks
that
potentially
being
G,
RPC
or
being
independently
reconciled
C
RDS.
A
So
that's
kind
of
the
high-level
gist
of
that.
We
want
to
try
to
kind
of
compare
and
contrast
the
different
approaches
find
out
which
model
that
we
want
to
choose.
If
there's
even
a
single
model
that
we
want
to
choose
for
all
of
the
different
extension
points
and
how
we
want
to
proceed
there
did
you
want
to
cover
the
data
model
yeah.
D
So
for
there
tomorrow,
this
is
going
to
be
kind
of
like
a
little
bit
more
broad.
Hopefully
this,
which
term
actually
will
split
in
multiple
other
work
stream.
For
example,
we
talked
about
machines
and
the
scope
of
the
machine
to
what
they
should
do.
This
is
like:
how
do
we
refine
a
little
more
that
we
have
right
now
right
now
we
have
cluster
and
machine
as
high-level
objects.
A
D
And
like
I,
want
to
add,
like
the
PPR
around
the
higher
level
requirements
is
meant
to
be
like
as
a
starting
point
right,
like
I
still
mention
it's
a
living
document
which,
like
we
can
like,
for
example
like
just
like
start
right
now
and
then
update
in
the
future,
but
has
to
like
kind
of
it
will
start
the
conversation
for
all
the
work,
stream
and
kind
of
give
a
base
up
for.
What's
in
scope
and
what's
out
of
scope,
the
next
two
or
control
plane,
lifecycle
management
and
the
note
bootstrap
logic
doesn't
I'll.
A
Right
so
for
the
control
plane,
lifecycle
management,
as
we
started
discussing
in
like
the
requirements
document,
we
wanted
to
be
able
to
have
an
actual
story
around
being
able
to
manage
the
control
plane.
It's
first-class
kind
of
thing.
We
want
to
be
able
to
scale
those
and
then
obviously
scale
down
if
we're
deleting
and
then
we
also
need
to
have
kind
of
an
upgrade
story
around.
A
In
particular,
we
don't
yet
have
a
facilitator
here,
and
the
goal
that
we
have
for
the
facilitator
is
not
necessarily
to
be
the
owner
for
these
topics,
but
two
rather
kind
of
coordinate
like
meeting
times.
If
there
are
any
kind
of
zoom
meetings
for
the
group,
facilitate
the
discussions
and
and
that
sort
of
thing
so.
G
A
D
J
How
about
node
lifecycle
management.
N
G
O
O
Able
to
create
some
sort
of
underlying
server,
so
everyone
to
languish
chained,
not
to
use
the
same
word
and
that's
you
know
then
then
creep
making
that
into
a
kubernetes
notice
is
sort
of
a
second
step.
There
is
that
type
of
thing,
which
is
an
anonymous
category
and
all
within
scope
here.
Do
we
want
to
just
define
an
API?
We
need
out
of
the
provider
to
to
get
a
machine,
I
guess
I'm,
not
clear
on
on
that
boundary
in
scope,
I.
B
Think
the
work
streams
are
meant
to
define
the
boundaries
like
so
like
we
can
the
work
streams
like
if
we
talk
about
node
lifecycle
management,
we
can
say
we
can
determine
what
we
want
to
work
on.
As
a
group,
we
just
need
to
have
buckets
I,
think
for
now
and
then,
as
as
we
iterate
we'll
we'll
determine
what
we,
what
is
in
scope,
not
a
scope
like
I'm
I'm,
very
interested,
particularly
in
image.
Damping
and
I
never
talked
about
that
before.
B
O
B
O
O
G
O
Understand
that,
but
it
wedding
yeah
again,
it's
a
I
think
we
just
as
long
as
it's
clear
to
everybody.
I
guess,
that's
fine
too!
If
it's,
if
there's
cloud,
do
we
you
do
is
centralize
organizationally.
Do
we
centralize
all
the
cloud
provider
specific
functionality
in
in
st.
cloud
provider,
or
do
we
take
some
of
it
here
and
that
that's
a
bigger
question?
Maybe
then
we
want
to
answer.
Maybe
it's
already
just
clear
and
I'm
just
coming
in
late
in
so
to
me,
this
is
a
great
conversation
topic
for
Friday.
We.
A
Just
going
to
say
that
some
of
those
discussions
around
does
this
belong
as
part
of
cluster
API.
Does
this
belong
somewhere
else
and
we
collaborate
with
a
different
group?
Do
we
try
to
factor
out
logic
into
a
common
place?
I
think
these
are
some
of
the
discussions
we
have
to
have
as
part
of
these
work
streams.
H
Quick
question
on
potential
additional
work
stream
of
for
infrastructure,
so
infrastructure,
including
you,
know,
network
security
groups.
Things
like
this.
That
I'm,
not
noting
that
covered
I,
know
I
know
is
in
it
is
specific
to
to
providers.
But
there
is
a
least
I
have
a
particular
case
in
mind
that
sort
of
across
all
providers,
so,
for
example,
I
bring
up
the
cluster
with
with
the
cluster
API
and
then
I
create
some
services
of
the
load,
balancer
type
right
and
underneath
the
cloud
controller
manager
goes
out
and
creates
a
bunch
of
resources.
H
For
me,
then
I
go
to
the
cluster
API
and
I
tear
down
that
cluster,
but
the
cluster
API
doesn't
manage
the
you
know
the
load
balancers
that
back
those
services
and
there's
not
necessarily
a
mechanism,
that's
going
to
ensure
that
those
get
torn
down
and
as
the
cluster
API
is.
You
know
it's
bringing
down
this
infrastructure
all
of
a
sudden.
It
can
hit,
for
instance,
an
AWS,
a
dependency
violation,
because
hey
I
can't
I
can't
bring
down
this
network
or
this
VCC
that
that
I
created
by
being
the
cluster
API
controller.
D
D
It's
kind
of
like
you
can
imagine
like
some
some
foundation
right
like
that's
what
other
like
work
stream
will
like
kind
of
build
upon,
but
they
are
scoped
to
be
like
running
in
parallel
like
so
that,
like,
for
example,
eyes,
you
said
like
infrastructure,
we
can
define
what
the
infrastructure
is
and
what
we're
going
to
be
foreclosed
JPI
within
the
data
model
and
if
net
like,
if
necessary,
we
can
spin
off
into
another
work
stream
with
folks
that
are
interested
in
driving.
That.
B
One
of
my
broader
concerns
here
is
that
we
don't
become
too
fragmented,
because
these
things
will
percolate
back
and
forth
across
each
other.
I
think
it's
it's
an
imperative
that
if
decisions
are
made
or
updates,
are
given
back
to
this
larger
group
as
part
of
the
weekly
sync,
so
that
way,
you
know
it's
kind
of
like
it's
part
of
the
whole
body.
If
you
move
your
leg,
you
know
vigorously
your
other
parts.
Your
body
are
gonna
shake,
so
you
need
to
be
able
to
have
awareness
of
things
that
are
going
on
so
I.
D
That
brings
up
the
other
thing
that
I
added
down
here,
oh
I,
see
we're
at
an
idea,
is
adding
it,
so
this
was
gonna,
be
a
template
for
workstream
updates.
So,
for
example,
like
next
week
meeting
the
facilitators
can
give
like
an
update
for
the
extension,
McKinney's
beta
model
and
all
the
different
work
streams,
and
we
can
keep
going
so
that
we
can
kind
of
like
keep
the
community
in
sync
with
each
other.
D
One
other
thing
is:
we
were
thinking
about
using
get
up
projects,
so
the
facilitators
or
other
members
of
the
cluster
API
project.
Could
you
try
to
get
hub
to
kind
of
like
assign
issues
or
PRS
to
their
own
projects
so
that
we
can
keep
it
scoped
and
talk
about
the
facilitator
role?
I,
don't
know
if
we
have
talked
about
participation
rules
at
this
point,
but
we
can
probably
think
on
those
later
Andy
did
you
have
anything
for
participation,
rules,
yeah.
G
Just
some
of
the
things
that
I've
noticed
across
many
many
zoom
meetings
over
the
past
couple
years
is
that
sometimes
it's
hard
for
people
to
get
their
opinions
voiced.
So
we
could
try
to
use
zooms,
raise
hand,
feature
or
other
methodologies
as
well.
I.
Think
just
I
wanted
to
call
out
that
the
facilitator
or
facilitators
should
work
with
each
workstream.
D
Sounds
good
I
think
with
that
I
can
give
you
just
back
I!
Think
I'm
done.
If
you
have
any
concerns
you
can
reach
out
in
slack
or
personally
in
India
and
give
any
feedback
I.
O
D
Well,
I
guess
Tim
can
carry
out
the
logistics,
but
the
idea
is
to
keep
in
in
the
same
repo,
because
this
is
a
sub-project
of
the
Sikh
cluster
like
circle
their
goals
and
on
goals
as
the
main
starting
point
as
we
mentioned,
and
keep
all
the
proposal
inside
our
own
repo.
The
cap,
the
close
API
enhancement
proposal
is
shaped
after
the
cap
upstream,
with
some
parts
removed
which,
like
mine,
are
make
sense
for
our
sub
project.
D
B
Pretty
much
well
I
had
a
small
little
bit.
I
think
that
the
purpose
of
this
too,
is
is,
is
to
understand
the
boundary
lines
and
make
it
explicit
between
where
upstream
caps
begin
and
end
in
what
their
attention
were
up.
Straight
caps
were
meant
to
communicate
bras,
broad
states
of
features
for
KK
right
and
they
cut
across
KK
sub
projects,
have
their
own
governance
model
and
that's
needing
special
specified
inside
of
the
community
repository
and
because
it
has
its
own
release
timeframe
and
it's
not
dependent
upon
the
rest
of
KK.
B
Yeah
we
still
want
to
have
a
similar
format.
You
know,
but
not
all
the
other
fields
make
sense,
not
all
their
details
make
sense
and
at
some
point
the
end
of
the
day.
We
want
to
be
able
to
cut
a
release.
So
it's
okay
I
know.
Sometimes
if
you
put
a
cap
off
this
death
by,
if
I
was
a
needle,
sometimes
in
the
community
River
repository-
and
this
is
much
smaller
group-
so
let's,
let's
keep
it
focused
and
fair
and
honest
and
and
just
keep
it
moving.
G
B
Let's
sit
here
can
work
shape,
see
a
part
of
the
new
contributor
onboarding
SEL.
We
can
talk
about
it
for
sure
this
mystery
easier,
joining
pretty
III
think
this
is
all
kind
of
new.
This
is
a
little
bit
because
we
have
such
a
broad
swath
of
things
we
want
to
accomplish
in
such
a
large
group
of
people
breaking
down.
B
The
structure
makes
a
little
more
sense
because
not
everybody's
interested
in
all
the
things,
and
also
in
such
a
large
meeting
such
as
this
one,
we
have
a
tendency
to
bike
ship
on
some
topics,
so
keeping
keeping
individual
scope
down
or
extremes
makes
a
ton
of
sense
so
that
this
is
a
little
bit
new.
You
can
feel
free
to
ask
questions,
but
I
don't
know
if
I'm
gonna
have
a
definitive
answer
for
that
question.
E
E
Yeah,
unfortunately,
yes,
because
somewhere,
my
point
is
that
big
in
Europe
I
mean
the
tendency
will
be
that
I
mean
for
me.
Now
is
almost
8
p.m.
and
this
is
an
early
meeting
and
we
have
some
meetings
for
9
p.m.
or
stuff
like
that.
So
be
careful.
If
we
have
many
more
meetings
and
I
can
accommodate
to
three
meetings
a
week
outside
office
hours
with
you,
we
had
three
more
meetings
for
the
different
or
streams.
The
problem
is
not
to
overlap
them,
because
many
people
is
interested
in
more
than
one
and
the.
M
D
E
D
I
would
expect
us
to
have
like
a
little
more
meetings
to
start
and
then
start
the
conversation
and
then
move
to
a
synchronous,
because
I
feel
like
that
also
worked
pretty
fine
for,
for
example,
for
a
requirement
and
known
like
in
the
goals
and
on
roles
where,
like
we
kind
of
met
once
or
twice
I,
believe,
and
then
we
moved
to
like
Google
Doc,
for
example.
So
we
can
move
to
that
and
discuss
to
kind
of
solicit
feedback
and
comments.
A
And
I
can
speak
to
what
I
was
thinking
about
doing
for
the
extension
mechanism,
which
was
basically
try
to
solicit
times
that
that
would
work
for
an
initial
kickoff
meeting
and
then
from
there
we
can
determine
you
know
how
to
proceed
from
there,
whether
it's
fully
asynchronous
or
haven't
have
a
meeting
to
you
know
recent
period
from
time
to
time
as
well,
but
I
think
the
initial
kickoff
meeting
would
probably
be
good
for
all
of
these
to
start
shaping
the
discussion
and
then
from
there.
Let's
go
as
a
synchronously
as
possible.
So.
N
Else,
if
we're
going
to
do
this
in
a
way
that
encourages
asynchronous
participation,
then,
and
especially
the
AIPAC
folks,
then
the
mailing
list
is
probably
not
the
best
place
and
I
don't
know
about
their
participation
on
slack.
So
maybe
getting
that
discussed
stuff
set
up
first
and
then
publicize
the
doodles.
That
way
would
achieve.
You
know
better
participation.
I
D
I
was
just
saying,
like
I
think,
even
if
we
set
up
discuss
there
would
be
some
like.
You
know
like
ramped
up
time,
to
like
kind
of
make
the
community
familiar
from
your
eyes
with
this
new
mechanism,
because
we've
never
done
this
in
a
sig
or
sub
project
before
so.
We
need
to
like
try
to
reach
out
as
much
as
possible
and.
G
So
I
think
we
can
send
it
a
mailing
list.
We
can
figure
out
the
discuss
aspect
and
post
on
discuss.
We
can
also
use
other
social
media
mechanisms
like
Twitter
or
whatever,
and
just
try
and
broadcast
it
as
much
as
we
can
and
get
people
in
our
social
networks
to
broadcast
it,
and
if
there's
people
that
we
feel
are
potentially
getting
missed
out
and
are
missing
out
and
you
have
direct
communications
to
them
like
feel
free
to
email
them
or
reach
out
to
them
in
whatever
way
so,
basically
just
broadcast
this
all
over
the
place.
G
Each
work
stream
needs
to
define,
what's
in
and
out
of
scope,
for
it
probably
look
at
the
use
cases
that
everybody's
been
putting
together
and
see
which
use
cases
apply
to
to
each
work
stream.
But
ultimately,
we
want
to
have
these
caps
flash
capes
that
have
enough
design
details
that
people
could
go
and
implement
them.
So
we
talked
about
what
each
of
the
work
streams
is
at
the
beginning
of
the
discussion
on
work
streams.
If
you
have
further
questions
on
what
they,
what
their
scope
is,
please
reach
out
either
here
or
slack
mailing
list
whatever.
G
But
what
I
would
hope
is
that
we
can
have
these
kickoff
meetings
and
then
move
fairly
quickly
into
asynchronous
self-organizing
groups,
where
we
are
actively
working
on
Google,
Docs
or
whatever.
The
mechanism
is
for
producing
these
cups
so
that
we
can
start
actually
putting
together
PRS
for
B
1,
alpha
2
I
would.