►
From YouTube: SIG Contributor Experience 20180307
Description
Weekly meetings, find more information here: https://github.com/kubernetes/community/tree/master/sig-contributor-experience
A
B
Right,
thank
you,
everybody
for
coming
to
this
week's
edition
of
contributor
experience.
We
do
have
a
good
amount
on
the
agenda
today.
Today
is
a
automation
and
people
meeting
for
those
who
don't
know
every
other
week
we
try
to
state
to
just
people,
processes,
things
I,
contributor,
guide
and
mentoring,
and
things
like
that,
because
automation
and
workflow
can
definitely
take
over
a
meeting
in
the
decision-making
around
that.
So
that's
what
we
are
doing
today.
Actually
it
will
be
a
mixed
meeting
and
I
am
putting
the
notes
in
the
chat
right
now.
C
Hello,
so
it's
my
first
meeting
I
am
the
guy
from
CNCs
who
is
developing.
That
starts
dashboards
for
the
kubernetes
and
actually
does
all
I'm
working
on
this
at
the
moment.
So
if
anybody
wants
some
new
dashboard
or
maybe
have
some
feedback
about,
the
existing
ones
feel
free
to
go
to
CN
CF
dashboards
on
github
and
create
issue,
I
got
the
rest,
any
feedback
as
soon
as
possible.
That's
all.
B
B
D
D
B
Awesome
all
right
so
we'll
work
on
that
today,
all
right,
our
next
major
agenda
item
we
actually
have
Joe
on
the
line
thanks
Joe
for
joining
us
today,
Joe
did
put
in
the
community
site
cap
for
those
who
don't
know
what
a
cap
is.
It's
the
community.
It
excuse
me
kubernetes
enhancement
proposal
and
the
links
are
in
the
chat.
Excuse
me
in
the
agenda
for
the
assigning,
approver,
reviewer
and
also
Joe
added
some
things
to
the
proposal
itself.
E
E
That
that's
great
I
first
wanted
to.
You
know
what
the
kept
process
I
think
this
stuff
is
still
no
we're
still
refining
it.
It's
not
a
done
deal,
etc,
etc.
The
idea
there
is
that
we
can,
you
know
a
lot
of
times
when
people
are
putting
design
Docs
or
something
in
there.
The
there's,
like
you,
know,
twelve
different
discussions
going
on
at
once,
and
you
end
up
with
like
a
300
message.
E
Pr
and
the
latest
state
of
what's
been
decided
you
have
to
like
it's,
you
know
it
takes
you
hours
to
figure
out.
What's
up
with
a
particular
thing,
one
of
the
goals
out
of
the
cap
process
is
you
know
if
you
can
agree
on
something
check
it
in
and
then
so
that
the
proposal
itself
is
not.
You
know
approved
until
it
moves
into
the
implementable
phase
right,
so
so
pretty
much
everything
everything
that
happens
up
until
you
sort
of
flip
that
status
bit
is
still
very
much
provisional.
You
can
change
it
like
it.
E
B
E
So
we
don't
sit
around
staring
at
each
other
for
months,
which
is
it's
so
easy
to
do
so
so
there's
two
there's
two
PR
s.
The
first
PR
is
to
is
to
have
you
Paras
ensure
your
lead
on
on,
contributes
and
I.
Think
that's
probably
the
right
place
for
this
stuff
to
be
to
be
this
group
and
the
day
you're,
the
one.
The
decision
in
terms
of
you
know
where
and
how
I'm
on
hotel
Wi-Fi.
Let
me
off
my
video,
but
you
know
it.
E
You
know
you'd
make
the
final
call
on
on
this
stuff
in
Ana
and
then
there's
a
set
of
reviewers
of
folks
that
we
expect
to
be.
You
know,
involved
through
the
sort
of
the
the
the
the
the
process
so
that
they're
up
to
speed-
and
you
know
they're
involved
with
it
versus
you-
know
somebody
swooping
in
at
the
last
minute
to
say:
hey,
don't
no,
don't
do
that
so
trying
to
get
some
of
those
people
identified
now
so
that
we
can.
We
can
have
some
consistency
as
we
go
through
this
decision-making
process.
E
So
that's
the
first
PR
and
you
know
we
can.
We
can
add
more
reviewers
there
later
or
and
change
that
stuff
up,
but
I
just
wanted
to
get
get
something
in
there
and
then
I
also
added
sig
Docs
as
a
as
a
as
a
involved
sig
or
what
is
the
the
nomenclature
there
but
like
as
a
you
know,
impacted
sig,
because
you
know,
obviously
they
have
some
interest
in
this,
and
so
at
least
didn't
sort
of
scoping
it
out
so
want
to
make
sure
that
they're
in
the
loop
on
that.
B
B
B
Right
so
I'll,
just
I'll
just
shoot
off
some
of
them,
so
it
looks
like
one
of
the
questions
into
here
is
what
the
domain
would
be.
Ultimately,
would
it
be
community
god
kubernetes?
Would
it
be
contributor
kubernetes?
So
this
to
me
indicates
that
you're
favoring
a
completely
different
site,
meaning
off
of
Quran.
He
said
io
/
like
something
or
would
this
be
running
on
the
same
tool
chain
as
the
current
kubernetes
site,
yeah.
A
E
A
bunch
of
reasons
in
the
last
section
there
and
the
structure
of
the
URL
is
really
driven
by
that
our
tool
chain
is
not
set
up
such
that
we
can
have.
You
know
multiple
sites
hosted
at
the
same
at
the
same
domain.
To
us,
that's
just
not
how
natla
fireworks,
and
so
so
if
we
were
gonna.
If
the
workflow
said
that
we
went,
you
know
that
everything
went
through
the
the
kubernetes
website
repo.
Then
it
would
be
under
kubernetes.
You
know
dub
dub
dub
kubernetes
do.
E
F
I'm
done,
sir
yeah
I
thought
they
why
the
workflow
was
very
rational
about.
You
know
what
the
constraints
are
within
the
Ducks
workflow
today
and
I'm,
just
one
of
the
maintainer
there,
so
I
I
wouldn't
say
that
I'm
necessarily
speaking
for
any
consensus
for
you,
but
I
think
all
those
problems
are
things
that
we
should
try
to
surmount
and
not
have
yet
another
site,
especially
with
the
start
of
the
problem.
Definition.
F
Is
that
there's
too
many
places
to
find
information
as
it
is
today
so
I
would
really
prefer
if
we
can
to
figure
out
how
to
solve
the
problems
for
the
workflow
into
the
docks
repo
and
build
it
into
the
same
site.
Some
tidbits
on
the
back
end.
It
may
not
be
terribly
obvious
from
outside
the
docks
community
is
we're
about
to
change
our
tool
chain
fairly,
significantly
migrating
to
Hugo
after
the
110
release.
We
haven't
set
a
firm
date
on
that,
but
we've
agreed
that.
F
F
The
other
is
that
with
the
addition
of
the
prow
automation,
plugins,
there's
no
reason
it
couldn't
have
a
subtree
of
the
repository
completely
available
to
a
whole
different
set
of
approvers
and
have
that
have
its
own
workflow
mechanism
as
a
part
of
that
process,
so
that
we
could
add
the
relevant
folks
from
community
in
there.
You
could
just
approve
what
you
want
and
add
in
there
there's
gonna
be
a
similar
need
for
that
from
the
blog
that's
going
in,
but
they
see
it's.
F
The
F
blog
is
migrated
into
kubernetes
io
and
it's
gonna
need
its
own.
Workflow
I
fully
expect
not
be
bound
to
the
same
documentation,
style
standards
that
we
put
on
to
the
regular
internal
documentation.
So
I
think
there's
already
a
place
for
that
to
happen,
and
it's
going
to
need
to
happen.
It
just
needs
to
do
the
work
to
make
that
happen.
F
The
last
part
was
there
seemed
to
be,
and
I
may
have
misread
this
back
misunderstanding-
that
the
docs
site
was
branched
and
locked
and
that
everybody
saw
just
a
constantly
lock
site
and
that's
not
the
case
for
Docs.
It's
an
evergreen
site
that
we
do
merges
to
master.
They
get
updated
immediately
in
the
live
site.
F
There
are
probably
other
things
that
I'm
missing
I
haven't
had
a
chance
honestly
to
review
in
great
depth
the
proposal,
but
I
think
the
things
that
Joe
was
calling
out
are
all
things
that
we
can
overcome
and
achieve
what
compete
in
the
same
site
and
I
would
argue
that
it's
a
much
more
effective
use
of
our
time,
because
human
resources
are
the
most
constrained
resource.
We
have
to
do
that
in
a
singular
site,
rather
than
splitting
it
up
and
possibly
becoming
multiple
sites
that
you
know,
then
only
partially
get
updated
as
they
go.
B
Question
in
the
chat
was
what
exactly
is
the
dock
site,
that
is,
the
repo
that's
kubernetes
/
web
site
and
technically
the
dock
steams
kubernetes.
Do
the
Linux
Foundation
yep
question.
So
let
me
let
me
just
repeat
back
something
that
you
said
just
so:
I
get
it.
So
what
you're
saying
is
if
we
did
a,
for
instance,
a
contributor
site,
and
it
was
kubernetes
at
I/o,
slash
contributor.
F
With
that
right,
that's
that
pause,
that's
not
how
it
currently
works
within
Cooper,
the
repo,
but
the
tool
change
so
forth
us
setting
up
an
approvers
file
for
a
directory
where
we
could
set
say
you
Joe,
betta,
George,
whoever
write
as
approvers
and
then,
as
you
add,
the
lgt
em,
and
approve
comments
to
the
poll
requests.
Those
would
be
acted
on
as
though
they
had
full
approval
to
be
merged
in
just
based
on
how
proud
works.
A
F
That
that's
right,
but
III,
think
it's
worthy
because
I,
think
least
I
would
argue
that
it's
more
beneficial
for
us
to
key
things
together
and
fix
the
workflow
constraints
to
allow
you
guys
to
do
what
you
need
to
do
to
not
have
the
explosion
of
multiple
sites,
because
I
agree
with
the
fundamental
problem.
There
are
too
many
issues
too
many
places
right
now,
where
things
get
hidden
like
design,
Docs
or
currently,
one
of
the
things
I
keep
getting
bug
of
is
about
hey
this
document
it.
Well
it's
in
a
design
doc.
E
This
these
are
interesting
options.
I
mean
last
time
we
talked
to
the
docs
folks,
the
idea
around
sort
of
changing
up
the
workflow
such
that
you
know
folks
in
the
community
could
make
changes
to
the
website
without
somebody
from
sig
da
Oxana
proof.
That
was
not
something
that
was
on
the
table.
So
that's
definitely
a
new
option
here.
I
think
the
discussion
around
hugo
or
jekyll,
or
have
you,
I
think,
is-
is
completely
parallel.
E
The
the
tool
change
that
used
to
generate
the
site
is
I,
think
a
separate
issue
from
sort
of
the
work
flow
around
approval
and
such
so
I
think
you
know,
you
know
getting
hung
up
on
Hugo
or
not
Hugo
is
is
somewhat
of
a
red
herring
in
my
mind
and
something
that
we
want.
We
want
to
avoid
if
we
did
go
through-
and
this
is
this
is
something
that
I
think
we
have
to
sort
of
think
about
the
social
implications
about
and
and
right
now
so
like
like
in
the
fullness
of
time.
E
Ideally,
what
we
would
want
is
we
would
want
everything
in
the
community
repo
take
the
list
of
SIG's
that
kept
the
design.
I
mean
it's
all
be
visible
and
searchable
on
on
some
public
facing
websites
as
we
go
ahead,
and
do
that
though,
if
it's
all
in
the
docks
repo,
then
essentially,
what
we're
saying
is
that
you
know
over
time
we
deprecate
the
community
repo
and
the
website.
E
Repo
essentially
takes
over
that
role,
which
is
not
necessarily
a
bad
thing,
but
I
think
that
there's
you
know,
there's
there's
definitely
some
implications
in
terms
of
putting
some
of
the
core
parts
of
our
sort
of
community
governance
into
something
into
a
repo
called
website
and
and
and
I.
You
know,
and
in
terms
of
you
know
the
discussion
around
sort
of
multiple
sites
and
bringing
this
stuff
together.
E
I
think
the
the
issue
here
really
is
just
the
smattering
of
markdown
that
we
have
spread
across
a
ton
of
different
repos
and
providing
a
way
for
for
that
stuff
to
come
together,
and
so
you
know
if
we
did
go
through
and
build
out
a
community
site
that
was
separate
from
the
main
sites.
You
know
wouldn't
be
perfect.
We
wouldn't
be
down
to
one
single
site,
but
it
would
be
a
improvement
here
and
then
the
other
parallel.
E
That
one
is
is
that
we
have
plenty
of
sites
that
are
dynamic
tools
that
are
also
hosted
on
kubernetes,
IO
and
and
because
they're
dynamic,
there's
no
sort
of
call
to
try
and
sort
of
work
these
into
the
architecture
of
the
main
site.
So
you
mentioned
prowl
there
is,
you
know,
there's
proud
self,
proud
of
kubernetes
IO.
Why
is
that
not?
You
know
kubernetes
dot,
io,
/,
prowl,
right,
I.
Think
that
there's
a
question
of
like,
like
you
know,
there's,
there's
different
websites
that
we
have
for
different
purposes.
E
I
think
the
only
difference
here
is
that
these
are
both
relatively
static
sites
that
are
about
documentation,
but
their
documentation
for
different
places
for
different
audiences,
and
so
so.
I
think
that
that
there's
a
certain
amount
of
like
well.
Both
of
these
things
are,
you
know,
content
largely
content
sites.
So
therefore
they
should
be
the
same
thing
and
that's
something
that
I
think
is
is
a
bit
of
an
arbitrary
distinction
and
so
I'm.
E
Seeing
in
the
chat
Joe,
you
said
a
couple
of
things
here
that
we
do
quite
a
bit
of
importing
from
other
repos
on
an
inconsistent
basis.
Now
so
I
addressed
that
in
the
in
the
in
the
design,
doc
I
think,
that's,
you
know
not
being
able
to
preview
what
the
thing
looks
like
you
know.
Having
you
know,
the
the
tooling
that's
been
built
there
so
far
has
been
relatively
brittle.
That's
tooling!
That
doesn't
necessarily
end
with
with
user
a
user
end
value.
Api
documentation
is
a
key
example,
so
API
documentation
is
a
very
you
know.
A
E
Yeah,
that
is,
that
the
API
documentation
is
automatically
generated.
This
is
not
something
that's
part
of
a
human,
workflow
and
and
I
think
we
do
have
a
problem
right
now,
where
right
now,
if
I,
you
know
the
API
documentation
is
generate
from
the
types
go.
The
comments
and
types
go.
If
I
make
a
fix
to
the
comments,
the
type
go
you
know,
seeing
that
show
up
on
the
website
can
take.
E
You
know
a
month
right
and
so
I
think
having
a
very
long
feedback
loop
there,
which
obviously
would
not
be
as
long
as
as
any
other
process
that
we'd
come
back,
come
up
with
having
a
very
long
feedback
loop
there
in
some
ways
discourages
people
from
actually
making
those
fixes,
because
they
don't
get
that
sort
of
dopamine
hit
of
like
look
I
did
something
right.
It's
like
look
I
did
something
in
like
a
month
from
now.
D
I
would
just
like
to
make
it
so
that
we
don't
have
to
go
through
and
edit
all
the
other
pages
like
in
the
community
repo
like
when
I
was
doing.
This
imported
thing,
I
had
to
go
back
and
add
stubs
and
all
of
a
sudden
I
had
to
pass
a
bunch
of
Doc's
tests
that
were
totally
foreign
to
me
and
I
had
no
idea.
All
I
want
to
do
is
write
markdown
and
commit
like
if
we
gotta
make
it.
You
know
what
I'm
saying
like
I
really.
B
H
Think,
just
from
a
workflow
perspective,
I
think
like
stuff,
like
design
documents
and
stuff
like
that.
Putting
that
on
a
website
would
be
kind
of
odd
before
they're,
ready,
I
think
there's
certain
elements
within
the
kubernetes
repo
that
from
Joe's
point
a
cultural
change,
doing
that
it's
gonna
just
be
gonna,
hurt
developers
heads
but
yeah
a
lot
of
the
information.
You
know
what
you're
saying
Paris
needs
to
be
up
on
the
website.
I
think
we
need
to
go
through
and
identify
what
should
be
website
what
should
be
community
repo,
maybe
community
repos
the
wrong
name.
B
E
Actually,
I
disagree
with
that
I
think
you
know
when
I
said
that
the
community
repo
would
disappear.
What
I
mean
is
that
that
all
the
information
in
the
community
repo?
Would
you
know
we
have?
We
have
a
fork
in
the
road
here?
It's
like
do
you
know.
Do
we
take
the
information
that
came
into
your
repo
and
we
hosted
something
like
urban
community
to
criminales,
dot,
IO
right
and
essentially
create
a
site
like
that?
Or
do
we
take
everything
in
the
community
repo
and
we
host
it
in?
E
You
know
kubernetes
io
/
community,
or
do
we
not
right,
which
is
a
you
know,
the
null
hypothesis
there
and
you
know
and
when
I
say,
get
rid
of
the
community
repo
if
we
want
to
join
it
in
with
the
main
Doc's
site,
and
we
don't
want
to
go
through
a
brittle
import
process,
then
essentially
we
take
everything
in
the
community
repo.
All
those
documentation
and
we'd
have
to
move
those
to
the
website
via
repo,
so
it
would
essentially
fold
the
community
repo
into
the
website,
repo,
which
I
think
that's
a
cultural
change.
E
B
E
D
D
Sorry,
but
when
I
google,
when
I
google
I
just
right
now,
just
googled
for
the
contributor
guide,
just
as
an
example,
I
get
the
broken
import,
which
is
fine,
we
have
to
fix
that
or
whatever
and
then
I
get
the
github
thing
itself.
That's
why
everyone's
passing
around
blah
/
master,
slash
blob
yeah,
like
I,
don't
understand
why?
E
Mean
my
god
I
gotta,
be
honest
here.
My
gut
is
that
these
audiences
are
different
and
you
know
we're
predicating
this
on
tooling
and
agreement
around
owner
isn't
proud
that
isn't
there
and
we've
seen
conflicting
things
and,
in
my
mind,
the
benefit
of
having
this
thing
be
kubernetes,
io,
/,
community
versus
community.
You
know
their
community
kubernetes
io.
I
think
from
a
from
user
point
of
view.
It's
it's.
G
A
G
B
B
H
So
here's
what
I
go
back
to
helping
a
brand-new
contributor
over
the
last
couple
of
days
getting
the
CLA
worked
out
right
every
time
the
CLA
is
busted.
They
have
no
idea
that
we
have
documentation
on
really
good
documentation
on
how
to
fix
the
CLA
fix
or
github
user
and
amend
it
and
I
assume
that
they're
going
to
Google
and
googling.
H
You
know
kubernetes
ççla
know
maybe
we're
not,
but
we
need
to
figure
out
how
to
I
think
what
we're
trying
to
do
is
do
two
things:
improve
the
experience
of
our
developers
and
our
users
and
make
it
easier
to
get
Doc's
out
to
them,
but
I
think
that
make
it
easier
to
get
at
Doc's
out
to
them.
We
have
to
figure
out
how
they're
looking
for
the
docs
and
what's
the
best
way
to
get
that
locks
to
them
ends
sounds
this
is
kind
of
what
I
go
back
to
yes,.
D
I
Just
gonna
mention
like
there-there
is
how
people
will
find
and
consume
the
documentation
and
there's
also
how
the
documentation
is
organized
on
the
backend
as
far
as
those
who
want
to
contribute
and
edit
the
documentation
and
I
think
the
the
stronger
opinion
that
I
have
on
it
is
having
all
of
this
documentation.
All
in
every
repository
called
website
would
be
confusing
for
somebody
to
go
and
find
as
far
as
like,
where
do
I
go
to
edit
this
back-end
information,
because
I
know
a
lot
of
people
even
on
the
consuming
side.
Look
for
it
in
github.
I
D
Yeah,
just
just
as
a
data
point,
if
you
do
CLA
kubernetes,
it
takes
you
to
the
direct
github
page,
but
I
think
the
point
about
having
this
as
a
site
is
like
it's
just
a
raw
markdown
page
right
and
for
the
CLE.
That
makes
sense.
But
if
you
wanted
to
do
something
like
show
me
all
the
caps
across
the
board
that
are
currently
open
right,
that's
kind
of
a
developer
thing,
but
raw
markdown
wouldn't
make
sense
stuff
like
that.
All.
J
B
As
a
owner,
we
need
open
source
project,
were
the
only
ones
that
do
not
have
contributor
information
on
a
site
somewhere.
I
think
we
have
stuff
on
community
right
now,
but
it
doesn't
necessarily
even
render
on
mobile
I
think
the
experience
for
visibility
is
lacking,
like
mentor
programs,
and
things
like
that.
I
really
would
rather
not
linked
to
a
github,
and
it
just
helps
when
we
have.
B
D
E
Yeah,
so
so,
from
my
point
of
view,
I'm
looking
at
like
like
pile
of
markdown
and
github
works
up
to
a
certain
point,
the
problem
there's
a
couple
of
problems
that
we
have
right
now
in
kubernetes,
and
these
are
really
separable
issues.
The
first
one
is
that
the
the
markdown
is
split
across
a
bunch
of
repos,
and
so
it's
not
very
discoverable,
and
so
there
is
no
information
architecture
across
this,
so
I
think
that's
a
problem.
E
Number
two
is
at
the
browsing
experience
for
hub
markdown
and,
like
things
like
a
table
of
contents,
metadata
searching
sorting
those
things.
Basically,
not
a
bigger
set
of
documentation
is
going
to
be
problematic
right.
We
already
see
this
with.
We
have
design
proposals
that
are
based
levels
of
our
date.
There's
no
ordering
there's
no
structure
to
those
things.
E
One
of
the
things
that
I,
you
know
that
influenced
me
for
the
cap
process
was
looking
at
the
the
Python
pet
process
and
one
of
the
things
for
me
that
really
works
for
the
Python
pet
process
is
the
fact
that
they
have
an
index
listing
all
the
pets,
their
current
state,
where
they're
at
right
so
I'd
like
to
build
something.
That's
inspired
by
that
that
that
really
provides
an
approachable
way
to
get
to
this
stuff.
E
E
So
my
take
on
it
is
can't
we
do
a
thin
static
site
on
top
of
the
the
markdown
that
we
haven't
github
right,
I,
don't
want
to
do
something
super
heavy
here.
You
know
now
like
so
like
we
have
like
the
the
doc
side
as
it
exists
today.
Not
you
know
not
talking
about
the
few
of
which
is
relatively
heavyweight
in
terms
of
editorial
process
and
and
for
a
good
reason.
E
Right,
I
mean
there's,
there's
reasons
why
why
we're
taking
you
know
see
that
very
seriously,
there's
a
pile
of
markdown,
which
is
like
a
freaking
free-for-all,
where
nobody
can
find
anything,
and
it
is
an
indexed.
Can
we
do
something
for
the
community
fixing
stuff?
And
that's
really
that's
really.
The
art
yeah.
D
Mostly
I
wanted
nice
just
nice
URLs,
and
it's
like
okay.
Can
we
slap
Hugo
on
this
and
generate
something
in
15
minutes
like
I?
Didn't
it
wasn't
clear
to
me
until
I
saw
the
docs
document
that
they
were
planning
on
redoing
the
site
which
you
know
I
didn't
find
out
about
it
until
our
face-to-face
right
where
I
was
like
what
is
what
is
the
website
have
to
do?
You
know
I
was
thinking.
D
This
would
be
more
like
a
convenience
for
us,
because
I'm
always
forgetting
get
that
cait's
that
I
owe
or
whatever
it's
supposed
to
be.
You
know
it's
like
can't.
We
just
slap
some
simple
CSS
that
makes
it
obvious
that
you're
not
on
the
user
end.
That's
right.
It
would
be
like
skin
different
towards,
like
you
know,
when
you
go
to
MSDN
right,
like
the
documentation
for
Outlook,
is
different
from
like
how
to
write
your
own
outlook,
plugin
I,
guess.
A
Cool
that
makes
sense
thanks
for
going
into
that.
Just
you
know
it's
nice
to
have
that
as
a
background.
So.
G
I
can
also
maybe
throw
in
one
more
thought
on
this,
and
that
is,
if
you
look
at
some
of
the
popular
open
source
projects
that
are
rather
simple
with
very
few
committers
or
contributors
to
them.
That's
when
you'll
find
they're
contributing
files
in
markdown
in
their
projects.
Once
you
get
to
projects
that
are
more
complicated,
where
they
have
lots
of
people
being
involved
in
contributing,
and
you
scale
out
contributors
because
a
lot
of
projects
you
look
at
some
of
those
product
popular
open-source
projects,
don't
have
that
many
contributors
to
them.
G
It's
mostly
consumers,
and
so
they
it's
very
easy
to
onboard
contributors
they're
in
common
workflows
and
to
do
a
little
hand-holding.
But
when
you
get
as
many
contributors
as
we
do,
sometimes
it
just
takes
more
and
that's
where
the
kind
of
contributor
sites
and
community
sites
come
into
play
and
I'm
kind
of
noticing
that
trend
among
the
different
projects.
It's
scaling
out
people
rather
than
intruders,
rather
than
the
popularity
the
project
all.
B
B
B
E
I
mean
so
first
of
all,
I
do
value
Joe
heck's
input
into
this
and
all
the
folks
in
sigdoc.
So,
like
you
know,
I
think
you
know,
there's
there's
definitely
a
fine
line
to
walk
here
and
I
appreciate
the
concerns
there
I'm
happy
to
start
prototyping
this
stuff
just
so
that
people
can
get
a
feel
and
some
sort
of
concrete
ideas
around
this
stuff.
E
With
the
understanding
that
you
know,
if
we
look
at
this-
and
we
can
you
know
we
can,
we
can
decide
to
sort
of-
you
know,
pull
the
plug
on
it
and
go
a
different
direction
if
the
amount
of
to
any
amount
of
TLC
that's
going
to
be
required,
gets
out
of
control
because
I
think
that's
the
the
biggest
concern
is
the
amount
of
investment
to
bring
up
a
new
site.
I.
Think
the
example,
in
my
mind,
is
we
have
the
automation
of
generating
the
cig
list
out
of
60ml
right
now.
E
That
has
not
been
a
huge
burden
and
it's
been
a
huge
plus
on
the
community
site
in
terms
of
creating
a
consistent
view
of
what
our
SIG's
are
so
I
think
you
know
my
mind.
This
is
just
a
continuation
of
that
type
of
thing,
but
but
I'm
definitely
sympathetic
to
to
the
experiences
from
the
sigdoc
folks.
B
F
B
And
I
think
I
used
harsh
language
with
that
and
I
apologize.
That
was,
that
was
my
bad
I
did
not
mean
it
necessarily
in
a
negative
light.
Just
wanted
to
see
if
other
people
had
any
other
strong
objections
against
alright.
So
if
that
wraps
that
and
let's
move
on
to
the
next
agenda
item
Joe
thanks
for
joining,
if
you
need
to
drop,
that's
totally
cool
appreciate
your
time
all
right.
B
So
next
on
the
agenda
is
automation,
stuff,
I'd,
Kristoff,
I,
know,
I,
have
you
on
the
line
and
we
do
have
some
things
that
you
had
mentioned
and
pinged
us
and
github
about.
It
looks
like
for
one
point:
one
point:
ten
cycle
need
a
verify
script
test
to
confirm
that
new
vendor
dependencies
of
acceptable
open
source
licenses.
Do
you
want
to
talk
about
that
briefly,
I.
I
Yeah
I
can
quickly.
It
was
just
discovered
that
there
were
some
dependencies
that
were
imported
into
core
in
particular,
but
we
don't
really
have
any
monitoring
around
the
organization
as
far
as
importing
dependencies
that
have
a
license
that
is
just
not
compatible
with
the
apache
license
that
the
rest
of
the
kubernetes
source
code
is
licensed
under
the
process.
Right
now
for
dependencies
in
dependency
licenses
is
basically
Tim
Hakan
and
that
you
know
a
this
is
something
that
could
be
offloaded
to
a
bot.
A
I
End
in
a
couple
weeks,
but
maybe
for
a
111
cycle-
that's
something
we
want
to
consider
is
a
way
to
verify
through
automation,
be
able
to
cuss
scanner
dependencies
and
scan
the
license.
Files
make
sure
the
license
files
are
up-to-date
and
that
they
use
like
a
whitelisted
set
of
licenses
that
we
know
has
been
vetted
by
by
legal
and
it's
okay
for
import
to
the
project.
G
So
this
is
Matt
I'm
gonna
jump
on
to
things
on
that
real,
quick
one
is
the
software
to
build.
Such
a
bot
totally
exists
already
in
his
open-source
second
I
stumbled
across
a
SAS
service
that
does
this
recently
I
saw
it
on
somebody's
github
page
where
it
had.
You
know
like
passing,
build
and
all
those
other
normal
things
you
saw
and
another
one.
That
was
for
a
thing,
and
it
was
a
bot
that
did
the
license,
checking
as
a
service
and
would
look
over
dependencies.
K
J
B
Right
keep
lines
open
there
and
then
the
next
issue,
or
actually
did
anybody
else,
have
any
comments
on
that.
I
apologize,
I'm
steamrolling
through
the
agenda
right
now
comments
all
right.
Next,
we
have
an
issue.
It
looks
like
I
think
it
wasn't
necessarily
about
the
issue
itself
Christophe,
but
you
were
talking
more
about
communication
changes
and
how
our
to
me
changes
and
how
we
communicate
those
changes
and
things
like
that.
The
issue
itself
was
about
blunderbuss.
Could
we
use
github
reviewers
instead
of
assignees
and
then
your
comment
to
contribute?
B
Your
experience,
folks
was
says,
makes
you
think
about
the
idea
of
ownership
of
code
process
changes,
and
this
is
a
piece
where
the
process
could
be
better
and
it
was
initiated
from
the
tests
and
testing
infra
and
so
indigo
I
actually
did
lay
out
communication
stuff.
Did
you
see
that
or
are
you
going
to
somewhere
different
with
that?
No.
I
That's
exactly
where
I
was
going
to
and
the
fact
that
we
have
so
written
down
somewhere
like
hey.
This
is
what
contributor
experience
is
going
to
do
when
we,
you
know,
look
at
rolling
out
these
kind
of
changes,
especially
you
know
as
it
as
the
grit
there's
a
gray
area
in
the
middle
between
contributor
experience
and
and
cig
testing
and
tests
infra
that
we're
all
kind
of
on
the
same
page
about
what
you
know.
I
If,
because
it's
this
started
out
as
a
hey,
we're
need
to
reinvent
this
munch
github
Munzer
into
a
prowl
plugin,
but
in
in
the
midst
of
that
there
was
a
process
like
an
outward
facing
process
change
to
how
the
plug-in
would
function
and
Cole
sent
a
message
out
to
Cabrini's
dev,
and
there
was
nobody
complained.
Nobody
said
anything
so
I'm
fine
as
far
as
like
leaving
it
the
way
it
is,
and
now
all
use
github
reviews
totally
fine
with
that,
but
yeah
now
as
well.
I
B
B
Woody
kubernetes,
dev,
cig
leads
and
the
contributor
experience
mailing
list
all
in
one
and
we'll
also
announce
the
said
change
at
the
weekly
kubernetes
community
meeting
that
happens
on
Thursday.
Does
anybody
have
any
other
suggestions
or
ways
that
we
should
communicate
better
about
process
changes,
especially
org
wide.
K
B
B
We
tried,
we
tried
to
actually
create
an
announcement
channel
where
we
lock
it
down
to
only
certain
people
that
were
in
it,
but
slack
guidelines
say
that
that's
the
general
channel
and
it
looks
like
someone
changed
the
general
channel
to
the
kubernetes
dev
channel
and
that
has
5,000
plus
people
in
it.
So
it
would
be
difficult
for
us
to
switch
those
things
out.
Giorgia
looks
like
you
want
to
say
something:
yeah.
D
K
B
K
Cuz
I
think
he
was
in
one
championing
getting
rid
of
right
access
to
a
lot
of
the
repos
and
I'm
I
know
he
had
an
umbrella
issue
somewhere
of
all
the
tests
needed
in
order
to
remove
right
access
and
I
think
maybe
the
the
project
managers
teams
are
one
of
those
teams
that
we
had
specifically
because
we
couldn't
do
everything
with
automation
and
I.
Think.
K
The
last
thing
that
we
needed
to
get
done
was
the
ability
to
set
the
milestone
for
a
group
for
cig,
leads
and
milestone
maintained,
errs
within
the
project
and
last
week
I
wrote
a
plug-in
that
accepts
the
command
ford,
slash
milestone,
so
you
can
say
ford,
slash,
milestone,
be
110
or
b1
900
or
ford.
Slash,
milestone,
clear
that
or
remove
milestones
from
er's
huge
thanks
to
testing
for
us.
The
CJ,
cole
and
Steve
helped
out
a
ton
with
this,
but
I
believe
that
we
no
longer
need
the
milestone.
K
I
I
B
You
know,
there's
questions,
concerns
comments
about
any
of
the
automation
stuff
that
we
just
discussed.
There's
also
one
thing
another
bullet
on
the
agenda
that
I
don't
necessarily
want
to
spend
too
much
time
on,
but
that's
the
revival
above
for
new
contributors
label
or
some
other
wording.
Variety
I
mean
just
insert
like
good
first
issue,
which
is
already
the
github
standard.
You
know
something
along
the
lines
of
letting
other
contributors
who
have
either
a
never
contributed
before,
or
maybe
you
know
less
than
one
year
of
experience
or
something
along
those
lines
right
now.
B
The
issues
that
are
coming
in
from
contributors
are
that
the
Help
Wanted
label
isn't
is
complex
in
the
fact
that
it
looks
like
it's
for
very,
very
experienced
either
developers
and/or
contributors
and
that
it's
not
very
friendly
to
the
folks
that
I
just
mentioned.
What
we
need
to
do
here
is
file
an
issue.
B
Obviously,
we
also
need
to
come
up
with
a
naming
convention
and
also
include
the
removed
piece
as
well
in
there
and
then
also
the
one
of
the
most
important
pieces
to
this
is
education
around
how
to
use
this
to
the
broader
community
and
that
it's
available
and
that
they
should
be
using
it
when
they
can
I
know.
Some
of
the
other
groups
are
starting
to
use
good
first
issue,
since
it
is
the
the
github
standard
in
there.
B
I
Other
thing
that
I
would,
if
I,
can
just
jump
in
there
for
quick
sidebars.
The
thing
I
would
want
to
add
to
that
is
the
meteor
part
of
that
issue.
I
would
say,
is
the
proposal
and
the
process
around
like
when
things
should
apply
and
how
good
first
issue
and
Help
Wanted
would
work
together
so
like
kind
of
designing
how
it
should
work
and
well
how
we
want
it
to
work
any
bought
pieces
and
the
automation
pieces,
there
are
super,
simple
and
and
I
you
know.
I
can
definitely
volunteer
to
help
out.
I
If
somebody
is
like
scared
of
the
bots
end
of
things
and
and
how
things
are
done.
On
the
prow
side,
the
bigger
the
bigger
thing
there
would
be
figuring
out
like
how
we
want
this
to
work
both
for
contributors
searching
for
the
label
as
well
as
contributors
who
are
adding
the
label
and
removing
the
label
from
issues
also.
A
B
A
Yeah,
but
if
I'm
just
running
in
somewhere
and
I'm
a
new
contributor
but
really
I'm,
just
finding
an
issue
where
I
mean
maybe
then
I
wouldn't
add
to
help
one
at
label
but
but
see
I,
don't
know
if
I'm,
not
a
sake
lead.
How
do
I
know
when
and
how
to
add
the
Help
Wanted
label
and
or
versus
a
good
first
issue
label
like
you
know
how
do
I
find
that
out
just
finding
an
issue.
H
Go
ahead,
yeah,
that's
right,
I'm,
sorry,
Chris,
they're,
real
good
ways
just
to
ask
in
the
dev
development
channel
specifically
for
the
cig
that
owns
the
source
code
or
like,
for
instance,
with
Kubb,
ADM,
you'd,
ask
and
sync
cluster
lifecycle:
hey
is
this
a
good
issue
should
I
tag
it
and
there'll
be
more.
You
know,
developers
around
that
should
be
able
to
answer
that
question.
H
A
Well,
I
mean
not
necessarily
teaching
I
just
like
to
have
a
dog
somewhere.
That
says
something
like
this
roughly
is
a
good
I
wanted.
Something
like
this
is
a
good
first
contributor
issue.
If
there's
any
debate
or
doubt
in
your
mind,
of
course,
then
the
default
is
go.
Ask
someone
who
might
decide
who
might
know
better
than
you.
That's
fine,
but
I
do
one
there
to
be
like
this.
A
A
bucket
for
each
right
and
I
want
it
to
be
available
to
someone
who's
just
filing
an
issue,
because
I
don't
really
want
to
necessarily
ask
say
goodnight
every
time,
I'm
filing
a
documentation
issue
against
the
contributor
guide
right,
I'm,
just
like
well
I
want
someone
to
fix
my
links.
That's
kind
of
a
good
first
person
to
you
know,
I,
don't
know,
but
I
want
to
I
want
there
to
be
a
place,
perhaps
in
each
sig
like
it
should
somehow
it
feels
like
it's
contributing
issue
right.
A
A
I
mean
yes
and
I
guess.
My
question
is
like:
where
would
be
a
logical
place,
to
put
that
where
people
will
find
it,
because
this
is
something
that's
really
only
relevant
for
people
who've
been
in
the
code
base
for
a
while
yeah,
but
aren't
necessarily
sig
leads
and
might
not
really
necessarily
look
for
that
or
if
they
do
look
for
it,
how
can
we
make
it
that
they
can
find
it
easily?
A
B
H
H
B
Right,
we've
got
like
two
minutes,
not
even
left,
and
there
is
one
more
item
and
I.
Don't
I,
don't
necessarily
have
all
the
answers
to
this
one
right
now
either,
but
we
are
changing
leadership
roles
within
this
SIG
and
the
new
governance
template
has
come
out
and
been
merged
from
the
steering
committee.
This
would
be
effectively
changing
our
titles
to
chair,
as
well
as
adding
technical,
leads
and
sub
project
owners
that
would
be
based
off
of
the
project's
MD
file
that
I'm
in
the
middle
of
checking
in
right.
B
Those
are
also
projects
that
have
owners
files
if
you're,
following
along
with
the
owners
file,
changes
our
progression
of
changes.
You'll,
you
know
see
this
kind
of
coming
as
far
as
like
everything
being
now
needed
to
tie
to
voters
files
and
so
check
the
mailing
list
for
all
of
the
updates.
As
far
as
this
leadership
is
concerned,
but
each
one
of
you
that
are
currently
owning
one
of
those
sub
projects
that
I
mentioned
will
be
listed
as
a
sub
project
owner
and
then
all
of
all
the
other
folks
are
still
members.