►
From YouTube: Kubernetes WG Naming Meeting 20200810
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
Computer
we're
live
hi
everyone,
it's
monday
august
10th
10,
30
pst,
and
this
is
the
inaugural
working
group
naming
meeting.
So
thank
you
very
much
for
joining
us
all.
My
name
is
celeste
horgan,
I'm
a
senior
technical
writer
working
at
the
cncf
on
cncf
projects.
A
A
But
it's
going
to
be
a
lot
of
talking
at
you
for
a
bit:
okay,
sound
good
everybody,
okay,
cool,
I'm
going
to
share
my
screen
and
I'm
going
to
share
it
to
the
agenda.
B
So
one
note
I've
popped
the
or
not
the
agenda
link
in
the
chat.
If
you
have
not
had
a
chance
to
put
your
names
on
it
and
say,
hi
say
that
you're
here
go
ahead
and
do
that
now.
A
Yes,
please
so
that
was
kind
of
our
introduction.
A
As
an
initial
focus,
we
are
focusing
on
anti-racist
words,
but
the
the
end
goals
are
much
broader
to
remove
both
violent
and
inaccurate
language
from
the
kubernetes
project
and
to
be
leaders
in
our
community.
In
that
regards.
A
A
As
a
broad
rule,
please
read
through
this
document
in
your
own
time
and
take
your
time
to
understand
it,
but
at
a
high
level
this
is
hard
work
to
do
and
it
brings
up
really
uncomfortable
conversations
for
people
and,
as
such,
it's
very
important
that
we
are
as
respectful
as
possible
of
each
other.
A
Per
that
being
inclusive
is
being
better,
is
better
than
being
exclusive
and
that's
our
guiding
principle.
I
think,
as
a
particular
note
to
the
naming
working
group
we're
working
with
language
and
we
are
working
in
a
space
of
anti-discrimination
and
anti-racism
and
it
behooves
you
to
either
have
kind
of
prior
experience
or
knowledge
in
that
regard
either
lived
experience
as
a
minority
of
some
sort
or
reading
from
our
handy
list
of
readings.
A
A
Please
do
not
concern
troll
and
there
is
a
lovely
link
there
explaining
that
term
we'll
go
over
this
shortly,
but
this
these
kinds
of
discussions
around
words
and
naming
and
is
something
offensive
or
problematic,
tend
to
get
a
little
long-winded.
So
we're
gonna
ask
that,
rather
than
use
this
time
to
discuss
things,
we
bring
things
up
in
the
mailing
list
first,
so
that
we
can
use
this
time
more
wisely.
A
And
to
that
note
please
be
mindful
of
not
derailing
discussions,
especially
in
person
ones.
Please
do
not
be
a
sea
lion.
This
is
a
really
very
entertaining
comic
and
you
should
all
take
time
to
click
through
it
and
please
do
not
brigade
there's
one
more
point
which
has
come
up
recently,
which
will
need
to
be
added
to
this
document,
which
is
please
don't
leave
anonymous
or
semi-anonymous
comments
on
things,
because
we've
already
dealt
with
this
kind
of
trolling
prior
to
even
the
kickoff.
A
A
A
little
bit
on
how
monthly
meetings
are
going
to
work,
we're
only
meeting
once
a
month
guys
and
that's
not
very
often,
so
these
meetings
need
to
be
more
of
a
status,
update
and
a
platform
to
make
final
decisions
on
things.
We
can't
do
asynchronously
rather
than
open
discussions,
as
I
mentioned,
and
we'll
go
through
the
working
agreements
after
this
in
general.
A
Please
start
discussions
on
the
mailing
list
so
that
everybody
has
time
to
really
work
through
the
discussion
rather
than
in
this
meeting,
because
these
discussions
get
long-winded
and,
as
I
mentioned,
anonymous
comments
are
probably
gonna,
get
moderated
pretty
heavily
yeah
jace.
You
want
to
talk
about
working
agreements.
C
Happy
too,
and
thank
you
for
kicking
off
the
meeting
and
thank
you,
everyone
for
attending.
It's
really
important
to
have
your
participation.
I'm
super
thrilled
to
be
seeing
so
many
folks
here
that
I
know
and
new
folks
as
well.
So
there
is
a
long
history
about
the
idea
of
working
agreements
and
the
first
real
project
inside
of
kubernetes
that
serve
did
this
was
city
architecture
and-
and
I
introduced
this
concept
some
time
ago,
because
we
were
having
very
long
contentious
meetings
that
had
a
lot
of
circular
discussions.
C
People
weren't
feeling
like
they're,
productive,
jordan
liggett
was
certainly
a
veteran
of
this
this
process
and
can
probably
speak
to
it
as
well.
But
essentially
the
idea
is
that,
by
participating
in
this
meeting,
we
have
a
shared
set
of
agreements
that
we're
enforcing
from
a
social
perspective.
So
it's
all
of
our
jobs
to
to
try
and
respect
these
and
to
uphold
these,
and
if
we
find
folks
who
are
sort
of
drifting
off
outside
of
these
agreements,
it's
important
for
us
to
share
that.
C
This
is
something
that's
part
of
participation
in
this
group
that
we
feel
is
important,
and
we
want
to
make
sure
that
everybody
is
on
board
with
that,
so
the
first
several
of
these
were
directly
cripped
from
sick
architecture
and
the
the
very
long
hard
learnings
that
we
had
there.
C
So
I
would
say,
go
ahead
and
read
these,
and
these
will
be
posted
at
the
top
of
the
document,
because
the
things
that
celeste
went
through
in
terms
of
why
we're
here
what
we're
trying
to
accomplish
and
so
forth,
we
won't
be
covering
that
every
single
time
we
meet,
but
those
things
are
always
really
relevant
to
the
way
the
meeting
unfolds.
So
these
working
agreements
are
just
a
reminder
before
we
record
the
meeting,
and
we
talk
about
all
that.
We'll
definitely
reiterate
that
you
know
these.
C
Our
meeting
is
under
the
auspices
of
these
meeting
agreements
and
that
if
you
participate
we're
asking
that
you
abide
by
them
as
much
as
possible.
So
that's
the
reason
that
we
have
those
and
it's
it's
certainly
something
that
I
believe
will
help
us
be
more
productive.
C
One
of
the
things
I
do
want
to
call
out,
though,
in
this
was
very
true
for
sig
architecture
as
well,
is
that
by
having
things
pre-vetted
on
the
mailing
list
and
in
text
it
it's
more
inclusive
one
because
time
us
being
able
to
meet
is
actually
a
privilege.
C
Many
people
can't
meet
because
of
reasons,
and
so
it's
more
inclusive
for
us
as
a
group
to
be
discussing
things
asynchronously.
So
we
have
to
get
really
good
at
that,
because
otherwise
we
won't
make
progress.
And
again
these
meetings
are
really
an
opportunity
for
us
to
get
together.
Convene
discuss
finalize,
maybe
have
some
some
discussion
around
things
that
are
particularly
deadlocked
in
discussion
so
anyway.
I
just
wanted
to
go
over
that.
C
If
there
are
questions
about
this
feel
free
to
direct
them
to
me
or
any
of
the
leads
and
we'll
we'll
go
there.
If
you
have
suggestions
that
you
think
should
be
added
to
the
working
agreements,
please
do
so
in
the
slack
channel
and
we'll
talk
it
over
and
go
from
there
that
good
any
questions
before
we
move
on.
A
Thanks
chase
yeah,
so
next
kind
of
section:
let's
talk
about
what
are
we
trying
to
do
here?
So,
amongst
the
leads,
I
think
we
agree
that
there's
two
major
areas
of
focus
for
this
group:
one
is
language
goals
and
one
is
kind
of
tooling
and
processes
to
maintain
a
space
where
we're
constantly
evaluating
the
language
we
use
and
making
sure
it's
as
inclusive
as
possible.
A
So
in
terms
of
our
language
goals,
what
we're
looking
to
do
is
to
remove
from
the
kubernetes
project
language
which
is
directly
offensive
or
harmful
to
certain
groups
of
people,
but
also
language
which
is
inaccurate
or
uses
metaphors
that
are
not
always
clear
in
things
like
translations
and
just
generally
make
the
project
a
better
place.
A
What
I
think
the
final
output
of
that
will
be,
and
I'm
let's
talk
about
it
after-
is
effectively
a
list
of
recommendations,
stations
saying
instead
of
this
term,
use
this
other
term
and
here's
our
reasoning
behind
it
and
again
we're.
I
think,
we're
absolutely
open
to
ideas
as
to
how
and
where
that
should
live
and
what
that
should
look
like.
A
So
that's
the
high
level
language
goal.
Steven
wanna
talk
about
the
other
half
of
this.
B
Yeah,
so
I
think
in
this
we
we
want
to
try
our
best
to
apply
processes
and
procedures
that
the
community
is
already
accustomed
to
to
make
some
of
these
transitions
a
little
easier.
I
think
that's
one
of
the
things
that
we
were
chatting
about
is
there
are
some
there's
some
immediate
goals
that
we
have
there's
some
some
longer
term
goals
and
there
are
going
to
be
some
trailing
things
that
we
want
to
take
care
of,
so
so
certain.
B
So
what
I
see
pretty
often
is
that
when
we
do
reviews
for
prs,
we
occasionally
run
into
common
typos
or
grammatical
errors
that
can
be
fixed
with
tooling
right.
So
one
of
the
initial
ideas
I
had
was
pre-submits.
We
already
use
pre-submits
for
a
lot
of
things.
We
have
repos
that
we
leverage
for
kind
of
cross-project
uses
like
repo
infra
are
our
containers
that
we
leverage
for
for
these
purposes.
B
So
something
that
comes
to
mind
is,
as
we
think,
about
a
set
of
appropriate
or
inappropriate
words.
We
can.
We
can
aggregate
a
set
of.
We
can
aggregate
a
word
list
essentially
right
and
move
to
the
point
where
we
can
run
some
pre-submits
on
certain
repos
that
that
can
basically
advise
you
like
hey.
This
is
this
is
a
this
is
a
a
word
that
may
not
be
a
word
that
you
want
to
include
in
your
arena
right.
So
I
see
this
happening
in
multiple
phases.
B
I
think
that
this
is
something
that's
is
near
and
dear
to
jace
and
and
a
lot
of
the
people
in
in
the
project
that
it's
it's
people
process
and
then
tools
right.
So
we
don't
want
this
any
tools
that
we
implement
to
proceed,
discussing,
how
how
process
should
be
developed
and
and
the
right
people
that
should
be
in
the
room,
but
just
to
you
know
a
preamble
to
this
tools.
B
I
I
see
that
there
would
exist
a
a
word
list,
a
suggestion,
potential
suggestions
for
fixes
and
multiple
ways
that
the
tool
could
operate
right.
You
could
operate
in
kind
of
a
warning
state
that,
like
hey.
This
is
not
a.
This
is
not
a
a
phrase
that
you
may
may
want
in
your
repo.
B
You
can
operate
in
a
suggesting
state
where
it's
not
only
will
it
tell
you
about
that
warning,
but
also
suggest
potential
fixes
for
that,
and
then
you
can
operate
in
an
enforcing
state
where
you
will
not
be
able
to
merge
certain
things
without
having
without
having
those
things
fixed.
So,
depending
on
where
you
are
at
in
your
journey
across
multiple
repos.
B
We
do
want
this
to
be
develop
process
with
the
community,
establish
that
ship
that
out
to
the
the
various
sigs
and
sub-projects
and
working
groups
and
have
them
own
their
destiny
in
terms
of
how
we
do
naming
across
the
project.
B
So
so,
depending
on
where
you
are
in
that
journey,
you
may
decide
that
you
want
your
repo
in
a
suggesting
state
or
an
enforcing
state
or
a
warning
state,
as
you
maybe
build
a
backlog
of
issues
that
you
want
to
naming
issues
that
you
want
to
tackle.
As
you
maybe
look
to
us
for
guidance
on
on
some
of
those
issues,
so
that
was
what
was
rattling
around
in
my
head.
B
For
for
the
time
being,
I'm
sure
there
are
other
ways
that
we
can
implement
this
stuff
again,
making
things
comfortable
so
reaching
out
to
people
the
same
way
that
we
would
expect
to
for
pr
reviews.
I
think
we're
going
to
yeah
we're
going
to
talk
about
some
of
this
in
a
bit,
but
you
know
the
same
mechanisms
that
you
would
you
would
normally
reach
out
to
reviewers
and
approvers
are
the
same
ones
that
we
will
be
using,
and
I
think
that
does
lead
into
the
next
topic.
So.
A
Thank
you
very
much
for
such
a
good
handoff,
okay.
So,
let's
kind
of
talk
about
next
steps,
we
have
a
backlog.
There
is
a
github
board.
I
will
eventually,
probably
after
this
meeting,
update
info
in
the
slack
channel,
to
link
to
all
of
these
lovely
things,
but
the
the
summary
is
this,
which
is,
we
are
a
little
behind
the
rest
of
the
tech
world
in
addressing
some
of
these
issues
at
this
point
that
wasn't
the
case
in
june,
but
quarantine
time
slip
comes
for
us
all.
A
Please
start
being
mindful
of
language
and
thinking
about
noun
phrases
and
verb
phrases
are
usually
the
big
ones.
Thinking
about
whether
or
not
this
is
really
the
best
phrase
we
could
be
using
and
either
percolating
things
up
to
the
mailing
list,
percolating
things
up
to
slack
or
opening
an
issue
in
repositories
and
tagging
it
with
the
working
group
naming
tag
so
that
we
can
then
start
adding
this
to
the
backlog.
A
This
is
a
bit
of
a
hard
problem
for
us
to
tackle,
because
suggestions
are
easy
to
come
from
a
top-down
perspective.
In
terms
of,
I
think
the
broader
tech
community
has
decided
that
master
slave
is
no
good
anymore
and
similar
with
blacklist
whitelist
and
that's
an
easy
top-down
suggestion
to
get.
But
the
real
power
from
this
is
going
to
come
bottom
up
from
looking
at
our
own
code
bases
and
looking
at
things
and
going.
You
know
what,
like
that's,
that's,
not
the
greatest
term
that
we
could
be
using.
A
For
example,
I
think
somebody
brought
up
earlier
in
the
channel
this
week.
The
word
abort
is
not
like.
As
a
woman
like
I,
I
don't
ever
plan
to
get
an
abortion.
I
just
don't
really
like
looking
at
the
term:
it's
not
fun.
A
It's
a
little
violent
but
starting
to
have
those
kinds
of
discussions
and
bring
them
to
the
group
so
that
we
start
to
build
a
sense
of
what
the
scope
of
this
problem
really
is
is,
I
think,
really
important.
A
That
said,
the
working
group
would
like
to
start
tackling
our
two
obvious
candidates
as
soon
as
possible,
so
that
being
changing
blacklist
whitelist
to
allow
listnylis
or
another
alternative,
as
well
as
master
slave
asterix.
We're
not
going
to
touch
the
repos
just
yet
to
primary
replica
or
another
alternative.
A
We're
hoping
that'll,
let
us
do
two
things.
One
is
understand
if
we
do
decide
to
change
a
set
of
terms,
what
does
the
scope
of
work
actually
look
like?
How
does
the
work
actually
break
down
because
that'll
help
us
start
to
figure
out
what
the
process
needs
to
be
going
forward,
but,
right
now
we
don't
know
we
need
to
do
that.
Learning
two.
It
helps
us
catch
up
a
little
bit
with
the
rest
of
the
community
and
three.
It
removes
some
kind
of
ugly
wording
from
our
our
celeste.
A
Thank
you,
participants.
A
All
right
you've
got
the
power
now
man,
so
that's
kind
of
what
we'd
like
to
do
and
as
action
items,
and
you
can
put
this
under
my
name
jace.
I
will
start
two
discussions
in
the
naming
working
group,
one
around
blacklist,
whitelist
and
possible
alternatives
and
another
around
master
slave
and
posthumble
alternatives,
and
what
I'm
really
looking
for
from
the
group
for
those
two
discussions
is:
what
is
our
canonically
preferred
alternate
option,
because
I,
I
personally
think
we
can
all
agree
they're
a
little
less
than
savory
at
this
point.
B
A
B
There's
there's
a
context
thing
right
so,
depending
on
the
context
or
depending
on
the
specific
technology,
the
preference
might
be
different.
So
I
think.
A
Thank
you
very
much
for
that
piece
of
information.
Yeah,
that's
not
the
perspective.
I
was
thinking
it
from
so
those
two
discussions
will
start
up
and,
let's
I'm
gonna
say:
let's
give
them
a
couple
of
weeks
and
then
let's
give
a
couple
of
weeks
to
implementation
and
that'll,
be
our
rough
timeline
for
now
and
then
hopefully
for
the
next
occurrence
of
this
meeting,
which
will
be
september
14th.
A
A
So,
like
I
said
what
you
can
do,
please
search
your
repositories
and
tag
stuff.
Please
start
thinking
about
this
and
please
start
bringing
things
to
the
slot
channel
and
such
so
that
we
can
start
moving.
Jordan.
You've
got
a
question.
A
Good
call
a
little
bit
amorphous
at
this
point
but,
for
example,
if
I
said,
let's
remove
blacklist
whitelist
from
our
repositories,
what
does
that
then
entail?
Does
that
entail
api
method?
Naming
changes?
Does
that
entail
internal
class
naming
changes?
Does
that
entail
changing
inline
documentation?
Does
that
entail
changing
documentation
on
the
documentation
website?
I
think
that's
the
breakdown.
We
need
to
start
thinking
about
to
understand
our
own
comfort
level.
So
for
me,
what
the
next
step
is.
I'm
is
I'm
probably
gonna
pull
stephen
aside
like
in
all
honestly
and
say:
okay.
A
E
A
E
F
B
So
so
I
do
think
that
what's
what's
really
cool
about
this
is
people
have
heard
the
call
people
have
already
begun
to
act
on
certain
things.
So
like
it's,
it's
we're
not
starting
from
zero.
In
this
work,
there
are
several
pr's
that
we've
seen
fly
by
that
are
steps
in
the
right
direction.
We
want
to
make
sure
that
I
think
what
I
was
suggesting
to
the
the
lead
group
is
that
we
are
going
to
dive
in
on
the
first
few
of
these.
B
I
think
it's
important
for
us
to
set
set
the
pace,
and
I
think,
as
we
do
these
we're
going
to
understand
what
the
process
looks
like.
This
is
again.
You
know
like
this
is
new
new
territory
for,
for
some
people,
new
territory
definitely
like.
B
I
am
not
a
technical
writer
and
we
have
technical
writers
who
are
not
engineers,
so
I
think
that
this
is
going
to
be
a
learning
process
as
we
go
forward
with
this
group,
but
I
think
eventually,
we'll
have
a
process
down
that
we
can
ship
out
to
everyone
that
says
like
if
you
encounter
foo
here's
how
to
do
here's,
how
to
get
to
the
place
that
you
want
to
be
right
and
we'll
proof
is
in
the
pudding.
We'll
do
some
of
that
ourselves.
B
So
you
can
see
what
that
process
looks
like
one
one
point
to
note
that
I
realized
that
we
did
not
put
on
the
agenda
and
that's
my
fault
was
the:
is
the
discussion
around
some
of
the
more
technical
and
mechanical
aspects?
If
we
think
about
like
branch
naming
branch
naming,
I
owe
an
issue
on
the
github
administration
side
to
talk
about
some
of
the
stuff.
B
But
we
are,
I
would
suggest,
and
the
general
guidance
from
the
project
is
not
to
rename
your
branches
right
now,
the
we
want
two
things
to
happen,
support
and
get
which
I
think
has
happened.
As
of
the
the
most
recent
version
for
new
repositories
right
for
the
default
branch
to
be
set
to
something
that
is
not
master
for
existing
repositories,
I'm
not
sure
that
that
is
true
right
now.
B
Github
has
some
guidance,
I
believe
that's
github.com
renaming,
but
what
I
think
is
also
really
important
that
we
have
in
place
before
we
move
into
any
of
that
is
one
not
only
guidance
from
github,
but
also
tooling,
to
make
that
transition
easy.
I
don't
want
this
to
be
a
sub
project.
Foo
developed
some
script.
B
To
do
this
thing
and,
and
it's
done
and
it
kind
of
works,
but
there
are
you
know
their
trailing
concerns
about
if
we
consider
prs
that
are
opened
when
prs
are
open,
they're
targeted
against
they're
targeted
against
branches
right.
So
when
you
change
the
branch
name,
you
may
have
to
change
the
way
prs
are
targeted
right.
B
So,
if
you
think
about
a
repo
with
large
pr
account
like
kubernetes
kubernetes,
changing
the
changing
the
default
branch
name
is
is
not
necessarily
advisable
without
lots
of
notice
and
without
walking
people
through
the
correct
procedure
for
for
doing
so.
So
I
think
what
we're
eventually
going
to
end
up
doing
is
choosing
choosing
a
few
different
repos
as
pilots.
A
kind
of
a
small,
medium
large
situation
and
christoph
has
his
hand
up.
So
I
know
he
has
opinions
on
this
too.
H
Sorry,
I
was
just
going
to
to
add
it.
I
do
have
a
few
pieces
of
technical
detail
on
this.
Some
of
this
well
like
one
of
the
hacks
I
wear,
is
I'm
on
the
github
administration
project.
We
have
close
ties
and
contacts
with
github
and
we
like
talk
to
them
some
of
it's
under
nba,
some
of
it's
not
about
their
future
roadmap
for
features
and
and
that
kind
of
stuff.
H
So
there's
potentially
a
phased
approach
of
how
we
could
do
this.
Where
you
know
new
repos,
we
could
stand
up
with
a
new
default
branch
name
and
then
eventually,
even
big
repos,
like
kubernetes
kubernetes,
could
use
github's
tooling
to
migrate
to
a
different
branch
name
and
have
things
like
all:
open,
active
prs,
automatically
update
to
the
new
branch
name,
and
things
like
that.
H
So
there's
some
like
technical
details
in
that,
where
you
know
we
could,
where,
like
the
tooling,
basically,
the
tech
will
get
better
with
time
and
we'll
be
able
to
do
it
a
lot
easier
than
we
would
if
we
were
like
manually
doing
it
now
and
like
updating
all
those
settings
now.
So
that
may
just
be
like
I'll
wait.
A
little
while
longer
until
github's
feature
set
is
where
we
need
it
to
be
to
make
those
transitions
easier
and
seamless.
A
Yeah
just
to
add
on
to
this,
from
the
cncf's
perspective,
the
advice
we
have
been
giving
projects
is
at
this
point,
particularly
with
github's
most
recent
or
git
rather's.
Most
recent
update
is,
if
you're
feeling
really
keen
and
you
don't
think,
you're
gonna
break
anything.
You
were
comfortable
with
you
making
that
change
for
yourself,
but
we
do
advise
for
most
projects
most
of
the
time
to
wait
on
github,
because
it
will
probably
resolve
a
lot
of
those
issues
without
them
becoming
issues
for
kubernetes.
A
Specifically,
lots
of
the
repos
are
large
enough
and
important
enough
and
kind
of
high
touch
enough
that
I
would
not
recommend
at
this
point
from
my
kind
of
cncf
employee
hat.
I
would
not
recommend
any
kubernetes
repo
at
this
point.
Change
their
branch
names
full
stop.
A
B
I
So
was
just
gonna
comment
on,
though
we
may
not
be
changing
the
physical,
actual
name
of
one
particular
branch.
In
our
repository,
I
still
could
use
some
guidance
on
how
we
refer
to
that
branch,
as
I've
been
doing
a
lot
of
prs
against
it,
and
that's
I've
been
having
a
lot
of
discussions
about
the
upcoming
release
and
our
plans,
I'm
trying
to
find
creative
ways
to
say
things
like
the
upcoming
release,
branch
or
the
in
development
release,
branch
or
the
main
branch,
or
something
like
that.
I
A
Yeah
totally,
we
don't
have
to
hash
it
out
here
either
bring
it
to
the
channel
or
the
mailing
list
is
my
first
piece
of
advice,
so
you
can
be
a
model
for
our
new,
wonderful
behavior.
Thank
you
so
much
for
volunteering.
A
B
Yeah,
so
maine
has
been
kind
of
what
people
have
been
floating
with,
and
I
think
that's
also
the
suggestion
from
the
list.
Let
me
open
the
k,
org
issue
first,
just
to
get
that
started,
because
I
think
that
that
will
all
be
part
of
deciding
on
on
that.
A
Yeah,
okay,
so
I'd
like
to
stop
sharing
my
screen
first
off
and
I'd
like
to
kind
of
open
it
up
to
the
group
for
a
little
bit
of
discussion
on
what
you
all
think
of
this.
A
What
you'd
like
to
see
happen,
see
done
and
any
ideas
you
have
around
process
tooling
how
and
where
to
present
decisions
on
language
long
term.
There's
a
note
on
the
community
contact
committee,
so
yeah,
I'm
gonna!
Stop
sharing
my
screen
and
open
this
up
for
a
little
bit
of
discussion.
Zach!
Do
you
wanna
maybe
keep
track
of
who's
next,
because
I
think
we're.
G
J
Well,
so
we've
talked
a
whole
lot
about.
We
how
we
want
the
sort
of
workflow
to
go,
but
we've
loosely
interchanged
mailing
list,
slack
and
github
issues
like
where
should
we
actually
open
new
discussions.
B
I
would
I
would
tend
towards
the
mailing
list.
It's
it's!
It's
easy
for
it's
easy
for
a
really
good
discussion
to
get
lost
in
slack,
and
I
think
the
mailing
list
kind
of
solidifies
that
so.
G
J
F
B
So
there
is
a
project
board
already
where
you
can
see
some
of
that
stuff.
I
think
that
so
what
we
have
been
doing
is
kind
of
backtracking
and
trying
to
tag
a
few
issues
and
drag
them
into
the
project
board
that
have
already
been
kind
of
handled,
but
I
I
think
that
part
of
this
will
be
relying
on
sig
subprojects
working
groups.
B
What
have
you
to
flag
that
an
issue
is:
is
naming
related
so
when
I
drag
things
onto
the
project
board,
I'm
basically
looking
for
the
naming
label,
the
working
group
naming
label.
So
if
it's,
if
it's
already
flagged
with
that
label,
it'll
get
pulled
in
as
we
do
as
we
do
triage.
D
Celeste,
could
you
provide
a
link
to
the
project
board?
You
probably.
D
E
I
was
just
gonna
mention
well,
while
the
charter
was
being
sort
of
put
together,
there
was
discussion
about
making
sure
we
have
or
think
through,
like
clear
guidance
about
how
we
evaluate
language
and
then
using
that
guidance
to
inform
the
things
that
we
tackle
changing.
So
we
sort
of
are
coming
into
this
with
a
few
things
already
in
progress.
The
ones
you
mentioned
and
that
that's
great,
like
continuing
continuing
that
progress
is
fine,
but
I
think
it
would
be
helpful
to
make
sure
that
we
don't
forget
the
like
the
guidance
aspect.
E
A
And
I
think
that's
that's
fair,
I'm
I'm
a
very.
I
tend
to
make
up
my
mind
halfway
in
between,
so
this
is
definitely
taking
a
bit
of
the
color
of
celeste,
very
specifically,
the
way
that
I
envision
this
working
best
is,
let's
start
a
few
discussions
on
the
mailing
list
and
amongst
ourselves,
vet
them
as
yay
or
nay
like
yes,
we
think
this
is
something
we
should
action
on.
A
C
Yeah,
this
is
something
so
just
to
echo
your
concern.
Jordan
is
something
that
I
was
really
thinking
about
too,
is
being
very
important
to
codify
the
decision-making
process.
What
are
the
sources
that
are
used
to
consult?
Are
they
consistent
every
time?
Is
this
something
that
has
industry
or
other
precedent
like
it?
C
A
lot
of
a
lot
of
things
that
I've
heard
celeste
say
it
at
least
a
dozen
times
and
in
zack
as
well
that
language
is
very
subjective,
and
so
these
these
things
are
very
hard
to
evaluate,
and
so
the
the
thing
that
I
would
like
to
do
is
add
as
much
rigor
to
the
process
that
literally
we
plug
in
a
word
into
this
process,
and
some
tabulation
happens,
be
it
human
or
otherwise,
and
then
at
the
end,
it's
like
you
know,
there's
a
there's,
a
90
consensus
that
this
this
word
or
this
phrase,
or
this
has
strongly
offensive
ties
to
racist
language
or
whatever
that
is
like.
C
I,
I
think
where
they
need.
We
need
to
be
as
evaluative
as
pros
as
possible
on
these
things
so
that
we
don't
have
this
arbitrary
thing,
because
the
thing
we
don't
want
to
do
is
accidentally
well
we're
trying
to
reduce
harm,
and
we
we
don't
want
to
induce
harm
in
another
way.
So,
at
least
in
my
opinion,
so.
D
To
counter
somewhat
the
idea
of
iterating
doing
a
couple
of
things
free
form
and
then
looping
back
around
what
if
no
consensus
emerges,
because
each
of
these
cases
are
like
individual.
D
So
if
what
if
no
clear
set
of
principles,
apart
from
reducing
harm
emerge,
it
seems
to
me,
like
we
have
already
a
fairly
clear
set
of
principles
that
we
can
use
to
create
evaluative
criteria
right
out
of
the
gate
so
like
jace
are
and
jordan.
I
would
like
to
see
rigor
applied
to
the
process.
F
D
Said
the
other
side
of
this,
what,
if
is
becoming
bogged
down
in
endless
rabbit
holes
of
etymology,
so.
D
This
is
not
the
place
to
work
through
this
discussion.
It's
you
know,
let's
move
it
to
the
to
the
list,
but
I'm
less
interested
in
the
particulars
of.
D
Process
and
evaluation
than
in
what
our
default
stance
towards
change
is,
and
that
also
needs
to
be
a
very
specific
principle
that
we
use
to
guide
our
work.
A
Okay,
yes,
please
first
off,
please
move
that
to
a
discussion
on
the
mailing
list,
because
I
think
we
need
to
start
exploding
that
and
second
stephen,
you
had
something
to
say.
B
Dang
my
thoughts
just
yeah,
so
I
think
that
process-wise
I
agree.
I
will
talk
about
it
on
the
mailing
list
too,
but
we
need
to
bias
towards
action,
and
I
think
this
is
something
that
that
zack
believes
strongly,
because
we
won't
get
anything
done.
I
think
this
is
the
nicest
way
of
saying
this.
B
The
you
know,
thinking
about
thinking
about
kind
of
like
the
instantiation
of
this
group,
which
was
a
mailing
list
thread
about
how
we
discuss
control,
plane,
nodes
on
the
cig
architecture,
mailing
list,
and
it
was
something
that
I
kind
of
backed
off
of
and
said
something
is
going
to
happen
here
eventually,
and
it
was
a
year
later
until
I
was
like
okay,
all
right.
Let's,
let's
do
this
so
so
we
need
to.
I
do
think
we
need
to
buy
us
towards
some
action.
B
I
do
want
to
make
sure
that,
like
when
we
make
actions
when
we
make
suggestions,
recommendations.
B
What
have
you
that's
they're,
easy
to
find
they're
easy
to
eventually
agree
upon
one
of
the
situations
that
worries
me
is
someone
or
some
some
sub-project
owner
some
some
sick
leads
chairs,
making
a
decision
about
some
naming
that
accidentally
and
unintentionally
goes
against
the
recommendations
of
this
group
right
so
like
then
it's
have
you
made
a
change
that
you
now
need
to
revert.
B
Could
that
could
that
action
have
been
prevented
by
seeking
guidance
from
the
group
first,
and
the
answer
is
probably
probably
yes,
so
I
think
that
part
of
what
we
need
to
do
is
make
sure
that
people
know
we're
here
to
provide
that
guidance
to
prevent.
You
know
there
are
also
already
repos
who
have
made
the
change
to
using
the
main
branch,
which
is
awesome,
but
it
had
it
had
it
created.
B
Had
it
headed
like
created
issues
for
their
repo,
then
it
would
be
a
larger
discussion,
maybe
a
discussion
with
the
with
the
org
admins
about
how
to
backtrack
some
of
that
stuff.
So
so
I
think
making
sure
that
we
funnel
the
discussion
through
here.
We
don't
want
to.
We
don't
want
to
block
progress,
but
we
also
want
to
make
sure
that
we're
having
the
same
discussions
and
everyone's
benefiting
from
that
information
so
chase.
C
I
think
this
is
really
important
because,
having
been
in
the
code
of
conduct
committee,
most
people
in
kubernetes
didn't
even
know.
We
had
a
code
of
conduct
committee,
much
less
what
we
were
supposed
to
be
doing
and
all
those
things
and
one
of
the
things
I
want
to
avoid
is
the
same
lack
of
awareness
or
visibility
for
our
group,
and
I
know
that
a
project
board
is
a
way
to
provide
that.
But
it
doesn't
necessarily
it's
not
a
proactive
way.
C
You
have
to
go
seek
that
out,
so
I
I
would
like
our
project
to
be
less
ncd
like
in
terms
of
you
have
to
go,
look
at
it,
and
maybe
we
can
broadcast
more
to
the
community
in
some
ways.
So
I
think
we
should,
as
a
group,
also
find
tangible
ways
to
do
that
via
community
updates
at
the
the
community
meetings
or
periodic
status
reports
to
the
mailing
list
whatever
that
is.
But
I
think
this
is
super
important.
A
I
think
that's
a
very
important
note,
so
I
have
already
scheduled
a
an
update
for
the
next
community
meeting
for
this
group,
but
I
also
like
the
idea
of
a
periodic
status
update
and
stephen.
B
So
one
really
great
thing
that
that
I
see
a
few
groups
doing
right
now
and
it's
kind
of
something
that
I
want
to
happen
in
all
of
my
groups,
because
we're
not
doing
it
right
now
is
that
is
that
post
meeting
update
right,
I
think
contributor
experience
sends
one
out
right
now
where
before
even
like,
maybe
you
weren't
able
to
attend
the
meeting,
and
maybe
you
don't
have
time
to
read.
Maybe
you
don't
have
time
to
watch
the
the
video
or
maybe
the
video
is
not
up
yet
right.
B
They
send
the
meeting
notes
after
every
meeting
now,
and
I
think
that
at
as
a
baseline
is
a
nice,
it's
nice
like
hey,
we're
doing
stuff,
here's
what
we've
been
up
to,
especially
given
that
we're
a
I'm
going
to
be
meeting
on
a
monthly.
A
So
one
last
thing-
and
this
can
also
be
an
action
item
for
me
under
this
agenda-
is
talking
more
about
like
how
do
we
kind
of
record
our
decisions?
What
are
our
options
and
like
what
level
of
visibility
do
we
want
into
those
decisions?
A
A
Do
we
place
it
at
this
in
its
own
repo?
So
it
has
a
bit
more
visibility
and
kind
of
what
format
do
these
take.
My
brain
is
biasing
towards
something
similar
to
like
an
architectural
decision
record
where
it's
like.
This
is
the
decision
we
made.
These
are
the
reasons
we
made
it.
These
were
the
other
alternatives
and
this
is
kind
of
how
the
cards
fell.
But
I
think
this
is
a
this
is
something
to
talk
about
a
little
bit.
First,
yeah,
that's
all!
I
really
had
to
say.
D
J
And
one
relatively
unpleasant,
but
important
topic,
people
that
manage
and
discuss
these
kinds
of
issues
often
become
targets
on
the
internet.
If
you
have
not
already,
please
make
sure
that
you
have
things
like
two
factor:
auth
turned
on
everywhere:
don't
click
on
strange
links,
yeah
and
yeah
you,
you
may
have
just
made
yourself
a
target
for
unsavory
individuals.
So
please
take
steps
to
protect
yourself.
If
you
need
any
help
with
that
contributor
experience
is
happy
to
help.
A
That
is
a
really
good
note
that
is
unfortunately
already
relevant,
but
it's
a
good
reminder
to
like
go
change,
my
passwords
for
things,
it's
good
good,
refresher.
B
And
a
re-re-re
reminder:
I
think
that
you've
noticed
some
of
the
additional
controls
that
I
mean.
This
is
common
for
for
zoom
meetings
in
general,
but
you
know
we'll
have
noted
that
the
waiting
room
was
on.
There
are
multiple
co-hosts
they're
things
like
we're,
taking
this
pretty
seriously
around
the
the
potential
trolling
opportunities
that
are
available
for
these
meetings
and
for
the
various
channels.
You'll
note
that
you
did
not
receive
a
meeting
password
until
closer
to
the
meeting
time.
B
There
are
certain
things
that
we're
doing
that
are
a
little
more
tightly
controlled
than
than
a
normal
working
group.
Subproject
sig
meeting
so
be
patient
with
us
as
we
work
through
additional
controls
and
try
to
I
don't
know.
I
have
nothing
else
to
say.
A
Folks,
I
think
that's
the
meeting.
Gonna
stop
recording
five
four
three
two
one.