►
From YouTube: 20200618 SIG Architecture Community Meeting
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,
hello,
everybody:
this
is
the
kubernetes
sig
architecture
meeting
for
June
18th
2020,
please,
we
have
a
pretty
full
house
today,
so
I
just
want
to
remind
everybody
that
we
have
a
code
of
conduct
to
be
kind
to
one
another
and
respectful.
So
please
follow
that
and
with
that,
why
don't
we
get
started,
I
believe
the
first
item
on
the
agenda.
What
Jordan
was
at
you.
B
So
I
emailed
with
a
list
last
week
sometime
there
there'd
been
an
issue
opened
I.
Think
against
the
kubernetes
community
is
asking
about
switching
from
whitelist
blacklist
terminology
to
something
else
like
allow
list
or
deny
list
or
something
else,
and
so
a
couple
PRS
had
been
opened
off
of
that
issue,
one
for
the
website
and
one
for
our
API
documentation
and
since
that
touches.
B
Recommendations,
API
guidelines
or
yield
an
injury
and
choose
in
the
future,
I
wanted
to
bring
it
up
here
so
since
I
sent
that
list
I
think
both
of
those
PRS
actually
got
reviewed
and
merged
in
in
this
case,
I
think
it
was
a
pretty
easy
call.
Our
documentation
was
often
sadly
neglected,
and
so,
if
someone
like
pays
attention
to
part
of
it
and
like
actually
worked
through
phrase
things
more
coherently,
I
think
it
was
a
net
benefit
for
both
of
those
both
of
those
cases,
and
there
was
basically
no
downside.
B
B
C
Yes,
naming
is
hard.
We
know
that
we've
we've
known
that
for
some
time,
I
think
that
the
I
think
that
you
know
to
tag
on
to
some
of
the
stuff
that
Jordan
was
saying.
I
have
Celeste
and
Zack
here
as
well
we're
proposing
a
working
group
that
Crosscut's
and
will
hopefully
be
sponsored
by
sig
Docs,
a
contributor
experience
and
sega
architecture
to
discuss
naming
across
the
project.
C
Part
of
this
is
related
to
that
previous
thread
and
threads
that
we've
had
in
the
past
some
some
fairly
toxic
that
were
that
were
locked
in
the
past
due
to
the
conversation
from
non
contributors.
So
we
want
to
move
forward
in
a
more
effective
and
thoughtful
way
here
so
say,
get
Docs
and
say:
contributor
experience
have
approved,
have
decided
to
sponsor
this,
so
we're
looking
for
additional
approval
on
the
sick
architecture
to
move
this
forward.
Essentially,
we
would
be
looking
into
various
areas
in
the
project.
C
C
This
activity
I
think
that
seeing
issues
pop
up
and
in
queue
builder
and
website
and
kubernetes
kubernetes
and
having
different
people
be
part
of
different
conversations.
Leading
to
different
resolutions
is
not
necessarily
productive
for
the
project,
so
that
is
the
same
fidus
for
the
working
group,
and
we
wanted
to
bring
it
to
you
here
today
to
get
thoughts
from
sig
chairs,
exact
technical
leads
and
contributors
overall.
C
Think
that
what
we
want
to
do
is
provide
guidelines,
process
and
procedure
for
one
discussing
the
stuff
overall
as
a
as
a
community
and
then
also
driving
towards
that
change.
I
think
that
the
sub-project,
the
excuse
me,
the
SIG's
that
we've
included
I
think
would
be
ultimately
delegated.
That
decision,
the
you
know
from
the
API
level,
API,
documentation
and
processes.
I
would
see
that
istic
architecture
from
the
process
guidelines
overall
I
see
that
as
a
you
know,
a
commingling
of
sig,
Docs
and
experience.
C
So
the
the
eventual
hope
is
to
provide
enough
of
a
basis
and
guidance
that
this
can
not
just
be
used
in
the
kubernetes
sub
broad
in
the
kubernetes
project,
but
also
in
other
CN
CF
projects.
So
you
know,
we've
been,
we've
actually
already
started
the
discussion
around
that
and
the
sig
we're
bringing
that
up
as
a
topic
for
the
maintainer
circle
and
say
contributor,
contributor
strategy
on
the
CNC
F
level,
so
that
we
can
discuss
this
across
multiple
projects.
C
Potentially
things
around
whitelist
blacklist
allowed
to
analyst
I'm,
not
sure
like
we
haven't,
we
haven't
done
the
dig
into
the
API
stuff.
Just
yet,
but
I
think
our
main
concern
was
I'm
fairly
certain
that
we,
you
know
from
the
API
level,
we're
not
touching
we're
not
using
kind
of
master/slave
references,
but
allow
deny,
as
our
white
black
is
more
likely.
So
the
short
answer
is
we
don't
have
the
answers
yet,
but
but
it's
we
thought
it
important
to
bring
it
to
y'all
to
if
people
have
context
already
I
mean.
F
I
was
gonna,
say,
I
think
we
have
a
couple
known
places
where
we
have
API
level
ones.
I
think
we
want
to
make
sure
that
we
have
a
good
process
for
if
we
do,
you
know
as
we
as
we
talk
about
terminology
and
as
the
working
group
continues,
having
a
set
of
you
know
ways
of
thinking
about
how
an
API
change,
if
it
became
necessary,
would
be
staged
over
time
like
I.
F
Think
the
one
place
where
we
actually
do
use
master
and
terminology
was
problematic
for
other
reasons
which
the
original
issue
actually
called
up,
which
is
like
we
shouldn't
have
even
been
doing
this
in
the
first
place
right
like
that
was
using
the
node
labels
to
mean
something
and
coupling
how
much
meanings
that's
taken
about
a
year
to
unwind
right
now,
but
it's
been
something
that's
been
in
motion.
We
generally
have
been
pretty
responsive
to
it
in
the.
F
How
do
you
stage
API
changes,
but
would
everybody
understand
how
long
some
of
these
changes
make
and
making
sure
that
that's
clear
like
we
will
change
documentation
or
we
will?
You
know
when
we
have
problematic
concerns?
We
react
to
those
quickly
and
then
we
communicate
how
the
process
for
the
other
changes
if
they
do
become.
You
know
if
those
problematic
things
extended
a
guy.
F
You
know
the
process,
here's
how
we're
taking
into
account
the
concerns
of
the
language
and
here's,
how
we're
taking
into
the
concerns
of
the
people
running
it
and
here's
how
we're
going
to
stage
that
change.
It's
kind
of
a
that
that
process,
I
think
is
where
a
lot
of
people
reacted
to
it,
which
was
like.
Oh
no.
We
have
to
go.
Make
big
scary
changes
having
that
framework
to
talk
about
that
is
very
useful,
like
how,
like
you
know,
understanding
the
balance
of
factors
is
really
what
I
think
addresses
a
lot
of
the.
G
C
To
be
determined,
honestly,
I
think
the
first
steps
are
to
to
eliminate
language
that
is
very
clearly
harmful
to
contributors
and
and
work
on
establishing
policies.
Short
version.
I
don't
have
the
answer
yet,
but
I
think
that
it
was
important
to
start
the
conversation.
But
yes,
I
do
agree
that
it
should
be
time
bounded
and,
and
ideally
these
policies
will
will
move
quickly
to
live
inside
of
the
cig
set
sponsor.
C
E
Steven,
so
in
terms
of
what
you
do,
this
working
group
will
need
from
cigar.
Collector
is
a
place
to
codify
the
policies
that
you
come
up
with
and
make
sure
that,
like
you
know,
we
have
the
API
review
stuff
right.
That's
just
if
we
don't
really
have
code
here
right,
but
we
have
the
policies
that
we
lay
down
for
the
API
reviews,
and
then
we
have
mechanism
to
like
work.
The
issue
about
like
how
is
this
API
review
good?
Is
this
PR
good
right?
So
is
that
what
you're?
Looking
for
from
from
this.
C
Group
yeah
I,
think
I
think
from
this
group.
It's
is
from
from
the
API
level
of
it.
If
it
eventually
becomes
a
link
out
to
a
dock
that
is,
can
maintain
by
contributor
experience
that
provides
guidance
around
language
within
the
project
and
I
think
that
that
should
suffice.
The
you
know
the
as
Clayton
mentioned,
there's
a
process
for
moving
through
changes,
so
I
think
at
least
making
that
process
more
visible,
especially
when
we
bring
in
new
language
or
we
want
to
change.
Language
is
important,
so
I
think
really
just
connecting
connecting
threads
between
all
cigs.
A
H
H
C
Right
so
I
think
part
of
that
will
be
understanding
a
little
better.
The
places
that
we
might
need
to
change
right
so
I
think
once
we
once
we
have
an
understanding
of
that
we
can.
We
can
kind
of
drive
forward.
This
is
something
that
is
actually
in
an
API
right
like.
If
this
is
something
that
needs
to
be
guidance,
then
it
becomes
guidance
right
and
documentation
is
fairly
simple.
If
it's
something
that's
on
the
API
level,
then
we
need
to
say
like
okay.
C
Well,
this
needs
to
exist
until
we
have
owners
for
making
this
change
and
carrying
it
through
any
API
change
periods
right.
So
it
may
range
over
a
set
of
cycles
to
get
that
done.
So
I
think
that
yeah
yeah
I
think
that,
on
the
on
the
architecture
side,
it's
the
the
handoff
from
working
group
back
to
saying
should
be
fairly
quick,
I
think
on
the
dachshund
contributor
experience
side,
it'll
be
more
of
a
continuing
effort.
It's
in
sure
that's
to
ensure
that
we
have
consistent
policies
in
place
for
handling
this
across
the
project.
B
I
okay,
so
I
had
a
couple
of
comments
about
the
naming
proposal,
so
whenever
I
see
sort
of
intentionally
ambiguous
goals,
I
worry
a
little
bit
and
so
I
think
crisping
up
like
what
what
the
de
liberals
deliverables
would
be.
What
the
goals
are
would
be
helpful.
I
mean
I
also
am
a
little
concerned
by
like
including
charged
language
in
the
goals.
B
B
For
this
reason,
then
that's
less
of
an
argument
than
saying
well,
I,
don't
think
it's
racist
because
blah
blah
blah
or
because,
if
you
look
at
the
etymology
of
the
word,
blahblah
like
if
you
say
it's
unhelpful
and
we
can
change
it
to
something
that
is
more
helpful,
then
let's
change
it.
So
I
think
that
might
be
a
more
constructive
way
to
frame
what
we're
shooting
for
and
that.
C
That's
that's
fair
I
did
include
in
the
email,
racist
and
non
inclusive,
so
if
we
want
to
move
towards
the
non
inclusive,
where
we
see
that
the
language
is
potentially
causing
harm
to
potential
and
existing
contributors
and
I
think
that
we
can
do
that
safely
and
yeah,
the
I've
I've
already
seen
this
Twitter
threads.
All
the
stuff
like
this
is
this
is
ballooning
quite
quite
quickly,
quickly.
Kristof
already
reported
a
user's
or
for
something
in
related
projects.
F
You
know
I
was
like
I,
think
framing
it
in
terms
of
terms
like
master/slave
are
confusing
and
like
they
are
have
a
history
and
they
are
unhelpful
and
they
are
they
create
problems
and
they're,
not
even
very
good
descriptions
like
a
lot
of
times.
We
say
you
know,
there's
a
history
of
using
this
term
in
this
context,
but
in
many
of
the
examples
that
we've
come
up
with
they're
actually
far
more
accurate
terms
that
we
could
use
I.
Think
sometimes
you
as
a
project
we
have
said
you
know.
Consistency
internally
is
important,
I.
F
Think
there's
an
angle
here,
which
is
consistency
to
you
know.
Body
of
literature
arguments
are
less
convincing
to
me
than
having
a
very
clear,
precise
term
that
describes
exactly
what
we
care
about
and
the
consistency
would
like.
You
know.
If
you
argue,
oh
well,
you
know
the
term
master
for
the
collective
you
know
element
is
determined
in
use.
There
was
a
discussion
the
other
day,
which
is
well
lease,
folder
or
lock.
Holder
is
a
far
more
accurate
term
and
is
actually
more
clear
and
so
to
just
add.
F
I
I
C
C
I'm
not
muted,
can
anyone
else
hear
me:
you're,
not
muted.
My
mic,
client
just
has
a
delay.
Sorry,
so
yeah
so
I
think
that,
overall
of,
if
we,
if
we
do
the
stack
rank
of
open-source
projects,
I
think
that
kubernetes
is
pretty
good
about
some
of
the
stuff
that
we
do.
I
think
that
we
do
have
levers
in
place
to
handle
handle
contributors
that
are
not.
You
know,
living
up
to
the
Sanders
and
values
that
we
have
for
the
project
so
I.
So,
yes,
I,
agree
on
the
handling,
bad
actors,
portion
and
and
again
I.
C
Don't
want
this
to
you.
I
don't
want
this
to
you
know
the
implication
to
be
that
we're
trying
to
malign
anyone
who
had
previously
contributed
code.
I
think
that
it
is
also
important
that
we
not
turn
this
into
a
bike
shed.
If
this
is
a
good
idea,
we
should
say
it's
a
good
idea
and
we
can
work
on
tightening
up
this.
This
proposal
I
think
we
should
work
on
moving
forward
with
the
work.
My
biggest
concern
here
is
that
we
we
spend
more
time
talking
about
these
things
that
are
not
moving
the
goalposts
toward.
B
Just
to
jump
in
on
that
I
I
think
by
I
think
we
will
actually
make
more
progress
if
we
set
our
goals
and
principles
in
terms
of
like
being
helpful
and
that's
a
much
easier
thing
to
get
on
board
with
and
a
much
easier
thing
to
connect
changes
to
I
could
say
this
is
unhelpful.
Let's,
let's
make
this
more
helpful,
so
I
think
in
terms
of
prop
making
progress,
we
will
actually
make
much
more
progress
if
we
avoid
the
like
setting
the
bar.
B
Everyone
has
to
agree
that
this
term
is
inherently
as
this
meaning
or
that
meaning
League.
Some
people
think
is
very
clear.
Some
people
think
it's
not
clear
if
you
make
that
the
bar
I
think
will
get
mired
down
at
arguments,
so
we
can
say
this.
This
would
be
more
helpful.
Let's
be
helpful,
let's
be
kind
of
each
other
I
think
not
Smart,
Covers
I.
Think.
C
In
the
the
kindness,
it's
important
to
note
that
to
a
bit
to
Clayton
to
previous
point
that,
like
this
should
be
additive,
it's
not
just
being
more
helpful
I
think
it's
it's
important
to
acknowledge
that
this
language
is
potentially
harmful
to
people
right
and
calling
that
out
in
goals.
So
so
I
do
plan
to
still
do
that.
J
J
A
goal
is
to
like
correct
and
change
language
that
is
problematic
and
identifying
which
language
is
problematic,
whatever
you
call
it
and
trying
to
correct
that
in
wherever
we
can,
whether
it's
you
know
our
documentation
or
code
base
and
that
kind
of
stuff,
so
that
is
in
itself
a
goal
not
just
being
more
technically
technically
accurate.
That
is,
you
know
a
bonus
if
we
can
do
both
great.
J
K
J
Like
binding
policies
that
we
have
to
adhere
to
the
reason
I
ask
this
is
and
why
it's
important
for
this
group
as
well,
is
where
that
output
reside.
If
it's
guidance,
that
is
something
like
a
policy
that
can
come
over
to
contributor
experience,
but
contributor
experience
doesn't
really
do
a
lot
of
binding
policies.
Binding
policies
on
things
like
naming
in
code
should
probably
exist
in
architecture
rather
than
contributor
experience.
So,
as
far
as
like
sponsoring
the
working
group
and
like
that
kind
of
stuff,
that's
something
that
this
audience
should
be
aware
of.
J
C
So
I
honestly
think
it's
a
combination
of
of
both
of
them.
I
think
I
mentioned
in
the
email
that
we
are
looking
to
provide
both
guidance
and
policy
from
the
from
the
person.
I
think
I
think
the
the
policy
would
be
that
the
policy
could
potentially
be
that
people
who
are
doing
API
review
should
be
reviewing
the
guidelines
set
forth
by
wherever
some
link
right.
C
So
if
this
is
a
part
of
the
API
review
process,
and
we
then
we
ensure
that
the
I
think
that
we
have
a
lot
of
things
in
the
project
that
are
binding,
maybe
right
things
that
continue
to
evolve
over
time.
I,
don't
think
that
there's
anything
that
we've
laid
down
that
just
exists
and
that's
it
right,
so
I
think
that
giving
the
opportunity
giving
the
opportunity
for
a
love
evolution
of
these
policies
over
time.
C
I
think
that
it's
it's
you
know,
I,
think
that
it's
saying
that
a
part
of
the
API
review
should
be
ensuring
more
inclusive
language
is
a
reasonable
policy
to
set.
K
And
just
to
sort
of
add
to
that
and
I
guess
give
a
little
context.
It'll
put
my
hand
down
after
this
one
this.
So
for
you,
those
of
you
who
don't
know
me
I
work
with,
because
the
technical
writer
for
the
CNC
F-
and
this
is
something
the
CNC
F
is
looking
at
implementing
broadly
across
all
projects
potentially
is
an
entrance
requirement.
We
don't
know
yet
so
there's
that
and
as
I
sort
of
mentioned
in
my
initial
comment
to
the
kubernetes
kubernetes
issue
from
a
technical
writing
perspective,
I
have
seen
this
particular
discussion
happen.
K
K
I
should
stop
using
these
harmful
words
in
my
codebase
and
they
say,
but
it's
really
hard
to
change
tests
and
it's
really
hard
to
change
class
names
and
our
customers
will
have
to
deal
with
braking
changes
and
we're
gonna
change
it
in
the
documentation
or
we're
going
to
make
guidelines
and
put
them
into
a
into
a
non-binding
form
that
doesn't
actually
affect
the
codebase
and
then
I'm
gonna,
step
away
and
every
single
times.
These
initiatives
fail
because
it's
not
taken
into
the
core
of
the
project.
K
L
L
The
discussion
has
been
made
in
history,
it's
being
made
right
now
in
our
lives
and
our
cities
in
our
streets.
These
terms
just
need
to
go
they're,
not
accurate,
they're
lazy,
whatever
that
is
I,
don't
really
care.
What
I
care
about
is.
These
terms
are
harmful.
We
have
to
remove
them
just
like
we
need
to
remove
a
cancer
from
a
body,
so
it
doesn't
spread.
This
is
this
is
work.
This
should
be
binding.
This
is
work
that
should
be
enduring
and
staffed.
We
as
white
people
should
be
staffing.
L
This
Steven,
as
a
non-white
person,
should
not
have
to
bear
that
burden
in
addition
to
the
burden
of
the
harm
that
these
words
create.
We
owe
it
to
our
community.
We
owe
it
to
each
other.
We
owe
it
to
Steven.
We
owe
it
to
every
person
who
ever
feels
like
they
are
left
out
because
they
look
different
than
the
vast
majority
of
people.
In
this
call,
we
have
to
support
them.
It's
our
job,
it's
our
job
as
a
community,
and
we
have
to
lead
by
example.
L
M
Yeah
I
think
we've
been
debating
a
lot
whether
or
not
we
call
these
things.
How
we
call
these
things
and
saying
that,
oh,
we
can't
call
them
bad
because
then
we're
blaming
people
or
something
I,
don't
think
anything
in
Stevens
proposals
suggest
that
we're
blaming
someone
for
saying
something:
racist,
we're
saying
that
these
terms
have
these
meanings.
These
meanings
are
not
ok,
we
need
to
change
them,
we're
not
blaming
anyone
and
saying,
oh,
you
were
being
racist
or
saying
these
terms
are
offensive.
Let's
remove
them,
I,
don't
think
that
needs
more
debate
here.
M
I,
don't
think
that
relates
to
sig
architecture
at
all,
I
think.
The
only
thing
we
need
to
know
is:
can
we
produce
some
policy
and
put
it
into
the
review
process?
I
want
to
make
one
further
comment,
I
think
in
terms
of
a
time
down,
for
this
Erin's
comment
is
about
what
I
would
have
expected,
we
should
produce
policy.
M
We
should
reconcile
that
policy
against
pre-existing
language
and
we
should
find
the
convergence
point
between
that
policy,
existing
and
being
applied
to
future
work
and
the
past
work
being
cleaned
up,
and
then
that
is
the
end
of
the
work
group
and
the
other
SIG's
will
own
continuing
to
apply
the
policy
through
things
like
it.
Got
review,
documentation,
review,
insider.
D
It
seems
significantly
broader
and
I
would
expect
that
to
fall
more
into
a
code
of
context,
a
code
of
conduct,
a
code
of
conduct,
sort
of
the
situation
and
not
a
working
group
sponsored
just
by
sig
arch
I,
mean
I've.
Looked
through
the
proposals
in
this
list.
The
they
used
non
racist
language,
doc
and
I
want
to
enhance
clarity,
but
I'm.
Not
really
sure
that
labeling
words
like
deprecated
as
harmful
is
what
people
would
expect
as
opposed
to
looking
through
something
in
the
list
and
saying.
D
Oh
well,
deprecated
isn't
very
helpful
to
me
and
it's
not
obvious
to
me
yeah
how
we
as
a
group,
decide
which
ones
are
and
which
ones
aren't
problematic
and
I'd
really
like
to
know
that
when
the
working
group,
if
that's
what
the
working
group
is
gonna
fit
figure
out.
I'd
like
to
know
that
at
the
end
and
call
call
that
maybe
one
logical
stopping
point,
and
if
this
known
already
and
we're
gonna
apply
that
policy
inside
the
working
group,
I'd
like
to
understand
what
that
process
is
and
how
to
participate.
So.
K
K
This
is
the
idea
of
how
we
decide
something
is
harmful
versus
non
harmful
is
a
really
difficult
subject
in
regards
to
the
to
deeply
contentious.
Words
word
pairings
that
we
have
to
deal
with
right
now.
Master/Slave
and
blacklist
whitelist
I
have
erred
on
the
side
of
looking
at
academic
research
and
other
precedents
within
the
computing
community.
K
To
see
a
is
there
kind
of
independently
verified
research
around
the
implications
of
these
terms,
has
somebody
actually
taken
the
time
to
go
and
do
that
and
be
what
are
our
peers
elsewhere
in
the
community
doing
and
see,
as
others
have
mentioned,
are
we
even
using
the
term
correctly
because
I
think
if
we
look
at,
for
example,
something
like
taints
and
toleration,
x'
we're
not
using
the
word
taint,
like
other,
like
other
computing
packages,
vases
etc,
use
a
similar
word.
So
we're
twisting
a
metaphor
in
that
case,.
K
N
N
In
terms
of
how
we
write
the
Charter
for
this
I
think
it's
important
that
we
focus
on
the
positive
and
not
the
negative,
because
because
feelings
are
hard
and
because
people
can
feel
defensive
and
that's
not
the
intention
here
right
nobody's
charging,
whoever
came
up
with
the
term
master
or
white
list
black
list
of
being
hateful
or
intention
terms.
They
were
common
terms
of
art
and
we're
evolving.
N
You
know
becoming
enlightened,
and
so,
if
we
focus
the
wording
in
the
Charter
on
using
more
inclusive
language
as
opposed
to
eliminating
hateful
language,
it's
it's
a
really
subtle
distinction.
But
it's
I
think
it's
important
in
cutting
off
meaningless
debate,
but
I.
Don't
think
that
we
need
to
water
down
what
we're
doing
I.
N
Don't
think
we
should
be
afraid
of
the
values
that
we're
trying
to
express
here
that
we
want
to
be
more
meaningful
and
that
the
situation
in
the
world
is
in
fact
the
catalyst
for
this
and
that's
okay,
even
if
black/white
wasn't
racially
charged,
we
would
still
want
to
change
away
from
blacklist
neue
list
because
it
would
be
better
for
our
code.
But
that
is
not
the
only
reason
and
we
shouldn't
try
to
paper
over
these
changes
by
saying.
Well,
it's
better
technically
ignore
the
rest.
N
O
B
Don't
think
it
would
I
mean
we
already
changed
the
existing
instances
of
documentation
and
API
Docs,
and
now
that
this
Islam
I
read
are
I
think
this
would
be
something
that
we
would
steer
towards
other
terms
for
I
kind
of
wanted
to
avoid,
like
one-off
questions,
if
we
were
gonna
have
a
group
that
was
gonna
look
at
like
this
holistically.
That
seemed
like
a
good
thing
to
have
that
group.
Look
at
but
yeah.
B
If
someone
opened
up
PR
today
to
add
a
new
instance
of
that
I
think
we
would
guide
to
better
terms
if
we
want
to
adjust
API
guidance
kind
of
proactively
with
like
one-off
things
like
that.
I
don't
object
to
that,
but
it
seemed
like
it
might
be
easier
to
do
it
as
part
of
but
good
on
it
still
you're
gone
and
then
oh
I
I
didn't
want
to
know
it's
something.
B
I
I
think
when
there
is
an
example
of
something
that
there's
broad
agreement
over
like
the
whitelist
blacklist,
thing,
I,
think
daniel
said
and
I
would
agree.
I,
don't
think
anyone
would
be
opposed
to
guidance
around
that
and
moving
away
from
that,
it's
easy
to
say
things,
sort
of
sort
of
the
way
Jake's
said
them,
which,
on
the
one
hand,
I
agree
with
these
particular
terms.
But
I
disagree
with
the
approach,
which
is
to
say,
like
the
debate,
is
over
like
there's
no
debate.
These
need
to
go.
They
need
to
go
now.
B
White
people
should
staff
this
like
for
these
particular
terms.
I
think
there
is
agreement,
but
I
want
to
be
careful
that
we
don't
bypass
discussion
and
understanding
in
the
future.
Just
because
someone
says
this
term
is
harmful
and
I.
This
is
kind
of
the
the
Supreme
Court
method
of
looking
at
something
like
we're,
not
just
deciding
this
one
particular
instance
we're
also.
B
The
way
we
respond
here
will
also
have
implications
in
the
future
and
so
being
considered
and
having
the
discussion,
even
if
it's
very
clear
to
some
people
in
the
community
that
I
don't
know
what
discussion
we're.
Having
I
think
it's
important
to
have
the
discussion
for
the
benefit
of
the
people
who
need
to
live
under
the
decision
and
if
it's
as
clear
and
unequivocal
as
we
think
it
is,
then
I
think
the
discussion
will
be
able
to
be
had
and
the
decision
would
be
able
to
be
made.
B
C
Sorry
to
cut
through
all
of
but
the
the
reason
that
I
have
asked
Celeste
and
Zack
and
a
few
of
the
other
people
that
are
on
the
call
to
attend.
This
meeting
is
so
that
we
could
have
a
decision
from
cig
architecture
regarding
the
formation
of
the
working
group,
so
so
so
sorry
to
cut
through
the
list.
But
I
would
love
to
hear
from
the
chairs.
E
Stephen,
we
still
have
a
little
bit
of
time,
so
I,
don't
think
we'll
get
to
anything
else
today.
But
let's
these
people
still
in
the
queue,
let
let's
let's
wrap
up
with
them.
Please
so
I
have
this
my
turn.
So
let
me
speak
a
few
minutes
so
so
far
we
haven't
so
one
of
the
things
that
Paris
mentioned
was
okay.
If
I
submit
a
PR,
will
you
merge
it
immediately?
So
we
have
other
things
that
are
already
in
the
community
right
like
we
have.
E
You
know
we
have
language
around
deprecation
policies
and
things
like
that,
so
I
think
we
have
to
like
look
at
those
things
as
well.
For
sure
and
not
you
know,
just
try
to
fix
the
problem
as
a,
but
then
this
will
the
the
problem,
Celeste
highlighted,
will
come
back
again,
which
is
like
it's
hard
to
do
this
change,
and
then
you
know:
how
do
we
how
we
do
we
make
sure
that
we
are
not
in
the
same
position
as
we
were
before
so
that
comes
so.
E
J
You
know
what
we're
what
we're
trying
to
do
and
the
vast
majority
of
them
are
supportive
of
the
work
that
this
working
group
is
trying
to
do
so
yeah
that
stuff.
That
was
my
entire
comment
is
just
like.
You
know,
let's,
let's
sponsor
the
working
group,
and
then
we
can
figure
out
all
the
details
in
there
because
that's
the
whole
point
of
the
working
group.
A
I'll
just
jump
in
them,
so
in
principle,
I'm
in
support
of
the
working
group
and
the
goals
I.
You
know
I
think
there
are
details
around
the
transparency
of
allocations
are
made
and
that
will
be
part
of
the
Charter
and
part
of
the
moving
down
that
for
work
as
I
said.
So,
that's
a
chair.
That's
my
nice
table.
E
F
C
L
H
Zachman
Zdenek
so
of
the
motions
that
I've
heard
so
far
to
create
a
board
of
review
that
ensures
whether
people
are
comfortable
with
changes
or
not.
I
think
this
is
a
terrible
idea
and
I
think
this
is
because,
if
we
put
a
person
who
was
harmed
by
language
to
the
experience
of
determining
whether
or
not
that
harm
was
real
based
on
other
people
who
don't
also
share
that
experience,
we
are
never
going
to
remediates
the
harm
done.
It
will
just
keep
on
going
because
it
will
be
a
long
litany
of
people
saying
well.
H
H
Well
I
think
it's
important
to
trust
that
the
work
of
the
working
group
will
have
the
people
in
it
necessary
to
make
the
the
informed
changes
that
are
going
to
stop
harm
and
make
the
project
more
welcoming
and
I.
Don't
think
that
we
should
be
subject
to
whether
or
not
white
people
are
comfortable
with
changes
to
language
that
people
of
color
tell
them.
Are
racist
I
think
that's
never
going
to
produce
a
happy
or
a
healthy
result,
so
I.
E
That
nobody
was
saying
that
this
is
a
review
board.
This
is
this
was
more
of
like
who
all
need
to
participate
in
this
working
group
and
make
sure
that
they
are
their
voices
are
there.
So
in
this
case
the
code
of
conduct
committee
was
not
there
in
the
original
email
thread.
Now
we've
made
that
connection
saying
we
need
to
make
sure
that
they
are
involved.
You
know,
along
with
sharing
as
well.
P
Yeah
so
I
guess
speaking
as
the
other
secure
on
cigar
ch
I'm
in
favor
of
the
working
group,
I
think
what
we
need
to
talk
about
the
next
steps
so
like
to
my
knowledge.
There
wasn't
a
pull
request
that
we
can
officially
+1
or
endorse
I
feel
like
there's
been
feedback
in
this
call
about
potential
updates
that
could
be
made
to
that
proposal
and
I
will
leave
it
to
Stephen
and
the
proposal
authors
to
decide
if
they
want
to
make
those
updates,
but
I
think
for
myself.
E
G
I
don't
know
if
I'm
just
going
to
restate
what's
already
been
said
so
to
verbally,
say
what
I
said
in
chat
I've,
you
sort
of
the
lifecycle
of
this
working
group
in
three
distinct
phases.
One
make
a
punch
list
which
Celeste
has
sort
of
put
together
some
of
the
really
obvious
things
to
come
up
with
a
set
of
policies
that
we
can
use
as
guidance
going
forward.
G
I
kind
of
feel
like
one
of
those
policies,
should
be
how
we
determine
you
know
things
to
add
to
the
punch
list
going
forward
and
then
three
is
reconciliation
against
the
policies
that
we
collectively
have
agreed
upon
and
I
get
it
I'm
a
white
guy
saying
this
like
and
I
I
heard
Jace's
passion
and
I
that
this
is
beyond
debate
and
for
the
items
that
are
currently
on
the
punch
list.
I
would
agree,
and
there
also
here
Zack
saying
that
we
don't
want
to
put
any
more
burden
on
those
who
feel
compelled
to
use.
G
Like
so
I'm
willing
to
make
sure
that
the
folks
in
the
working
group
put
their
trust
in
inappropriate
sets
of
people
or
person,
I'm
not
sure,
like
I,
could
envision
a
scenario
where
it's
sort
of
the
code
of
conduct,
committee,
kind
of
comes
up
with
suggestions
down
the
line
or
amendments
down
the
line.
But
I
do
feel
like
we
need
to
have
a
process
for
amending
our
punch
lists
or
our
policies
going
forward.
That's
all
like
I
am
ociffer
ously
in
support
of
this
effort.
A
G
Adheres
to
the
values
of
this
project,
and
so
in
general
I
think
we
favor
inclusively
and
in
general
I
think
we
favor
transparency
I
recognize
there
are
times
where
we
need
to
be
sensitive,
but
you
know
I
just
hope.
We
take
that
into
account,
and
that's
me
speaking
I
guess
is
a
steering
committee.
Member.
E
So
from
my
side,
the
other
thing
I
want
to
say
here
is
that
there
is
work
to
be
done
right.
We
don't
have
enough
enough
people
of
color
who
are
here
right,
so
we
have
work
to
do
in
terms
of
mentoring,
getting
more
people
on
board
and
get
them
to
positions
of
influence
and
power
that
kind
of
stuff.
We
need
to
do
a
lot
of
lot
more
work
there
as
well.
This
is
not
the
end
of
the
story
by
just
making
some
changes
in
some
documentation
or
some
code.
L
Can
I
just
add
that
I
have
absolute
faith
and
trust
in
all
of
us
to
do
the
right
thing?
That's
what's
drawing
me
the
community
in
the
beginning,
and
it's
what
remains
a
draw
for
me
today
that
you
all
have
huge
hearts.
You
care
you
work
hard
and
we
can
do
this
and
we
can
do
it
in
a
way
that
doesn't
destroy
our
project
or
our
community.
We
can
do
this
together.
Okay,.