►
From YouTube: WG Component Standard 20190917
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
Okay,
good
morning,
everyone
and
welcome
to
the
tuesday
september
17th
working
group
complaint
standards
session
how's
everyone
doing
today.
C
Yes,
oh
good
good
it's
afternoon
for
me,
but
it's
all
right.
A
Great,
so
we
have
kind
of
a
small
group
this
morning,
but
I
still
want
to
take
some
time
for
this
lee
and
I
have
been
talking
a
little
bit
and
we
both
kind
of
agree
that
feels
like
it's
been
a
slow
few
months.
A
So
we
wanted
to
kind
of
have
a
discussion
and
we'll
probably
continue
this
again
next
week
in
case
other
people
show
up
about,
like
which
sorts
of
things
are
challenging
for
people
in
open
source,
which
things
might
be
blocking
work
we've
seen
a
lot
of
really
good
ideas
come
through
working
group
and
people
have
written
some
very
interesting
caps
and,
like
that's,
gotten,
some
review
and
some
discussion
in
open
source,
but
it
seems
like
a
lot
of
things
are
stalling
lately.
A
C
American
start:
well,
I
for
myself,
I
don't
know
I
haven't
been
with
the
working
group
for
too
long
and
but
so
far
it's
been
quite
good.
I
mean
thanks
a
lot
to
lee
who's,
taking
out
quite
a
bit
amount
of
time
to
go
through
some
issues
with
me.
That
was
really
helpful.
I
think
in
general.
It's
I
think
you
mentioned
it
last
conversation
is.
I
think
people
can
find
a
bit
difficult
to
work
on
these
issues,
at
least
like
from
my
point
of
view.
C
Looking
through
all
these
serializer
stuff,
it
can
be
quite
daunting
and
there's
a
lot
of,
like
I
don't
know,
a
lot
of
abstractions
and
sometimes
duplications,
where
it's
not
quite
clear
like.
Why
is
this
used
there?
Why
is
this
used
there?
I
think
it's.
It's
also
part
of
our
job.
I
guess
to
better
that
on
that
front,
but
I
mean
like,
as
far
as
working
with
the
working
group
goes,
I
only
have
good
things
to
tell.
C
I
don't
know,
I'm
it's
it's
challenging
for
sure,
especially
for
someone
who
hasn't
really
worked
on
this
before,
but
I
feel
it's
a
lot
of
fun.
For
me
at
least,
I
have
to
dig
into
these
issues,
but
I
can
feel
I'm
making
some
progress,
at
least
so
at
least
I'm
learning
stuff,
and
I
know
which
points
to
tackle
next
so
yeah.
For
me,
it's
quite
good
actually.
A
Okay,
well,
that's
good,
do
you
feel,
like
you
know
the
people
you
need
to
reach
out
to
for
things,
and
you
know
how
to
get
in
contact
with
them
and
and
make
sure
that
you
know
your
issues
are
being
addressed
like
I
know
a
lot
of
times
in
open
source.
A
C
I
mean
for
my
work
since
I
haven't
really
done
much
as
of
yet
I
haven't
had
much
issues,
at
least
in
this
working
group.
I
had
some
in
the
past,
while
I
was
trying
to
get
some
traction
with
like
other
six.
This
could
be
quite
challenging.
I
mean
at
the
moment
I
I
don't
see
it,
but
I
can
see
why
why
people
would
say
that
or
why
he
would
have
this
problem.
A
B
Something
I
think
is
very
worth
pointing
out
is
over
the
past
few
releases,
we've
received
a
lot
of
discussion
and
criticism
of
the
project
from
like
core
maintainers
and
then
users
about
the
prioritization
of
features
and
graduation
features
with
very
really
little
work
on
stability,
refactoring
and,
basically
everything
that
this
working
group
is
concerned
with
and
a
lot
of
that
in
from
what
I
see
is
people
are
incentivized
right
by
by
monetary
goals,
right
and
so
people
who
are
paid
to
work
on
the
project
work
for
companies
who
get
ultimately
incentivized
by
their
clients-
or
you
know,
by
their
product
development,
to
merge
features
that
are
in
line
with
something
that
can
enable
them
to
have
some
kind
of
differentiator
in
the
field
so
that
they
can
use
kubernetes
to
sell
stuff
right
and
and
stability.
B
Isn't
sexy
or
cheap.
A
A
It's
sort
of
a
tragedy
of
the
comments
right.
If
it
doesn't
happen.
C
What's
like
the
I
mean,
maybe
you
guys
have
a
bigger
view
on
that,
but
I've
like
the
past
couple
weeks
has
only
been
really
us
discussing
this
stuff
right.
Is
there?
Are
there
any
other
members
working
on
it
like
on
the
back
lanes
or
somewhere.
A
B
Yeah
tim
expressed
a
lot
of
support
from
the
c
cluster
cycle
perspective,
of
doing
anything
that
he
can
to
bolster
the
efforts
in
the
area
of
component
config,
specifically.
B
B
A
Yeah,
I
think
that's
definitely
something
to
be
more
of
even
if
we
had
like
a
weekly
or
bi-weekly.
B
Yeah
I
mean
we'll
have
the
c
cluster
lifecycle
call
after
this,
where
we
have
our
announcements
for
the
people
on
that
call,
but
yeah
the
mailing
list
is
certainly
a
larger
audience
right.
C
I
remember
sort
of
like
the
first
time
I
really
got
started
working
on.
This
was
the
contributor
onboarding
and
there
were
a
couple
of
points
which
were
identified
for
like
new
contributors
to
work
on.
Would
it
make
sense
to
like
I
don't
know,
make
issues
out
of
them
describe
them
and
then
maybe
use
those
links
on
the
mailing
list
and
say
hey
look.
We
have
some
work
to
do
if
you
guys
would
like
to
join
reach
out
to
us
or
something
like
that,
so
that.
C
Go
ahead,
yeah,
and
that
was
like
one
of
the
problems
I
had
when
I
was
trying
to
get
started
with
kubernetes,
just
like
identifying
issues
which
you
know
I
can
work
on
and
kind
of
like
matches.
C
My
skill
set,
or
you
know
I
can
tackle
as
a
like
starting
contributor,
a
lot
of
the
issues
to
see
on
on.
Like
I
don't
know
in
general,
like
in
kubernetes
quantities
or
in
in
the
six,
you
know
they
love
people
talking
about
it.
It's
like
yeah,
I'm
tackling
that
immediately
and
it's
a
bit
like
difficult.
Okay
like
how
what
are
like
areas
where
I
can.
Actually
you
know
chime
in
and
work
on
stuff.
C
So
that
was
a
bit
difficult
for
me
and
I
had
to
navigate
like
d6
six,
a
little
bit
until
I
reached
I
reached
here.
Basically.
C
I
I
think
I
think
it
does.
I
mean
like
if,
if
lee
wouldn't
have
like
taken
the
time
to
mentor
me
in
this
regard,
I
don't
think
I
would
like
still
spend
time
on
this
issue
just
because
it's
so
daunting.
You
know
like
there's
no
way
for
me
to
to
tackle
this
as
an
outsider,
with
no
inside
knowledge.
I
mean
you
know.
Of
course
I
can
read
a
book
on
api
machinery
or
something,
but
you
know
I
still
wouldn't
know
all
the
backstory
of
it
and
how
these
things
interact.
C
It's
just
so
much
better.
If
someone
talks
through
you
just
for
like
an
hour
or
so
yeah,
it
was
so
much
better.
It's
it
helped
a
lot.
B
Really
like
that
idea,
so
that's
part
of
the
project
management
stuff
is.
We
should
structure
it
so
that
it's
clear
mentorship
is
available
for
people,
even
if
they,
you
know
log
on
from
thailand
or
india
in
a
completely
different
time
zone,
and
they
don't
know
anybody
yeah
and
that
can
be
oh.
I
can
reach
out
to
this
person.
A
Yeah
and
that
can
be
our
value
proposition
like
it's
something
I
was
trying
to
think
about
was
you
know,
our
working
group
is
doing
a
lot
of
refactoring
and,
like
reorganization,
it's
a
great
way
to
learn
about
the
code
base.
It's
not
necessarily
the
sexiest
work,
because
it's
not
like
a
feature
that
you're
gonna
necessarily
write
a
big
blog
post
about
right,
but
it's
important
to
sort
of
the
longevity
of
the
project
and
like
kind
of
the
cleanliness
of
the
system,
so
I've
been
trying
to
think
about.
A
You
know
what
other
things
can
we
offer
people
it's,
maybe
not
like
the
glory
of
working
on
a
future
but
still
valuable
them.
So
I
think
that's
a
really
good
one.
Yeah
mentorship
like
opportunity
to
learn
about
the
code
and
be
more
involved
with
the
project
and
we'll
actually
coach
you
through
it.
You
know.
C
Yeah
yeah
and
you
know,
having
like
a
single
like
landing
page
now
on
maybe
on
the
readme
of
of
the
working
group
and
having
a
link
to
the
project
management
page
and
saying,
like
look,
you
know,
these
are
the
issues
we're
currently
working
on
if
you're
interested
in
any
of
those
reach
out
to
xyz,
or
something
like
that.
So
as
a
new
contributor
like
to
fetch,
friction
to
get
started
on
these
issues,
get
reduced
gets
reduced
as
much
as
possible.
I
think
that's
a
good
way.
D
D
What
I
was
supposed
to
do
is
actually
a
pr
that
was
open
as
an
example
on
kk,
and
that-
and
the
thing
that
I
was
thinking
is
that
that
pr
that
never
never,
actually,
that
that
never
actually
landed
and
just
got
close,
was
a
really
good
and
useful
resource
and
and
normally
normally
things
like
that-
don't
actually
go
into
don't
actually
go
into
the
recommendation
again
because
it's
not
it's
not
a
feature.
It's
not
something
that
most
people
should
be
looking
at.
Is
there?
D
A
That's
a
really
good
point
and
I
think
we
should
definitely
there
were
some
talks
about
having
like
an
examples
directory
in
component
base
rightly,
but
I
think
a
few
of
our
libraries
do
that.
So
maybe
we
should
look
at
that
more
seriously
and
try
to
have,
like
you
said,
more
real
examples
where
you
can
just
go,
read
the
code
and
see:
oh,
that's
how
this
is
supposed
to
be
used.
A
B
I
guess,
a
good
significant
burden
for
us
to
propose
a
patch
right.
That's
making
improvements,
often
incrementally
to
get
to
the
end
goal
and
to
like
already
have
that
example
beforehand
when
people
who
have
got
who
are
going
to
go
through
months
of
review
processes
on
that
code
are
going
to
nitpick
things
and
like
ask
for
structure
to
change.
A
Specific
one
we're
talking
about,
but
I
think
you
could
also
have
you
know
well,
a
lot
of
code
is
already
merged
right
and
there's
a
lot
of
things
in
use
that
are
tough
to
understand,
like
the
serializer
stuff's,
a
great
example
of
that
right
and
alex.
I
don't
know
if
you,
if
you
had
had
more
examples
of
how
it
was
supposed
to
be
used
that
were
well
documented.
Do
you
think
that
would
have
helped.
C
C
Yeah
definitely
I
mean
I
feel
there
are
like
first
of
all,
there's
this
whole
like
api
machinery,
which
is
you
know,
a
beast
in
itself
to
tackle
like
getting
to
know
all
the
difference
like
what's
the
scheme?
What's
what's
like
internal
version,
external
version
that
took
me
quite
a
while,
and
I
think
there
are
some
some
resources
available
for
that,
although
it's
not
as
let's
say,
as
I
don't
think
it's
it's
like
the
area
is
not
as
sexy.
C
As
you
said,
it's
like
you,
know,
networking
or
something
it
are
not
like
big
fancy
blog
posts
about
it.
No
one's
really
writing
about
it.
I
mean
you
have
some
talks
of
you
know.
Stefan
or
you
know,
there's
this
one
book
on,
I
think
amazon.
They
wrote,
which
I,
which
I
like
currently
reading
as
well.
So
like
you,
you
can
kind
of
like
get
at
the
information,
but
it's
it's
really
difficult
because
there's
just
not
a
lot
of
you
know
easy
to
understand,
beginner,
friendly
resources
on
on
this,
I
feel
yeah.
C
To
answer
your
question.
Definitely
I
mean
these.
These
things
always
help.
You
have
like
a
nice
write-up
on
on
this
stuff.
It's
it's
always
good
to
have.
A
Pretty
cool,
so
I
think
that's
something
we
can
look
at
doing
as
well.
Maybe
we
can
come
up
with
kind
of
a
framework
for
how
to
write
that
kind
of
documentation
and
write
those
examples
and
some
guidelines
and
then
kind
of
encourage
people
to
do
it.
B
Yeah
I'll
just
point
out
as
well.
That
kind
of
it
might
be
also
good
to
have
a
kind
of
like
issue,
or
example,
document
like
what
alex
did
was.
What
am
I
saying.
B
When,
when
first
attacking,
like
multi-dock,
which
then
like,
went
down
into
some
deeper
api
machinery
and
serializer
stuff,
the
first
thing
that
you
did
was
you
started
a
document
where
you
cataloged,
like
english
descriptions
and
links
to
version
pieces
of
the
code
for
all
of
the
different
components
that
were
kind
of
within
scope
of
what
would
work
on
that,
and
they
all
did
things
in
a
different
way
right,
and
so
that's
like
the
the
problem
is
desiring
and
like
wanting
for
a
refactoring,
and
so
the
whole
reason
why
there
isn't
like
a
central
example
or
list
of
examples
is
because
these
projects
have
all
done
it
a
different
way,
and
you
have
to
have
somebody
who's
willing
to
then
go
like
hunt
for
that
genre
of
problem
everywhere
and
then
catalog
and
document.
B
Okay,
like
this
is
the
state
of
things,
and
this
is
roughly
how
we
can
understand
and
talk
about
these
things
before
you
can
identify
patterns,
and
then
it's
like
okay
well
like
this
is
the
pros
and
cons
of
this
is
the
pros
and
cons
of
this.
This
is
meant
for
this.
Specifically,
we
should
support
this
use
case.
We
shouldn't
do
this.
A
A
Today,
where
things
are
relatively
stable,
but
those
are
also
like
the
the
things
that
the
worker
was
really
trying
to
work
on
is
what
you
just
talked
about,
which
is
all
these
things
that
are
messy.
How
do
we
unify
them
and
simplify
them
right,
and
so
you
know
how
do
we
build
people
up
to
where
they
are
doing
that
work
going
in
looking
at
all
the
different
ways?
The
projects
have
done
it,
refining
the
solutions
and
coming
up
with
sort
of
the
opinionated
right
way
to
do
it
for
kubernetes.
C
I
mean
this
could
be
part
of
the
of
the
work
here.
You
know
I
mean
like
when
we
say:
okay,
we're
gathering
some.
You
know
areas,
maybe
creating
some
issues
pointing
to
mentors
some
mentors
to
them.
We
could
say
you
know,
look
there's
this
one
area,
why
don't
we
or
like
this,
this
person?
Who
knows
the
best
of
it?
Why
can't
you
try
write
down
a
little
bit?
You
know,
how
does
it
work
have
some
links
to
it
for
some
people
to
understand?
C
What's
the
current
state
and
then
also
discuss
inside
the
working
group?
Where
do
we
want
to
go
from
there?
Have
there
be
some
prs
in
that
area?
You
know
put
it
in
the
dark
and
then
iterate
on
that
you
know,
and
you
can
have
it
in
the
google
doc
and
when
things
change
just
update
it
and
you
link
to
it
and
then
people
who
we're
not
familiar
with
to
work.
You
just
look
at
it
and
say:
okay.
This
happened
here.
This
happened
there.
This
is
what
I
thought
of
it.
A
A
Cool,
I
think
we've
got
some
good
ideas.
I
like
I
definitely
like
sending
out
kind
of
an
announcement
lee
where
we
kind
of
can
organize
the
work
that
needs
to
get
done
and
say
hey.
We
need
help
with
these
we're
willing
to
mentor
you
if
you're
new
to
the
project
or
you'd
like
to
contribute,
get
some
coaching.
A
D
Another
another
idea,
kind
of
kind
of
more
of
a
request
that
I
wanted
to
draw
out.
There
is
that
every
now
and
then
I
see
the
I
see
on
pr's
and
issues
that
people
ping
they
I
forget,
the
actual
the
exact
name
of
the
github
group
is
something
like
component
standard
pr
reviews
or
something
is
there
any
chance
that
we
could
be
added
to
those?
A
D
B
Okay,
well,
we
have
five
more
minutes
of
this
meeting,
I'm
happy
to
work
on
the
dx
of
all
of
this
in
the
contributor
experience
stuff
after
some
whip.
So
right
now
I
can't
do
this,
but
I'm
I'm
happy
to
jump
on
and
help
out
if
anyone
else
wants
to
do
project
management.
Stuff
pick
me.
A
I
don't
know
if
you
were
planning
on
going,
but
there's
the
community
meeting
on
the
26th
that
we're
scheduled
for
a
sig
update.
So
if
we
could
put
something
together
by
then
even
it
doesn't
have
to
be
like
totally
well
formed.
It
could
just
be
a
plan
that
we're
thinking
about
that
might
be
good,
so
we
can
discuss
it
with
you.
B
Okay,
I'll
put
that
on
my
list
for
next
week.
Let's
make
sure
we
hit
alex's
points
here
on
multi-dot
refactoring
and
the
strict
sterilizer.
C
So
just
real
quick
yeah
last
week
lee
and
I
we
had
some
like
rather
long
session,
diving
a
little
bit
into
the
code.
C
We
identified
three
different
implementations
in
the
code
base
which
handles
multi-dog,
so
my
plan
is
to
just
you
know,
take
them
see
what
our
workflow
is
and
basically
the
ultimate
goal
is
to
find
some
sort
of
workflow
or
abstraction,
which
we
can
add
to
the
codec
factory.
Ideally,
you
know
using
one
of
the
three
seeing
what
the
what
workflow
is,
what
the
limitations
are
on
those
basically
moving
forward
and
then
another
thing
or
is
there
any
any
questions
so
far
on
on
that?
C
Okay,
the
next
one
is
so
the
district
serializes
have
merged
and
I've
like,
while
looking
through
all
the
code
like
where,
where
where
like
the
code
factory
is
used
in
the
existing
components,
lee
suggested
that
you
know
I
make
some
patches
on
using
the
strict
serializer
on
the
component
configs,
so
I
just
wanted
to
yeah
throw
that
into
into
the
discussion.
If
that
is
a
good
thing,
if
I
should
work
on,
this
should
be
fairly
straightforward.
B
A
C
A
B
Something
to
be
careful,
there
is
like
looking
at
the
kublet
scheme
that
you
linked,
which,
by
the
way,
thank
you
for
linking
all
of
the
places
in
the
code.
That
is
significant
work,
the
oh,
that's
the
config
scheme,
yeah,
so
just
making
sure
I
guess
that
that's
not
used
for
the
kubelet,
like
parsing,
pods
and
stuff.
B
A
Cool
all
right,
well,
thanks,
so
much
folks,
we're
kind
of
out
of
time
here,
but
that
was
a
good
meeting.
I
think
we
got
some
really
good
action
items
for
the
working
group.
So
thanks
for
all
of
your
input
and
see
you
all
next
week.