►
From YouTube: Kubernetes WG Naming Meeting 20201214
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
On
air,
hello,
everybody,
it's
december,
14
2020,
10,
35
a.m,
pacific
time-
and
this
is
the
monthly
working
group
naming
meeting-
I'm
lost
morgan.
I
am
one
of
the
leads.
The
other
lead
on.
The
call
today
is
steven
augustus
just
quickly
going
over
the
working
agreements
for
this.
This
is
a
kubernetes
working
group
meeting.
It
therefore
abides
by
the
kubernetes
code
of
conduct.
A
A
Favor
work
on
updating
language,
favor
systemic
improvements,
please
make
feedback
constructive,
respectful
and
actionable.
If
you
have
a
comment
generally
try
the
chat
first,
so
we
don't
get
bogged
down
in
circular
discussions.
However,
it's
a
pretty
small
group
today,
so
I
think
we're
going
to
be
okay
on
that
and
the
working
group
is
not
necessarily
here
to
educate.
We
are
here
to
make
changes,
okay,
cool.
A
A
The
one
status
update
that
I
have
for
all
of
you,
because
we've
talked
about
this
for
the
past
two
meetings
is
in
january.
These
are
going
to
be
bi-weekly
meetings,
specifically
just
to
get
the
cadence
of
work
going
a
little
bit
faster.
We
initially
set
the
meeting
cadence
for
once
a
month,
because
the
leads
were
very,
very
busy
and
now
I'm
hoping
to
kind
of
get
more
work
done
so
wrapping
the
cadence
tell
all
your
friends
any
questions
or
comments
on
that
three,
two
one:
okay,
stephen!
B
Sure
thing
I
think
one
one
note
as
well
for
the
class
group
is
that
we
just
had
the
inclusive
naming
initiative
meeting
and
we
are
also
working
on.
So,
as
you
may
know,
the
kubernetes
working
group
naming
is
part
of
the
inclusive
naming
initiative
kind
of
from
the
open
source
angle
of
it,
and
we're
starting
to
work
on
building
out
work
streams
for
that
initiative.
B
Kind
of
somewhat
modeled,
after
some
of
the
way
that
we
organized
as
cigs
within
the
kubernetes
community,
so
kind
of
slicing
across
the
vertical
efforts
which
are
going
to
be,
how
do
we
handle?
How
do
we
handle
change
in
open
source
projects?
How
do
we
handle
change
in
companies
and
how?
How
may
we
handle
change
in
larger
standards
bodies
and
then
some
of
the
horizontal
or
process-based
efforts
which
would
be?
How
do
we
bring
new
people
into
the
group?
B
How
do
we
onboard
how
do
we
kind
of
do,
outbound,
coms
and-
and
how
do
we
maintain
the
whole
thing?
Who
is
responsible
for
that?
So,
if
any
of
those
efforts
also
the
actual
language
aspect
of
it,
I
love
that
I
left
it
off
of
the
initial
work
streams
thing
and
then
then
again
it
mentioned,
but
also
the
the
language
aspect
of
it.
How
do
we
evaluate
language
using
some
of
the
framework
that
we've
we've
built
out
here
in
kubernetes
working
group
naming?
But
how
do
we
you
know?
B
How
do
we
actually
get
experts
in
evaluating
language
on
board
and
how
do
they
do
those
things
and
then
put
those
recommendations
out
to
the
various
vertical
work
streams?
So,
if
that
is,
that
is
work
that
catches
your
eye,
let
us
know
come
hang
out
in
the
in
the
inclusive
naming
initiative
meetings
as
well,
since
everyone
loves
everyone
loves
doing
that
multiple
times
for
the
day
so
monday
is
monday
is
like
big
naming
initiative
at
energy.
B
I'm
in
the
future
baby
in
the
future
baby,
all
right,
so
we've
got
some.
We've
got
some
open
pr's
around
size,
okay,
make
it
larger.
A
A
Mentioned
icon
pr,
we
merged
christopher
rides
master
slave
to
primary
replica
in
my
sequel,
pr,
I
believe
the
next
one
down
for
coop
adm
went
in
for
120
and
that
is
now
merged.
A
The
120
pr's
got
merged
because
120
is
now
out
so
good
job
getting
stuff
done.
Everybody
yeah!
Now,
let's
talk
about
what's
what's
in
progress
all
right,
so
if
I
recall
correctly
more
than
a
few
of
these
are
aaron
krickenberger
prs
that
are
on
hold.
So
I'm
thinking.
B
Well,
yeah
we'll
tag
him
for
more
more
reviews.
I
can.
I
can
do
that
all
right,
so
rename
master
test
integration.
This
is
within
the
integration
tests
and
kubernetes
kubernetes
the
outstanding
bits,
okay,
so
that
is
that
needs
a
rebase
since
120
went
out.
B
This
actually
should
not
have
a
120
restriction,
which
is
interesting.
Okay,
problem
for
a
different
time:
yeah
since
120
went
out
a
and
the
milestone
restriction
has
been
lifted
from
the
master
branch
in
kubernetes
kubernetes.
Large
swath
of
prs
will
have
landed
since
since
aaron
touched
this,
hence
the
rebase,
so
you
might
see
rebases
on
a
few
more
of
these
needs
rebase.
On
a
few
more
of
these,
this
one
yep
knee
3
base
knee
3
base,
probably
needs
rebase.
B
Okay
and
all
right,
so
the
next
ones
are
the
website
pr
from
pulsar.
I
believe
he
needed
assistance
picking
this
up.
Some
things
have
moved
forward
since
then,
like
the
creation
of
the
the
creation
of
the
staging
group
for
this,
and
what
remains
to
be
done
is
all
all
of
it.
Okay,.
A
B
Yeah,
I
think
I
think
that's
that's
what
it
is.
I
think
in
general,
this
is
yeah.
This
is
not
my
domain
specifically
to
make
this
suggestion,
but
in
general,
ideally,
we
can,
because
we
did
the
whole
chat
about
like
a
database
versus
a
cache
they're,
not
the
same
thing.
So
if
it
suits
the
needs
for
the
purpose
of
the
tutorial,
I
think
then,
the
net.
B
The
net
effect
is
that
we
want
the
tutorial
to
work
right,
not
necessarily
that
someone
be
trained
on
a
specific
technology,
but
more
so
that
they
be
trained
on
the
I,
and
rather
the
specific
technology
that
they
should
be
trained
on
is
kubernetes,
not
any
one
of
the
technologies
that
are
within.
C
A
A
Yeah,
I
okay,
so
I
will
take
the
action
item
to
bring
it
up
to
the
next
big
doc's
meeting
and
then
come
back
and
I'll
effectively
say
like
working
group.
Naming
has
has
kind
of
made
its
final
columns
more
comfortable,
but
there
is
a
fundamental
change
from
a
documentation
perspective
and
it's
in
y'all's
hands.
Now.
B
To
make
that
decision,
so
it's
very
possible
that
paul
may
not
have
the
time
to
actually
carry
this
across
the
finish
line.
I
can,
I
can
grab
the
pr
too.
I
think.
B
Paul
and
myself
I
may
be
the,
but
if
someone
else
wants
it,
they
could
absolutely
jump
in
so.
A
Let
me
let
me
round.
A
On
the
sig
doc's
pr
situation
first,
the
agenda
is
not
updated
jim,
so
let
me
ask
take
doc's
first
and
I'll
also
say
the
pr
is
very,
very
stale
and
we
don't
think
that
paul
is
going
to
be
able
to
actually
finish
it
so
because
that
is
typically
sig.
Docs's
responsibility
is
to
to
make
sure
that
mert,
like
sounds
scaled,
sounds.
B
A
A
B
All
right
so
guestbook
this
is
similar
the
same
pr,
maybe
in
different
repos
yeah.
This
is
similar
and
also
the
same
replacement.
Same
comments
were
made
around
redis
and
mongodb.
B
B
A
A
B
A
I
would
like
to
close
this,
so
we
have
an
adr
out
for
blacklist
whitelist.
This
is
a
little.
B
Too,
let
me
just
get
everything
open.
Do
you
want
to
hit
the
allowance
denialist
thing
first,
since
most
recent.
A
This
is
pretty.
This
is
almost
ready
to
go.
I
have
a
few
more
comments
from
kartik
that
I
need
to
address
manually
and
then
it'll
be
ready
for
a
final
review.
I
just
haven't
been
able
to
loot
background
to
this
yet
yep.
Oh,
that's!
Fine!
Children!
In
a
few
days.
B
Okay-
and
I
probably
owe
a
review
on
this
as
well-
yes,
okay,
all
right,
it
looks
like
you
did
address
some
of
them.
B
B
B
B
B
All
right,
so
all
right.
This
is
both
the
allow
list
deny
list,
plus
white
master
slave
and
okay
same
same
status,
since
the
master
stuff
is
already
in
progress
and
so
is
allows
denialists
I
spoke
to
this
is
changing
default
branches
to
maine
I
spoke
to
github
administration.
B
We
are
still
poking
at
that.
I
believe
the
I
believe
there
were
some
conflicts
for
the
last
github
administration
meeting
and
those
are
monthly,
so
there's
some
chatter
on
their
slack
channel,
but
we
need
to
circle
back
on
it.
Basically,
what
I
would
like
to
do
next
is
to
change
the
so.
The
interesting
thing
is
it's
very
likely
that
the
github
settings
for
our
orgs
are
already
configured
to
use
main
as
the
default
branch
for
new
repos.
B
So
that's
potentially
good.
If
that's
true,
I
know
it's.
I
know
it's
on
by
default
for
orgs
in
general,
unless
you
explicitly
use
something
else
right,
that's
a
configurable
thing
on
the
org
level,
so
that
is
good,
but
but
does
not
solve
our
problem
for
kubernetes.
B
B
So
we
need
to
see
basically
we're
waiting
for
confirmation
on
github
when,
for
all
of
these
things,
to
be
easier,
the
timeline
for
that
was
end
of
year
and
we
are
we're
at
the
end
of
the
year
just
about
so
it's
it's
time
for
check-in
again
here.
What
I
would
like
to
do
is
the
next
step
is
turn
on
main
for
for
the
kubernetes
template
project.
What
this
is
going
to
require
is
a
little
bit
of
spelunking
across
like
test
infra.
B
One
of
the
concerns
here
is
that,
if
we
will,
we
have
will
we
have
auto
redirects
from
master
to
maine
yeah.
If
that
is
not
true,
a
lot
of
things
fall
apart
on
the
on
the
ci
side.
So
we
need
to.
I
think
what
we
were
planning
to
do
is
get
kind
of
like
a
small,
medium
and
large
sized
orgs
repos.
B
I
keep
saying
orgs
repos
to
test
against
right
and
see
how
these
changes
impact
those
repos,
so
that
is
on
my
plate,
stay
tuned
for
more
details,
yep,
okay,
test.
A
B
Absolutely
sounds
good
all
right.
Any
other
questions
on
that.
B
Review
and
progress
these
this
is
the
tracking
issue.
It
looks
like
for
a
lot
of
the
prs
that
are
review
in
progress
touching
the
test
integration
folder,
so
we
kind
of
went
through
those
already,
and
this
is
did
I
open
it
twice?
I
guess
it
did.
B
Okay,
yeah
all
right
rename
this
this
is
in
flight.
A
lot
of
this
has
landed
for
120
already,
as
mentioned
earlier,
looks
like
docs
updates
may
be
the
thing
remaining
and
they
are
done
so
love
the
love
the
thumbs
down
on
that.
B
And
so
let
me
sync
up
with
lupimir.
They
probably
don't
need
any
guidance
here,
but
this
is
probably
close
to
ready
to
close.
A
B
A
B
I
would
leave
them,
as
is
the
in
review.
Column
is
usually
for
with
the
kanban
automation.
The
prs
are
the
things
that
go
into
the
review
in
progress
column,
okay.
B
This
is
again
related
to
you.
The
work
that
lubimir
and
crew
have
already
taken
up,
but
this
seems
like
it
cross-cuts
some
of
the
off
bits
as
well.
I.
B
B
B
Okay
same
story
with
the
test
folder
and
needs
a
rebase
another
aaron,
one
and
samesies
again.
B
B
B
So
celeste
has
the
adr
up
and
I
owe
feedback
on
the.
B
Cool
all
right
backlog
back
log.
You
know
this
is
actually
in
progress
really.
A
Speaking
of
the
backlog,
would
you
get
to
those
two
around
the
localizations
localization
yeah
at
the
very
bottom.
A
The
update
there
is
that
I
spoke
to
sigdocs
about
it,
who
spoke
to
the
localizations
about
it.
They
are
aware,
and
they
have
been
made
aware,
that
they
can
just
take
action
on
that
whenever
it
suits
them,
so
it
will
get
done,
but
on
somebody
else's
schedule.
A
B
A
Went
to
both
cool.
B
B
Right,
okay,
so
see
we
have
the
two
nebulous
ones
and
this
field
name
one
for
merge
warning.
This
is
potentially
not
too
hard,
not
too
hard.
B
But
because
it
is
a
change
to
a
exactly
yeah,
because
it
is
a
change
to
a
prowl
plug-in,
it
should
require
some
sort
of
deprecation
timeline,
because
we
are
not
the
only
ones
who
depend
on
prow.
So
did
we.
A
It
seems
like
the
last
update
is
the
announcement
to
stop
support.
That's
already
been
merged,
so
yeah
they're
they're
on
the
road
to
communicating
the
deprecation
policy
which
is
good
and
then
the
follow-up
is,
is
stopping.
A
B
A
Yeah
I
feel
like
this
needs
to
be
unpacked
a
little
bit
more.
This
is
another
one
of
those
ones.
I
think
there's
an
action
item
here,
but
it's
I
don't
think
the
action
item
is
just
removed
from
the
docks.
So
I'm
trying
to
think
what
does
the
unpacking
then
look
like.
A
I
think
what
it
really
is
is
try
running
an
alex
js
scan,
see
what
comes
back
and
then
farming
it
out
to
being
a
bunch
of
good
first
issues,
because
these
are
very
good
first
issues
I
think
yeah.
I
think,
there's
a
second
dependency
here
of
what
do
we
do
with
things
like
blog
posts,
but
I
think
that
is
a
sig
docs
question
at
this
point.
So
I
think
that's
another
thing
to
look
back
around
to
sig
docs.
B
Yeah,
I
would
say
that,
so
what
could
work
in
this
case
is
a
is
a
pre-submit
that
is
not
blocking
optional.
Pre-Submit
no
report
status
so
that
you
can
run
alex
js
without
having
to
impact
mergens
and
then
taking
that
data
back
to
an
issue.
B
At
the
same
time,
I
do
I
do
worry
that
well
rather
again
not
my
domain,
that
the
issue
is
sufficiently
unpacked
before
people
process
tools
right.
B
So
the
issue
is
sufficiently
unpacked
before
we
decide
on
a
tool
or
before
someone
decides
on
a
tool
whether
it
be,
I
I
think,
alex
js
is
one
of
the
few
things
I've
seen
in
the
space
serving
that
need.
So
maybe
that
discussion
is
had,
but
it
should
be
had
with
the
right
people.
A
Yeah,
so
I
think
I
wonder,
there's
a
couple
of
ways
to
slice
this
in
terms
of
tooling,
because
I
think
what
you're
trying
to
get
at
with
this
is
like,
and
now
let's
develop
some
automation
around
it
there's
a
couple
of
ways
to
slice
this
one
is:
we
can
potentially
just
go
ahead
with
alex
js
and
see
what
happens.
A
A
And
those
are
interesting
because
they're
customizable,
like
their
language
base,
is
customizable
and
you
can
implement
stacking
language
bases
to
check
against,
and
so
that's
typically,
what
a
documentation
team
will
do
if
they're
implementing
linting
is
they'll,
take
like
a
base
style
guide
like
google's
style
guide
and
then
they'll
add
their
own
customized
rules
on
top
of
it
and
then
they'll
add
like
like
accessibility
and
sensitivity,
oriented
like
dictionaries
to
it
as
well.
So.
C
B
So,
just
to
be
clear,
I
was
not
suggesting
any
automation
around
this,
just
in
just
adding
alex.js
or
existing
tools
to
the
pre-submits,
so
no
automation,
but
using
tools
that
we
know
work.
B
So
if
that
makes
sense
or
if
you
decide
that
it's
alex,
js
or
or
bale
just
saying
that
we
know
it's
a
discussion
that
should
be
had
in
sig
docs,
and
maybe
that
sets
the
stage
for
other
repos
picking
this
up.
B
We've
got
one
more,
it
is
the
inconsistent
use
of
the
term
resource
and
I
forgot
what
we
said.
We
were
going
to
do
with
this
one.
B
A
B
B
This
will,
I
will
okay,
no
response
from
sig
architecture,
yet
I
will
carry
this
to
a
sig
architecture.
Mailing
list
near
you.
A
A
Okay,
so
let's
kind
of
handle
our
open
discussion
items,
I'm
actually
going
to
rearrange
slightly
and
I
apologize
for
the
beeping
in
the
background
that
is
the
oven,
so
the
blacklist
whiteless
allows
nice
recommendation
is
almost
out.
That's
cool
kartik
is
not
here,
but
he
has
a
mailing
list
discussion
open
on
the
term
abort.
A
I
asked
jace
to
take
a
look
at
this
because
I
know
he
has
some
ideas
around
this,
but
in
general
I
would
like
to
call
attention
to
that,
and
I
would
like
to
suggest
that
as
the
next
adr
that
we
start
working
to
push
through
or
or
to
not
push
through
tldr,
please
take
a
link.
Look
at
the
link
in
the
agenda.
A
A
So
this
came
up
a
few
a
little
while
ago.
Now
it
was
a
comment
from
joyce
on
one
of
the
adrs,
which
was
very
insightful,
and
I
wanted
to
talk
about
it,
which
is
who
has
the
onus
of
figuring
out
downstream
effects
for
a
change,
so
we've
say
said:
okay
we'd,
like
you
to
use
control
plane
instead
of
master.
A
A
So
I
did
that,
for
I
did
that
for
the
blacklist
whitelist
one,
because
I
don't
think
that.
A
I
think
we
at
least
have
to
like
give
us
the
rough
shape
of
what
that
might
end
up.
Looking
like
first
off,
but
I
think,
there's
also
like
a
hidden
problem
in
here
as
well,
which
is
how
do
we
communicate
that
we
want
people
to
go
ahead
and
make
a
change,
because
right
now
we're
working
just
a
little
bit
in
isolation
and
we're
relying
on
people
to
come
to
us
as
opposed
to
going
outwards
and
saying,
go
forth
and
make
the
change.
A
So
I
guess
another
hidden
question
is:
do
we
need
to
start
communicating
say
to
kubernetes
dev
mailing
list
a
little
more
proactively
saying
like
this
is
a
change
that
we
recommend
you
make,
and
now
you
may
proactively
make
it,
as
you
require.
B
So
I
think
that
I
would
ask
first
what
is
downstream.
B
It's
it's
well,
I
I
asked
that,
because
we
have
multiple
hats
on
where
we
also
work
in
inclusive
naming
initiative
or
downstream,
depending
on
the
work
stream
is
going
to
be
different
things
right.
So,
if
we're
saying
downstream,
as
in
downstream
within
the
project,
that's
one
thing:
if
we're
saying
downstream
is
in
consumers
of
the
project.
That
is
an
entirely
different
ball
right,
so
I
think
clarifying
scope
before
we
do
anything,
I
do
think
that
one
of
the
goals
should
be
to
issue
these
recommendations
across
the
project
and
and
a
wider
mailing
list.
A
I
think
that
yeah
we're
kind
of
on
the
same
page
here
and
the
the
reason
that
I
bring
up
the
idea
of
like
communicating
out
to
the
mailing
list
more
is
like
we're.
Never
gonna
catch
every
edge
case
like
where
there's
no
possible
way
for
us
to
do
that
analysis,
even
though,
like
it's,
the
nice
thing
to
do
for
lack
of
a
better
word,
we're
never
going
to
catch
every
edge
case.
A
We're
never
going
to
figure
out
like
where
something
is
user
facing
versus
a
non-user
facing
change
like
that
has
to
be
up
to
the
code
owners
to
do
so.
How
about
this
as
an
action
item.
A
B
A
B
A
Okay,
then,
maybe
what
I'll
do
is
draft
up
a
communication
and
post
it
in
slack
instead.
A
A
A
Go
go
for
it.
Go
nuts
just
go
stephen
and
I
are
like
attendants
of
the
church
of
chaos.
A
So
my
my
gut
instinct
is
like
just
go
for
it,
especially
because
from
my
position
as
a
writer,
you
know
the
code
better
than
I
do
and
I'm
not
sure
being
systemic
is
actually
the
best
way
to
go
about
this
right
now.
C
B
So
so
I
would
say,
don't
discount
your
ability,
I
have
not
spent
time
on
a
kubernetes
cluster
since,
like
116
or
something
so
you're,
you
may
be
further
ahead
than
I
am
right.
I
think
that
proximity
to
issues
will
allow
you
to
determine
their
impact.
B
I
think
that
in
trying
to
be
too
systematic
about
certain
things,
I
do
like
a
little
chaos,
because
I
feel
that
the
the
things
that
are
important
will
bubble
up
right
like
if,
if
we
try
to
say
okay
well
this
this
cuts
across
this
axis,
this
cuts
across
us.
We
like
we
have
it.
We
have
a
an
evaluation
framework
for
these
things
already
right.
B
So
I
think
part
of
it
is
the
ones
that
you
feel
are
are
causing
impact,
so
just
sharp
eyes
as
you're
as
you're
going
through
the
code
base
is
really
one
of
the
asks,
I
think
from
the
external
side
as
we
I
was
talking
about
this
in
the
inclusive
naming
meeting
earlier,
as
we
introduce
more
people
to
this
effort,
whether
it
be
kubernetes
local,
are
on
the
wider
inclusive
naming
side.
B
People
have
been
jumping
onto
the
mailing
list
and
saying
hi
and
like
hey,
I'm
here
to
do
stuff,
and
I'm
like
that's
super
great,
but
we
want
to.
We
want
to
come
with
actions.
We
want
to
see
what
our
outcomes
need
to
be
right.
B
So
if
you
come
to
a
mailing
list,
getting
an
idea
like
this,
this
is
my
word
list
like
this,
or
this
is
the
work
that
we've
already
done
in
my
in
my
company
or
in
my
other
open
source
project,
and
maybe
maybe
something
cool
to
adopt
here
as
well,
right
so
being
able
to
kind
of
cross
cross-pollinate
that
information
and
just
I
I
think
it's
I
think
it's
just
awareness
right
you're
as
you
get
more
familiar
with
code
and
content.
B
You'll
you'll
have
a
pulse
on
where
certain
decisions
are
being
made
and
where
certain
people
are
making
them
and
the
kind
of
impact
that
they
have,
and
I
think
that
that
will
season
your
decisions
and
recommendation.
A
Okay,
so
I
think
that's
all
we've
got
for
now.
Do
we
have
any
final
questions
or
comments
for
this
meeting.