►
From YouTube: Kubernetes WG Naming Meeting 20200914
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
A
It's
lovely,
to
see
you
again
just
to
restate
this.
Our
working
agreements
are
as
follows.
First,
off
before
adding
an
item
to
the
meeting
agenda,
please
initiate
a
discussion
on
the
mailing
list.
First
to
ensure
that
we
have
the
time
to
let
the
discussion
play
out
and
that
the
right
parties
are
engaged.
A
Please
focus
efforts
on
focus
your
efforts
on
things
that
are
underway
and
concrete
proposals
that
we've
decided
to
action
on
as
opposed
to
proposing
new
things
constantly
in
general,
please
favor
work
on
updating
language
in
the
projects
over
discussion
whenever
possible,
favor
systemic
improvements
over
point
wise
decisions,
please
make
feedback
and
discussion
in
general,
constructive
and
respective
respected,
full
and
actionable.
A
If
you
have
a
comment,
try
slack
if
you
can
first,
so
we
don't
get
bogged
down
in
circular
discussions
and,
as
a
final
note,
this
working
group
is
here
to
make
decisions
on
language
for
the
kubernetes
sub
project,
rather
than
to
be
an
educational
form
for
language
issues
around
harmful
language,
systemic
racism,
inclusion,
the
value
of
diversity
or
other
kind
of
foundations
of
awareness.
A
So
please
kind
of
keep
those
baseline
discussions
to
other
to
other
forms.
Okay,
okay:
somebody
has
added
the
topic
of
moderation
to
the
agenda
and
I'm
hoping
that
they'll
speak
to
it.
B
Yep,
that's
me:
hi,
I'm
zach
celeste
set
expectations
for
our
time
together
so
wonderfully,
and
I
feel
like
this
is
almost
superfluous,
but
we
will
moderate
actively.
So
if
we
ask
you
to
wrap
up
a
thread,
please
do
make
room
for
underrepresented
groups
to
speak.
B
A
Okay,
thank
you
so
much
zach,
so
I'm
just
going
to
run
through
the
agenda
at
a
high
level
really
quickly,
because
these
things,
I
have
a
feeling
we're
going
to
get
into
overlapping
topic
areas,
and
I
want
to
just
remind
people
to
keep
discussion
to
the
discussion
portion
of
the
of
the
meeting.
So
we
have
a
couple
of
lazy
consensus
items
to
formalize.
A
One
is
around
blacklist
whitelist
and
changing
that
to
a
lawless,
denialist
or
allowed
nouns
to
nine
nouns,
and
we
have
a
half
decided
consensus
on
master
slave
in
that
we've
decided
how
we're
comfortable
referring
to
master
branch
going
forward,
but
I
don't
think
we've
quite
reached
consensus
on
a
replacement
for
master
slave
or
replacements.
A
A
side
note
that
I
have
here
that
lazy
consensus
isn't
ideal
for
this
task,
which
loops
down
to
one
of
our
open
discussion.
Questions
kartik
has
a
couple
of
agenda
items
around
one
thread
that
he
started
for
starting
the
conversation
with
or
the
suggestion
list.
If
you
can
cardik.
I
would
really
appreciate
if
you
could
link
the
discussion
from
googlegroups.com
here
as
well
as
a
way
to
popularize
the
existence
of
working
group.
A
Naming
the
two
items
that
I
personally
would
like
to
lead
a
discussion
are
are
one
on
how
we
record
our
recommendations
specifically
around
how
we
decide
consensus
and
what
our
kind
of
overall
approval
flow
is
for
the
community
as
a
whole,
and
the
second
thing
that
I
think
we
need
to
spend
most
of
our
time
on
this
meeting
probably
is
around
how
we
evaluate
language
and
what
we
think
is
important.
A
Okay,
sound
good.
If
so,
I'm
gonna
dive
into
this
first
topic
on
blacklist
whitelist.
B
A
So
the
second
thing
that
we
have
in
terms
of
things
that
were
kind
of
up
for
lazy
consensus,
so
master
slave,
is
a
bit
of
a
difficult
one,
because
there's
two
important
but
somewhat
tangled
meetings
there,
one
is
master
in
terms
of
master
key
master
branch
master
file
insofar
as
master
branch
for
our
github
repos.
A
A
A
F
So,
specifically
to
the
the
github
changes,
the
I
believe
some
of
the
plan
is
to
enable
prs
to
be
automatically
targeted
retargeted
to
the
renamed
branch.
I
think
that
would
be
primarily
what
we'd
want
to
wait,
for
there
are
some
changes
that
have
been
made
in
a
new
version
of
git
that
allow
you
to
change
your
that.
Allow
you
to
set
a
default
name
for
a
branch
upon
creation
of
the
repo,
given
that
all
of
our
repos
are
created
already.
F
We
we
can't
take
advantage
of
that,
but
I
would
say
for
again:
we
need
to
talk
about
what
it
looks
like
to
crystallize
a
recommendation.
While
we
did
just
approve
to.
We
have
not
really
talked
about
the
flow
for
doing
that.
There's
a
suggested
flow
below
and
more
discussion
to
be
had
on
that.
I
just
want
to
make
it
clear
that,
like
we
have,
I
guess
tentatively
approved
something,
but
not
yet.
H
A
Yeah,
that
would
be
very
helpful.
That
is
not
my
area
of
expertise
and
I
would
love
if
somebody
whose
area
it
was
closest
to
could
take
that
up
as
an
action
item.
I.
A
A
So
do
we
want
to
continue
talking
about
master
slave
at
this
point,
or
do
we
want
to
take
that
back
to
the
mailing
list?.
A
F
F
Yeah,
so
I
think
that
we
should
talk
through
some
of
the
recommendations
that
were
made,
but
I
think
that
any
conversation
about
making
a
recommendation
for
or
making
multiple
recommendations
for
a
language
change,
since
this
kind
of
falls
into
scope
of
multiple
recommendations,
depending
on
the
context,
should
be
prefaced
by
a
discussion
about
how
we
make
the
recommendation.
So
we
should
probably
do
the
open
discussion
thing.
First,
before
coming
back.
A
To
you,
okay,
I
think
that's
fair
and
I
think
the
the
thing
with
master
slave
too,
is
it
also
ties
into
how
we
are
choosing
to
evaluate
language
and
how
we
what
we
decide
we
want
to
move
forward
with,
because
I
think,
in
short,
some
of
the
suggestions
are
not
necessarily
much
better
than
master
slave
in
some
ways,
because
they
they're
personifying
code
in
weird
ways,
but
we
can
get
into
that
a
little
later.
Kartik
do
you
want
to
lead
the
discussion
on
this
next
bullet
point.
H
So
I'm
skipping
to
the
next
one,
then
yeah
for
the
popularizing,
the
existence
of
working
group
naming
so
I
work
within
the
same
countrybacks
upstream
marketing
committee,
which
is
part
of
a
subcommittee
sub
group
under
sick
country
backs.
So
we
have
a
project
called
contributor
tweets.
As
of
now
caislin
is
manually
tweeting
any
like
we
have
a
twitter
handle
called
k8
contributors,
so
we
tweet
on
using
the
k8
contributors
handle
and
there
is
always
a
friday
shout
out.
There
is
a
like
everyday
shout
outs.
H
H
Okay,
it
contributors
handle
is
for
the
k,
dev
community,
like
k,
devs,
basically
so,
like
I
briefly
touched
on
this
in
our
previous
meeting,
like
we
can
actually
popularize
this
via,
like
we
can
popularize
the
existence
of
working
group
naming
via
okay,
its
contributor
tweets,
so
that
if
anyone
wants
to
raise
an
issue
or
anyone
wants
to
join,
they
could
actually,
they
will
be
like
informed
by
the
street.
H
H
Hazeline
will,
as
of
now
will
manually
tweet
that,
like
what
is
the
content
you
want
to
tweet
about
working
group
naming
so
in
a
way
like
it
would
go
out
in
a
wider
group
of
audience,
and
I
guess
we
have
like
almost
more
than
let
me
quickly
check
like.
We
have
a
good
amount
of
followers
on
the
kids
contributors.
H
Handle
okay,
it's
just
829,
but
we
would
get
a
good
number
of
followers
for
that.
A
Yeah
thoughts,
everybody.
A
B
Celeste,
I'm
sorry.
I
want
to
raise
visibility
from
the
comments
smartness
asking
how
about
including
this
works.
This
group's
work
as
an
agenda
item
in
the
cncftoc.
F
Meeting
so
I
was
typing
up
something
on
that.
I
think
that
the
tfc
meeting
is
a
good
place,
but
it
is
maybe
not
the
best
place.
Initially.
We
have
an
issue
open
for
sig
contributor
strategy
on
the
cncf
level
to
talk
about
naming
as
a
as
a
topic
for
the
maintainer
circle.
So
maintainer
circle
is
intended
to
be
an
aggregate
of
energy
maintainers
that
wish
to
drop
by,
and
they
are
part
of
some
cncf
project
and
they
want
to
just
kick
around
ideas.
F
So
I
think
that
I
think
it
would
be
cool
to
have
some
discussion
there
before
we
bring
it
to
the
larger
today.
A
I
think,
in
terms
just
to
get
to
to
kartik's
specific
point
about
like
tweeting
it
out
and
maybe
engaging
with
upstream
marketing
as
well.
Maybe
let's
take
this
offline.
I
think
it's
not
a
bad
idea,
but
let's
talk
about
this
further
in
slack
sounds
good.
A
Two
kind
of
bigger
topic
items
recording
a
recommendation
so
as
a
working
group
to
give
a
bit
of
context
here
as
a
working
group,
we
do
not
own
code,
we
make
recommendations
to
the
steering
committee.
Who
then
takes
it
to
individual
sigs
and
says:
please
implement
this
suggestion.
A
So,
first
off,
does
anybody
not
know
what
an
architectural
decision
record
is?
Is
anybody
new
to
this
concept.
A
Yeah,
so
architectural
decision
records
are
effectively
a
set
of
documents
that
exist
usually
inside
a
github
repository
for
a
software
project,
and
they
are
designed
to
communicate
the
decisions
made
throughout
our
project's
lifetime
for
a
couple
of
reasons,
one
to
onboard
new
members
to
the
team
or
new
contributors
more
easily,
so
that
they
can
understand
why
the
software
is
in
the
shape
that
it's
in
to
understand
rationale,
particularly
when
you're
looking
at
old
code
and
going
like.
Why
is
this
the
way
it
is?
You
have
a
decision.
A
You
have
like
a
record
of
why
we
decided
it
was
the
way
it
is
and
see
to
sort
of
record
who
was
involved
in
making
the
decisions
and
what
we
thought
the
implications
were
versus
what
they
actually
ended
up
being
so
I'm
proposing
be
it's
another
way
of
thinking
about
it
is
it's
a
very,
very
lightweight
cap.
A
I
hesitate
to
throw
the
word
kep
in
there
whatsoever,
but
if
a
cap
is
like
a
small
to
medium-sized
essay,
an
adr
is
maybe
one
to
two
pages
typed
max,
like
they're
they're,
significantly
more
lightweight,
so
I'm
proposing
that
we
use
rk
community
repo,
create
a
sub
directory
called
recommendations
that
have
been
ratified
and
effectively
create
markdown
documents
that
have
a
title
like
old
term
to
new
term.
What
the
status
is
like.
A
What
the
recommendation
is
why
we
decided
to
make
that
recommendation
and
optionally
if
we're,
if
we're
feeling
extra
ambitious,
what
does
the?
What
is
the
implication
of
making
that
recommendation
like
what
are
the
downstream
changes
that
then
need
to
occur?
A
I'm
proposing
we
do
it
in
k
community,
because
that's
the
infrastructure
we
have
available
yeah.
I
noticed
that
steven
has
a
bunch
of
notes.
F
Yes,
so
the
notes
are
basically
based
on
our
chair,
sync
that
we
did
a
little
bit
back,
so
we
were
kicking
around
the
idea
and
we
kind
of
wanted
to
make
sure
that
our
thoughts
were
structured
before
we
came
to
the
meeting
with
us.
F
So
the
general
flow
or
suggested
flow
is
discussion
somewhere,
which
is
kind
of
already
happening
via
mailing
list,
slack
et
cetera,
the
leads
or
someone
files,
an
architectural
decision
record,
and
the
record
must
include
the
scope
of
the
change
right.
Whether
this
is
crossing
multiple
sig
boundaries.
What
have
you
who
essentially
who's
going
to
be
the
owner
for
this
change
right?
The
goal
for
us
is
to
make
recommendations
not
necessarily
handle
the
implementation
right,
potentially
give
guidance
for
implementation,
but
not
own
the
implementation
right.
F
The
record
is
essentially
on
hold
until
the
people
who
are
owners
of
those
areas
have
approved
it.
Kind
of
the
background
for
some
of
this
is
that
we
have
several
areas
in
the
project
where
recommendations
have
been
made
or
law
has
been
set.
Law
has
been
set,
whether
it
be
like
the
release
versions
or
stylistic
stylistic
requirements
for
certain
pieces
of
content
that
are
not
necessarily
as
visible
as
they
could
be
for
a
sig
release.
F
Example,
our
release
versions
are
documented
as
part
of
the
design
proposals
that
are
in
community,
which
are
deprecated
documents
right.
So
this
is
not
necessarily
a
canonical
place
for
people
to
go
to
view
this,
so
we
do
want
the
idea
by
having
it
within
having
it
within
k.
Community
within
our
directory.
F
Is
that
it's
sort
of
a
staging
area
for
these
thoughts
for
these
recommendations
for
these
pre-crystallized
and
approved
recommendations
before
they
go
into
a
canonical
place,
the
at
the
point
at
which
the
the
area,
you
know
the
scoped
area
people
approve
this
recommendation.
It
would
be
proposed
to
steering
if
steering
approves
that,
then
it's
you
know,
then
it's
something
that
we
have
to
consider
like.
Where
are
the
places
that
the
canonical
guidance
needs
to
live
right?
Is
that
you
know
is
that
in
the
style
guide?
F
Is
that
in
api
review
guidelines
so
on
and
so
forth?
Right
so,
depending
on
the
scoped
area?
It
will.
It
will
kind
of
determine
where
these
recommendations
might
live
and
then,
at
that
point
it's
on
the
scope
area
to
actually
do
the
implementation.
D
Okay,
I'll
ask
it
so
we,
if
some
of
the
recommendations
have
implementation
details
which
would
themselves
require
caps.
How
do
we
envision
that
sort
of
dovetailing
with
like
a
decision
or
a
recommendation
like
yeah,
I'm
just
trying
to
figure
out
how.
D
That
would
interact,
especially
if
it's
like,
like
there's
a
recommendation,
that's
accepted
or
approved
or
whatever,
and
then,
like
the
implementation
proposals
are
sort
of
stuck
in,
like
we
can't
figure
out
how
to
do
this
without
breaking
the
world
like
what
does
that
mean
smash.
A
D
Like
a
lot
of
the
things
that
would
be
considered
in
those
caps
like
okay,
how
do
we
get
from
where
we
are
to
where
we
want
to
be?
You
want
that
to
fold
back
into
the
recommendation,
or
at
least
be
into
that?
I
don't
know
just
trying
to
figure
out
that
interaction,
yeah.
F
And
zach
has.
B
His
hand
up
there's
a
great
question.
I
wonder
whether
it
might
be
best
to
make
our
recommendation
like
we
recommend
that
this
becomes
a
cap
and
that,
because
these
groups
are
the
owners
of
it,
that
they
own
the
cap.
B
Can
I
can
I
finish
my
thought,
please
thank
you.
Yeah
I
mean
there.
That
is
the
element
of
it
is
that
it
ends
up.
We
end
up
volunteering
people
into
making
caps,
which
is
gross,
but
I
mean
if
there
is,
I
mean
I
wonder
if
there's
just
if
there's
a
way
to
say
this
needs
to
be
a
cap
or
like
we
can't
do
this
work
without
a
cap
and
then
put
that
work
back
in
the
hands
of
steering
to
to
continue
that
discussion
and
stephen
has.
F
Ascend
so
yeah
this
is
so
part
of
the
suggested
flow.
Is
that
it's
that
the
adr
would
be
on
hold
until
the
scoped
areas
make
approve
it,
and
I
think
during
that
discussion
is
the
the
point
at
which
we're
like.
Oh,
this
seems
kind
of
big.
Maybe
this
needs
to
be.
Maybe
this
needs
to
be
something
else
right.
Maybe
this
needs
to
be
a
cap.
Maybe
this
needs
to
be
strewn
into
a
process
that
that
we
don't
have
direct
ownership
of.
A
Yeah
so
I
think,
to
put
steven's
words
in
a
slightly
different
configuration,
and
I
apologize
for
interrupting
you
by
the
way
zach.
A
There
are,
I
think,
this
actually
came
a
little
bit
out
of
cardik's
email
thread
where
some
of
the
scope
of
the
changes
that
he
was
suggesting
were
more
scopes,
say
towards
docs
and
community
than
they
were
towards
code
bases.
A
And
I
think
the
idea
is
if
we
make
a
recommendation
understanding
what
the
scope
of
that
recommendation
is
and
like
who
we
want
to
actually
be
an
implementer
and
then
seeking
those
people's
support
as
a
part
of
the
process.
Maybe
of
approving
a
recommendation
for
ourselves
because
yeah
you
don't
really
want
to
be
making
a
bunch
of
decisions
without
taking
other
people's
input
and
at
some
point
we
do.
A
We
need
to
engage
the
broader
kubernetes
community,
like
we've
intentionally,
been
a
little
bit
private
about
it,
to
keep
the
discussion
well
moderated,
but
we
need
to
start
going
outwards,
and
I
think
this
is
the
best
way
to
do
it
where,
if
something
is,
for
example,
going
to
heavily
affect
the
api,
then
we
need
to
ask
sig
api.
How
do
you
feel
about
this
like
we're,
making
this
recommendation
for
kind
of
the
emotional
health
of
the
community,
but
it
is
going
to
have
a
big
impact
on
you.
F
B
So
my
concern
about
that
is
take
the
take
an
example
from
what
we've
already
seen
where
people
disagree,
whether
something
is,
for
example,
racist
or
not.
What
do
we
do
when
the
sig
leads
themselves
say?
No,
we
don't
need
to
do
that
or
we're
trying
to
de-prioritize
this
work
or
in
the
case
of
a
sig
that
is
already
shorthanded.
B
F
So
I
I
maybe
we
can
loop
back
into
that
for
the
guidelines
and
language
evaluation
framework.
Some
of
the
things
that
jase
had
suggested
offline
were
essentially
to
minimize
conversation
around
potentially
emotional
subjects,
even
prior
to
getting
to
the
so
finding
finding
ways
to
say
like
okay,
something
is
something
less
clear
than
it
could
be
right.
That's
that's
an
axis
that
we
could
potentially
judge
language
on
before
we
get
to
harm,
and
is
that
a
good
idea
right,
but
I
don't
want
to.
D
Topic,
I
was
just
gonna
say
I
think,
there's
value
in
making
a
recommendation,
even
if
we
don't
have
a
clear
picture
of
how
to
deal
with
existing
use
like
we're
all
it's
useful
to
have
thoughts,
written
down
and
centralized
and
for
people
who
are
doing
new
things.
You
know,
if
someone's
doing
something
new,
it's
useful
to
maybe
avoid
making
something,
making
the
same
mistake
that
was
made
in
the
past
and
so
a
process
that
lets
us
make
a
recommendation
to
help
inform
future
directions
seems
useful.
D
I
wouldn't
block
that
on
having
every
last
thing
figured
out
for
all
existing
instances,
so
maybe
a
way
to
think
of
it
would
be
to
say
this.
This
is
our
recommendation.
Here's
existing
things
that
we
would
like
to
correct.
We
don't
know
if
or
how
to
do
all
of
that
yet,
but
if
you're
coming
up
with
something
from
scratch,
take
this
recommendation
into
consideration
that
seems
valuable.
B
I'm
sorry
I'm
sorry,
I'm
so
sorry,
I'm
behind
in
note
taking
jordan.
Can
you
repeat
your
point,
I'm
so
sorry
to
ask
it,
but
can
you
repeat
that
again
sure.
D
I
would
not
want
to
block
recording
a
recommendation
on
having
every
last
bit
of
dealing
with
existing
uses
figured
out.
It
seems
useful
to
record
a
recommendation
to
help
inform
current
and
future
work
and
avoid
making
mistakes.
D
F
Sorry,
just
to
clarify
that
statement,
it
wasn't
to
block
it
until
everyone
agrees
upon
it.
It's
to
block
it
until
the
stakeholders
of
the
scoped
area
decide
that
it's
okay
right.
So
if
that's
consensus
of
the
leads
for
some
say
grade,
I
think
you
know
the
conversation
that
we
had
in
the
past
about
api
review
right
and
how
a
lot
of
the
a
lot
of
the
guidelines
that
were
written
for
api
review
or
like
so
someone
doesn't
make
the
mistake
that
I've
made
in
the
past.
F
D
Yeah,
just
one
follow-up
on
that,
like
our
our
guidelines,
are
full
of
here's
a
mistake
we
made
in
the
past.
You
can
avoid
it
this
way,
but
we
continue
supporting
existing
users.
D
Even
with
this,
like
horrible
mistake
of
a
api
field,
and
like
we
look
at
this-
and
we
see
it
was
a
problem
and
it's
ugly
and
we
hate
it,
but
we're
not
gonna
break
people
just
so
we
can
clean
up
our
api,
and
so
I
I
would
want
to
make
sure
that
saying
this
seems
like
a
good
recommendation.
D
We
definitely
would
avoid
that
in
the
future,
let's
think
through
how
we
can
improve
what
we
have
now
like
those
seem
like
distinct
conversations
to
have,
and
I
don't
want
to
hold
up
like
current
and
future
improvements
based
on
not
having
a
clear
understanding
of
how
to
honor
our
commitments
to
our
existing
users.
At
the
same
time.
So.
A
H
This
is
a
good
conversation,
so
what
I
was
going
to
say
is:
like
I'm
gonna
echo
jordan's
point
like
we
should
proceed
forward
like
we
should
move
further
to
record
a
recommendation,
and
probably
we
can
give
some
time,
let's
say
a
year
or
like
18
months,
or
something
like
that
to
see
whether
the
recommendation
has
been
implemented
or
recorded
completely
on
all
the
kubernetes
repositories,
and
there
are
like
a
lot
of
stuff,
like
new
contributor
workshops,
to
gain
a
lot
of
contributors,
traction
towards
every
each
and
every
single
c
community
and
working
group.
H
So
there
is
no
working
group
has
out
of
resources
forever.
I
mean
this
is
my
perception.
There
would
be
no
working
group
with
no
resources
or
no
bandwidth
forever,
so
maybe
probably
within
18
months
of
duration.
H
From
the
time
when
the
recommendation
has
been
approved,
every
single
six
should
be
kind
of
like
implementing
those
changes
or
the
recommendations
in
their
own
cigar
in
their
own
code
base,
and
probably
this
can
also
be
a
good
first
issue
for
people
who
is
coming
in
because
whoever
is
picking
up,
I
mean
any
contributor
who
is
picking
up.
They
are
actually
not
working
on
the
default
main
branch.
H
I've
moved
from
master
to
main
from
the
on
the
main
branch,
so
they'll
be
working
on
their
own
fork
and
we
have
our
end-to-end
test
coverages
to
verify
everything
is
perfect,
even
like,
before
getting
merged
into
the
main
branch.
So
there
is
a
good
catch
before
we
are
making
like
like
committing
a
terrible
change
into
the
main
branch.
So
even
this,
these
are
something
can
be
also
labeled
as
good
first
issues.
This
is
my
opinion.
This
is
totally
in
my
opinion,.
A
I
agree
with
the
idea
that
a
lot
of
these
are
going
to
be
either
good,
first
or
good
second
issues,
just
because
there's
you're
touching
a
lot
of
code
but
you're,
not
necessarily
like
implementing
a
new
feature.
I
don't
know
that
as
a
working
group,
we
can
specify
a
timeline.
In
fact,
I
am
pretty
sure
we
cannot.
That
would
be
up
to
steering
to
do,
but
that
is
something
that
we
can
work
with,
steering
to
decide
on.
A
F
So
so,
just
to
back
up
that
recommend
that
implementation
cannot
be.
F
F
I
think
again,
this
falls
to
the
scoped
areas
to
make
a
decision
on
what.
If
we're
saying
that
the
scoped
area
is
on
the
hook
to
do
the
implementation,
then
they
should
also
be
on
the
hook
to
provide
a
timeline
in
which
the
implementation
can
be
done.
If
we
see
that,
I
think
I
think
we
also
have
to
have
provisions
for
understanding
when
conflicts
arise.
From
asking
someone
some
scoped
area
to
provide
a
timeline.
F
I
think
that
those
are
the
kind
of
issues
that
can
potentially
be
escalated
to
steering,
but
I
don't
think
that
we
should
have
steering
entirely
in
all
of
this
flow
having
to
dictate
timelines
to
to
areas
that
have
a
better
idea
of
what
is
on
their
plate
for
a
cycle.
A
Okay,
I'm
I'm
actually
gonna,
say:
let's
wrap
this
discussion
up
just
because
we
are
running
running
through
our
time
slot
and
kartik.
I
super
apologize,
but
I
think
we
really
need
to
get
to
the
guidelines
and
kind
of
how
we
evaluate
language,
because
that's
going
to
roadblock
us
until
we
unblock
ourselves.
A
A
I
did
a
bit
of
research
on
this
and
I
have
some
thoughts
of
my
own
that
I've
discussed
with
the
other
leads.
However,
before
I
share
those,
I
would
like
to
open
it
up
to
the
floor
and
hear
what
everybody
else
has
to
say
in
terms
of
what
do
we
think
is
important
to
account
for
when
we
take
a
look
at
a
term
like
say,
master
slave.
C
Yeah
we
did
a
similar
exercise
within
our
own
company
and
it
was
coming
up
with
categories
of
bias
and
types
of
eyes
that
might
exist,
and
we
also
had
a
group
of
people
who
represented
a
lot
of
different
minority
statuses,
who
helped
select
those
names
and
those
replacements.
I
think
using
categories
and
kind
of
enumerating
them
out.
I
posted
in
the
google
group
the
one
that
we
used
from
apa,
and
I
thought
that
was
a
great
resource.
C
A
And
I'm
just
going
to
throw
a
link
to
that
in
the
chat,
because
I
happen
to
have
it
open.
I
believe
it's
that
one
right,
yeah,
yeah
yeah,
so
there's
that
and
I
posted
in
slack
a
few
weeks
back
shopify-
has
a
really
really
useful,
at
least
for
me.
A
I
found
it
really
really
useful
to
think
about
in
terms
of
they
have
this
idea
of
a
name
or
a
phrase,
being
descriptive
versus
being
evocative,
where
I
think
our
our
kubernetes
in
universe
example
of
that
is
what
was
once
known
as
pet
set
and
is
now
known
as
stateful
set
pet
said
is
evocative.
A
It
evokes
a
pet
that
you
take
care
of,
and
you
have
to
maintain
its
state
in
a
certain
way,
and
it's
this
cute
little
thing
versus
stateful
set,
which
describes
specifically
what
this
set
is.
It
is
stateful
in
the
way
that
we
say
computing.
Things
are
stateful
and
I
think
that
that's
like
for
me
is
a
really
crunchy
thing
to
think
of
because
it
makes
it
very
discreet.
A
A
B
B
So
I
think
that's
an
important
question
to
keep
at
the
top
of
the
discussion
is
who
is
harmed
if
this
language
remains
the
same?
Who
is
harmed
if
it
changes.
A
And
I
think
another
thing
that
you
mentioned
at
some
point
during
one
of
our
discussions
is
the
idea
of
humanizing
people
rather
than
humanizing
computer
components,
which
I
think
is
the
same.
A
A
A
Oh,
that
was
that
was
somewhat
intentional.
I
was
gonna
take.
I
was
gonna,
write
down
a
few
notes,
so
the
idea
that
I
have
oh
stephen
do
you
want
to
go
you're
just
you're,
just
thinking,
okay,
I.
A
No,
I
you
should
go
first,
because
I
was
gonna
launch
into
what
we
talked
about
prior
to
this.
F
C
So
so
I'm
cool,
of
course,
with
doing
adrs.
That's
actually
what
I
use
internally
everywhere.
So
are
we
gonna
call
them
architecture,
design,
recommendations.
A
I
think
we're
gonna
call
them.
I
think
we're
gonna
call
them
probably
just
recommendations.
C
And
I
I
was
wondering
you
know:
if
you
start
with
that
steven,
it
might
be
helpful
if
it's
already
somewhat
in
a
kept
format
more
than
an
adr,
so
that
the
template
we
start
with
you
know.
Normally
you
have
the
adr,
one
use
adrs
and
then
adr
two
would
be
your
first
recommendation,
probably
master
slave
for
us,
but
I
think
that'll
make
the
transition
going
from
the
recommendations
to
formalized
caps,
because
somebody's
gonna
have
to
do
that.
Translating.
F
Yeah
for
sure,
I
think
I
think
that
I
wanted
to
make
a
point
about
what
you
had
proposed
to
the
mailing
list.
F
It's
really
cool
to
see
that,
especially
if
you
were
not
sure
if
you
had
a
chance
to
come
to
the
first
meeting,
but
what
I
proposed
is
eventually,
we
would
maybe
see
pre-submits,
automation
and
stuff
that
would
lend
itself
to
language
correction
and
the
format
that
you
proposed
looks
a
lot
like
camel.
F
A
Nice,
nice,
nice
cool,
so
thank
you
for
looping
us
back
around
to
consent
that
we
are
consenting
to
to
a
proposal:
okay
to
kind
of
jump
back
down
a
little
bit
around
guidelines
and
language.
So
the
leads
had
a
talk
prior
to
this
meeting.
A
To
organize
our
thoughts,
and
by
our
I
mean
mostly
mine-
and
I
think
what
makes
what's
probably
going
to
make
the
most
sense
for
us
is
if
we
think
about
this
almost
as
a
decision
tree,
half
decision
tree
half
rubric,
and
that
also
gives
us
a
format.
That's
going
to
be
really
portable
for
when
this
working
group,
eventually
disbands
and
the
owner
of
these
kinds
of
decisions
is
not
us.
They
have
a
very
portable,
easy
to
understand
format
for
doing
this.
What
makes
most
sense
to
me.
A
Is
to
kind
of
drill
down
into
whether
something
is
harmful?
So
I
think
the
first
question
that
makes
sense
to
me
is
is
asking:
is
this
again?
Is
it
evocative
or
is
it
descriptive
because
descriptive
language
is
not
is
usually
less
harmful,
but
evocative
language
can
get
to
a
place
of
harm
pretty
quickly,
so
is
it
descriptive
or
evocative?
If
it's
evocative,
does
it
does
the
language
or
the
term
for
lack
of
a
better
word?
Does
it
have
a
bit
of
baggage
with
it?
A
A
A
Does
it
have
weird
colonial
or
historical
context
when
you
start
to
look
at
that
word,
the
more
baggage
a
word
has
the
higher
its
chances
that
it
is
something
that
we
need
to
change.
So
that's
that's
my
working
model
right
now.
It's
a
kind
of
two
level
decision
tree.
A
E
D
F
So
this
went
into
so
part
of
that
discussion.
I
I
was
was
pondering
whether
it
makes
sense
to
look
at
these
as
multiple
axes
right
as
opposed
to
just
strictly
a
decision
tree.
Multiple
decision,
trees,
folding
into
a
final
decision-
and
I
don't
know
if
that
becomes
a
scoring
system
or
something
right.
F
Yeah
is
that
too
big
for
us
to
do
and
the
score
changes
over
time
potentially
so
like?
Is
it
a
good?
You
know,
but
I
think
I
think,
having
multiple
axes
and
say
like
this:
is
you
know
this
is
potentially
harmful
or
this
is
or
this
is
not
descriptive
right
and
saying,
like
it's
checking
multiple
boxes
right
as
opposed
to.
We
didn't
even
assess
this
box
because
it
checked
one
box
at
the
top.
A
G
So,
like
the
one
thing,
I'm
just
thinking
is
also
to
make
it
as
simple
as
possible
right
because
we
we
need
to
like
come
up
with
a
recommendation.
We
need
to
like
to
talk
to
different
six
to
get
more
input.
So
I
would
also
make
this
as
simple
as
possible
and
I'm
wondering
we
already
have
a
few
recommendations.
G
Maybe
what
we
could
also
do
is
just
do
the
exercise
with
them
right
and
to
just
see
how
that
would
work
out
yeah
so
because-
and
I
don't
think
every
every
case
needs
to
fit
all
the
boxes,
and
I
think
that's
we
as
a
working
group.
We
just
have
to
say
okay,
even
if
it's
only
takes
one,
it's
a
really
important
box.
So
it's
still
our
recommendation.
G
I'm
not
sure
how
we
can
make
the
whole
process,
but
we
should
still
have
some
kind
of
checklist
and
it
needs
to
evolve
over
time
anyway,
and
we
are
just
starting.
So
I
would
prefer
to
have
it
a
bit
more
lightweight
and
then
get
more
complete
more
cases.
You
have
right
mom,
we
don't
have
a
lot
of
cases
assuming
they
here
come.
A
Yeah,
I
I
super
agree
with
that
as
well.
I
think
that
was
a
good
suggestion
in
terms
of
it's
a
list
of
characteristics
that
we're
looking
for
that.
I
think,
if
something
hits
one
or
more
of
those
characteristics
there's
a
chance
that
it
is
a
harmful
piece
of
language
that
we
need
to
remove
the
more
of
those
it
checks,
probably
the
more
harmful
it
is.
I
I
You
can
definitely
do
an
and
or
I
can
see
how,
over
time,
if
we
add
to
this
list,
it
could
get
a
little
more
complicated,
but
I
mean
I
think
it's
a
it's
a
it's.
It's
a
good
point.
I
don't
think
it'll
confuse
that
many
people,
that's
that's
kind
of
what
I
wanted
to
say.
I
I
do
think
that
you
don't
have
to
have
a
hierarchy
just
to
make
it
simpler.
I
H
A
Yeah,
I
think
so
and
I
think,
as
an
action
item
for
this,
I
will
open
up
a
thread
in
the
mailing
list
which
summarizes
this
so
that
we
can
digest
it
at
will
and
in
the
last
five
minutes,
and
I
apologize
for
giving
you
so
a
little
time
card
tick.
Do
you
want
to
talk
about
the
last
bullet
point
here.
H
Sure
so
that
was
following
up
with
the
first
introduction
of
celeste.
Is
my
mail
about
master
slave
and
whitelist
blacklist.
I've
also
like
kind
of
created,
a
small
list
which
would
actually
in
in
this,
is
totally
in
my
opinion.
When
I
looked
at
it
as
a
non-developer,
I
would
totally
consume
that
as
a
harmful
statement,
but
there
are
like
a
lot
of
responses
to
that
which
are
totally
legit
response
like
few
words,
which
cannot
mean
harm.
H
Those
are
just
purely
intended
for
coding
purposes,
let's
say,
for
example,
the
black
hole.
You
know
in
networking
terminology
black
hole
means
like
intentionally
I
mean
the
packets
are
dropped
or
like
kind
of
orphaned,
but
the
word
black
doesn't
mean
a
racist
word
there.
So
that's
sorry,
that's
one
of
the
words
I
added
there
and,
along
with
that,
like
I
had
like
few
other
words,
and
my
intention
there
was
to
for
the
like.
H
My
original
assumption,
probably
might
be
wrong
was
to
provide
a
kind
of
a
list
and
the
recommendations
for
both
for
anyone,
who's
affiliated
in
any
way
with
kubernetes
community,
like
maybe
a
speaker
or
maybe
a
developer,
or
maybe
a
tech
writer.
So
we
should
provide
them.
Okay,
if
you're
a
speaker
even
then
you
should
actually
oblige
whatever
the
recommendations
we
have,
you
must
not
use
blacklist
and
so,
for
example,
in
one
of
my
thread,
I'm
searching
through
that.
H
So
I've
said
like
there
are
maybe-
and
there
is,
must
not
so
you
could
use
black
hole
like
I
totally
forgot.
I
am
totally
lost
with
there
so
say,
for
example,
the
freshman.
H
The
freshman
is
something
you
could
use
if
you
are
representing
yourself,
if
you
are
designating
yourself,
but
you
cannot
use
freshmen
to
call
someone
else
in
the
community
because
you
might
not
know
whether
you're
offending
or
not.
So
as
a
speaker
when
you
are
doing
it
yourself,
you
may
use
that
as
a
developer.
When
you
are
raising
an
issue
or
when
you
are
like
doing
a
coding,
you
may
use
it
for
your
own
representation,
but
you
must
not
use
against
the
community
or
something
like
that.
So
that
was
one
among
the
idea.
H
I
had
like
an
inclusive
guidelines
for
both
speaker
and
the
developers
or
anyone.
As
a
matter
of
fact,
anyone
who
is
affiliated
with
the
kubernetes
community
so
I'll
I'll
cut
short
here
I'll
stop
here.
F
Stephen,
so
I
think
this
is
awesome
personally,
the
the
the
thread
that
you
put
up.
F
I
would
ask,
I
guess,
for
future,
just
general
guideline,
if
we're
discussing
something
if
we
can
try
to
segment
the
discussion,
because
I
think
a
lot
of
good
ideas
were
proposed
in
the
thread
but
they're
all
like
kind
of
forky
right
like
one,
is
a
set
of
recommendations
but
for
multiple
terms,
there's
a
framework
for
potentially
proposing
recommendations
or
aligning
people
to
the
kind
of
proposals,
and
then
there's
also
like
a
separate
discussion
about
how
we
may
socialize
some
of
the
stuff,
but
also
how
people
should
implement
them
in
the
community
right.
F
So
there
are
a
few
different
things
and
I
think
this
got
bogged
down.
I
think
it's
a
great
discussion,
that's
being
had
on
the
mailing
list,
but
it
got
bogged
down
by
like
multiple
thoughts.
A
Yeah,
that
was
gonna
actually
be
my
piece
of
feedback
for
you
too,
as
lokartik,
where
I
think
I
think
at
this
point
we've
crystallized
like
what
kind
of
recommendations
we're
gonna
make
or
like
we're
getting
there
and
like
what
a
recommendation
is
going
to
look
like,
and
so
I
think
maybe
the
best
option
is
if
you
can
start
to
split
out
your
existing
thread
into
smaller
threads,
so
that
we
can
parse
decisions
one
by
one,
stephen.
F
Oh
last
thing
promise,
hopefully
so
a
suggestion
I'd
made
was
we
have
an
issue
template
right,
our
create
an
issue
template
right
once
we've
gotten
to
a
point
where
we're
discussing
some
of
these
things
make
it
clear
that
there
is
a
way
to
a
more,
maybe
more
formal
way
of
of
doing
the
discussion
right.
So
maybe
it's
an
issue
template
and
then
you
come
back
that
way.
You
can
seed
a
bunch
of
these
potential
recommendations
for
discussion
before
we
start
formalizing
them.
A
F
E
E
I
was
going
to
propose
rather
than
harm
as
a
first
order
metric.
Perhaps
impact
there's
multiple
aspects
of
impact
harm,
though
I
think
should
be
an
outweighted
one.
This
has
been
discussed
previously,
but
there
are
going
to
be
cases
where
code
change
impact
as
jordan
was
describing,
may
come
to
a
place
where
a
sig
doesn't
want
to
change.
So
there's
various
levels
of
impact
that
need
analyzed
for
a
decision
outcome.
F
So
I
will
say
we
are
over
time
yeah.
So
are
there
any
final
thoughts
before
we
close
up.
A
Cardiac
did
you
have
something
to
say
just
prefer
to
go?
No,
no,
okay,
cool!
Thank
you!
So
much
for
a
lovely
discussion.
Everybody
please
be
active
in
slack
on
the
mailing
lists
and
I'm
going
to
stop
the
recording
in
three
two
one.