►
From YouTube: SIG Contributor Experience 20180221
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Alright,
alright.
So
yesterday,
one
of
the
things
one
of
the
major
things
that
we
did
was
the
more
of
the
finalization
of
1.10
goals.
I
know
it
sounds
silly
considering
or
so
close
to
it
being
done,
but
we
do
actually
have
a
lot
of
work.
That's
coming
out
of
this
cycle,
I'm
also
going
to
be
sharing
the
almost
with
you.
If
anybody
has
those
handy
I'll,
actually,
no
I
got
him
right
here,
sharing
those
in
the
chat
as
well.
A
Let's
see
some
of
the
notable
items
on
the
goals
that
we
wanted
to
talk
about
today
was
that
we
do
have
a
coupon,
deep
dive
and
intro.
That
is
something
new
and
we
are
allowed
to
talk
about
it
at
this
point,
and
the
schedule
did
go
out
yesterday
for
cube
conf
open
Hagan.
So
that
is
an
announcement.
We
do
have
an
intro
and
deep
dive.
A
So
it's
important
that
we
tell
folks
of
what
we're
doing
and
why
we're
doing
it
and
then
I
am
committing
these
goals
today
to
get
home
so
they're
finally
going
to
be
out
of
this
spreadsheet
and
then
we'll
have
comments
and
things
like
that
via
github,
instead
of
the
spreadsheet,
and
things
like
that,
I'm
also
going
to
create
a
nice
to
have
do
in
github
as
well.
I
did
start
that
it
only
has
two
lines
and
the
in
the
spreadsheet
right
now
in
this
effort,
but
this
will
be
cool
for
us.
I.
Think.
A
As
we
bro
get
when
you
contributors
do
come
into
our
fold
and
they're
interested
in
helping
out,
this
is
a
good
way
to
point
them
to
things
that
we
would
love
to
do,
and
maybe
we
just
don't
have
the
support
in
some
way
to
do
that.
So
I
think
that's
it
for
one
point.
Ten
gold,
stuff
questions
concerns
comments.
A
A
B
Don't
have
this
in
the
community,
it's
it's
kind
of
nice,
it's
hard
to
formulate
a
road
map
and
understand
one
coming
in
what
the
priorities
are
other
than
a
future
tracking
sheet,
but
like
the
non
feature,
work
that
is
a
priority
in
the
SIG's
I
think
is
really
hidden.
You
have
to
kind
of
dig
in
and
like
talk
to
the
SIG's
individually,
so
maybe
that's
something
we
can
also
do
to
just
help.
Yeah.
A
B
A
I
think
I
think
the
docs
team
actually
does
it.
I
was
trying
to
yesterday
find
it
but
I
just
kept
getting
sidetracked,
but
they
actually
list
their
goals
and
like
in
a
project
the
way
where
they
have
owners,
and
things
like
that
that
are
linked
in
there
so
they're
doing
something
very
pleased
but
they're
doing
something.
Similar
I
also
wanted
to
talk
about
potential
goals
or
ideas
for
111
to
see.
A
If
anybody
on
the
line
either
had
something
in
the
future
that
they
think
that
they
really
want
to
take
on
or
if
they
see
things
when
our
goal
lists
that
are
maybe
listed,
it's
like
priority
three
or
on
the
nice-to-haves
list,
just
to
have
like
a
broad
conversation
about
that
today.
Obviously,
where
we
are
getting
a
little
ahead
of
our
Celso,
it
doesn't
need
to
be
done
today.
I
just
wanted
to
get
a
sense
from
everybody
on
the
call
what
they
thought
that
we
should
be
working
on
or
what
folks
will
be
working
on.
C
A
C
C
D
B
B
E
D
So
I
mean
to
be
honest
too,
since
some
like
a
lot
of
the
people
that
are
affected
by
these
process.
Changes
or
sort
of
had
had
frustrations
with
it
are
also
at
the
helm
somewhat
with
him
on.
This
may
be
a
good
conversation
to
come
back
to
in
the
next
meeting,
but
for
what
it's
worth
and
so
I
had
asked
Parris
and
Jason
I
believe
both
actually
jumped
in
to
the
Siq
testing
meeting
yesterday.
D
D
C
It's
easy
from
a
from
like
an
overreaching
goal
standpoint
to
say
having
a
consistent
experience
across
uber,
Nettie's
org
is
desirable
and
everybody
kind
of
agrees
with
that,
but
where
their
needs
across
the
kubernetes
repo
are
different,
we
have
repos
that
are
documentation.
We
have
repos
that
are
pure
code.
B
So
that's
like
part
of
the
second
or
the
the
first
problem
that
Steve
brought
up,
which
is
how
do
how
do
we
communicate
wide
enough
that
we
get
that
feedback?
Because,
right
now
it
sort
of
sounds
like
we
get
the
feedback
after
the
fact,
when
someone's
frustrated
that
a
change
we
rolled
out
came
about
as
a
surprise
and
disrupts
their
existing
workflow,
and
they
can
act
like
they
can't
adjust
to
it
or
don't
want
to
adjust
to
it.
D
A
I
think
this
is
what
we
were
trying
to
put
in
our
charter
yesterday
of
when
does
our
actual
communication
process.
Fuller
process
changes
so
that
we
can
at
least
show
people
the
channels
that
we're
using
so
that
they
know
the
official
ones
that
they're
gonna
get
updates
from
and
that
they
absolutely
have
to
monitor
these
channels
and
that's
their
responsibility
in
these
following
ways,
and
one
of
them
is
a
lazy
consensus
on
the
dead
list
for
sure
I.
A
Don't
necessarily
agree
with
like
72
hours
for
major
changes,
only
maybe
five
days
and
like
a
reminder,
especially
if
you
haven't
heard
anything
negative
and
then
there's
also
the
community,
an
announcement
section
where
we
starting
to
utilizing
changes
to
I
mean
we
have
hundreds
of
people
that
are
on
that
call.
So
that
distro
is
is
amazing
and
it
should
be
utilize.
A
But
then
also
I
really
think
that
now
we
know
that
helm
and
a
couple
others
like
docks-
and
maybe
a
couple
other
repos-
that
we're
all
thinking
about
have
use
cases
where
they
are
a
little
bit
outside
of
our
normal
and
I
say
normal
in
quotes.
But
maybe
we
should
go
to
those
people
naturally,
and
us
have
people
that
are
representatives
there.
You
know
to
kind
of
carry
out
the
contributor
experience
will
if
you
will
and
that's
again
another
reason
why
we're
gonna
do
these
road
shows
on
a
quarterly
basis.
A
You
know
on
a
fairly
regular
basis
and
I
mean
I
mean
whether
or
not
we
want
to.
You
know
talk
about
that.
But
anyway,
so
you
know
I,
don't
know
how
scalable
like
road
shows,
and
things
like
that
are
but
I
think
if
we
start
getting
people
and
they're
just
in
the
habit
of
including
us
in
in
there
any
feedbacks
that
they
have
I.
Think
things
will
get
a
lot
better,
but
in
a
case
for
home
I
mean
I
feel
like
there
are
workarounds
that
that
they
could
do
so.
A
I
feel
like
I,
do
hear
both
sides
to
the
story
or
not
necessarily
story
but
I
feel
like
I,
hear
both
cases.
So
that's
why
I'm
a
little
bit
on
the
fence
with
it.
Six,
if
I
do
hear
the
need
for
consistency
and
if
they,
if
they
do,
have
a
workaround
that
they
could
use
where
we
could
still
apply
the
change,
then
I
see
do
it,
but
at
the
same
time
I
am
sort
of
on
a
Kristoff
page
where
it's
like
it's.
A
B
B
The
problem
you're
trying
to
solve
alternatives,
considered
there's
like
a
clear
way
of
doing
that
so
I'm
wondering
if
we
can
adapt
that
either
use
that
exactly
or
contribution
changes
or
do
something
very
similar
and
I
think
that's
beneficial
in
a
couple
ways
like
it's,
it's
more
declarative,
which
is
like
a
very
big
theme
in
kubernetes.
So
like
the
process
like
the
proposals
there
and
there's
not
a
trail,
but
it
and
also
we
can
also
maybe
get
feedback
on
a
more
regular
cadence.
So
right
now
the
way
I
think
it
works.
B
Is
we
come
up
with
an
idea
and
contracture
testing
for
us?
We
propose.
If
we
talk
about
it,
we
send
out
that
email
for
lazy
consensus
and
then
we
just
roll
it
out
on
whatever
schedule.
Maybe
we
can
have
like
a
bi-weekly
or
monthly
like
this
is
where
new
processes
are
gonna
be
rolled
out,
and
so
we
can,
you
know,
give
updates
at
the
community
meeting
and
it's
more
on
a
regular
cadence
to
I.
Don't
know
it
was
just
an
idea.
What
do
people
think
I'm.
F
F
G
Am
I'm
just
gonna,
say,
I
think
some
sort
of
formal
ease
formalization
around
this
process
is
huge
because
I,
when
I
have
tried
to
introduce
process,
changes
and
I'm
one
of
those
people
that
somehow
it
does
a
lot
of
those
I've
run
into
multiple
buzz
saws.
In
terms
of
thinking
that
there
is
consensus,
knowing
that
the
Sagan
power
to
make
the
decision
was
had
already
made
the
decision
and
then
still
running
in
the
buzz
saw
so
I
think
that
there's
there's
a
few
things.
G
G
That
are,
we
need
to
be
able
to
untangle
the
the
decision
making
process
in
a
better
way.
Lazy
consensus
does
is
not
working,
it's
actually
causing
problems.
The
other
thing
is,
we
need
a
way
to
to
present
the
decision
making
process
or
the
the
decision
making
tools
to
people
in
a
way
that
is
effective,
I've
been
using
Google
Docs.
Other
people
use
issues,
some
people
are
using
keps
and
it's
all
over.
G
The
map
like
there's
no
way
to
actually
read
a
position
and
understand
how
you're
supposed
to
interact
to
it
or
relate
to
it
and
PRS,
get
in
issues
get
so
complicated
with
the
the
unreadable,
discussions
and
stuff.
So
whatever
this
process
for
processes
is,
we
need
to
this
needs
to
be
really
well
thought
out
and
implemented,
or
we're
actually
going
to
make
this
a
lot
lot
worse.
D
Think
one
thing
that
I
would
be
really
careful
about
is
having
that,
like
feedback
come
at
the
time
right
before
it
features
are
actually
rolled
out
so
I
guess
it
really
depends
on
the
stance.
That's
taken
about
like
how
consistent
do
these
things
actually
need
to
be
between
repos
and
like
what
I
wouldn't
want
to
see
as
a
developer
create
a
proposal.
You
know
get
some
feedback
on.
It
actually
implement
the
thing
you
know
putting
good
effort
and
then
send
out
the
email
to
get
ready
stead
of.
D
Oh,
you
know
we're
gonna
turn
on
this
feature
next
week.
Everyone
says:
no,
we
don't
want
that.
All
of
a
sudden
that
effort
has
been
kind
of
not
been
put
to
good
use,
so
I
think
potentially
having
liked
both
both
sides
of
the
equation,
so
feedback
from
a
lot
of
people
at
the
outset,
and
then
also
maybe,
if
we're
choosing
to
specifically
not
try
it
on
for
certain
repos
feedback.
Actually,
when
we
turn
it
on
well.
G
I
think
that's
part
of
this
decision-making
framework
that
I'm
advocating
for
is
it
one
of
the
core
pieces
in
a
position
statement
should
be
impact,
so
if
this
is
going
to
be,
if
I'm
proposing
hey,
let's
duplicate
the
features
repo,
what
is
the
impact
of
that?
What
does
that
actually
mean
in
terms
of
the
release
team?
What
does
it
mean
in
terms
of
sakes?
You
have
to
do
something
different
or
it's
more
overhead
of
paperwork
or
whatever,
and
with
repos
like
what?
What
is
the
impact
of
all
the
the
core
ecosystem
projects?
G
What
are
there
projects
that
have
known
different
workflows
that
we
need
to
reconcile
before
you
implement
that?
Just
that's
a
that's,
a
really
simple
thing,
but
there's
no
good
taxonomy
and
process
around
how
we
assess
impact
or
how
we
go
through
that
process.
So
there's
there's
a
layer
of
governance
around
decision-making
that
is,
is
I.
Think
it's
one
of
our
most
vulnerable
points
as
a
project
right
now
that
could
literally
sink
this
project.
We
don't
sort
it
out.
C
Another
idea
on
the
communication
channel
bevel,
it
seems
like
having
input
from
contributes
as
far
as
when
we're
making
changes
to
contributor
workflow,
like
this
being
the
forum
that
people
give
feedback
in
I
think
is
good
and
I
definitely
support
that
I.
Also
wonder
if
you
know
we
have
a
million
mailing
list,
but
maybe
setting
like
kubernetes
contributes
an
ounce
or
something
like
that.
C
If
people
don't
necessarily
want
to
subscribe
to
dev
for
whatever
reason,
because
if
they're
not
in
core
dev,
is
less
important
to
them
and
I,
don't
know
that
we
enforce
kubernetes
dev
on
like
helm,
for
example,
or
the
charts,
repo
or
people
outside
of
working
on
court.
If
there
was
like
hey,
here's
a
low
volume
communication
channel,
but
this
is
where
we're
gonna
communicate
to
you
to
let
you
know
when
there's
these
changes
to
contributor
workflow.
It
might
also
be
helpful
if
we're.
C
If
we're
looking
like
a
little
bit
wider
scope,
we
have
you
know,
there's
going
to
be
like
multiple
levels
of
repos.
There's
gonna
be
stuff,
that's
in
the
core,
kubernetes
org,
but
there's
also
going
to
be
stuff
that
are
like
associate
a
repose
and
and
there's
one
other
level
that
I
forget
off
the
top
of
my
head,
but
they'll
be
using
bots
to
different
degrees
and
different
workflows.
So
we
may
be
in
the
future,
impacting
more
than
just
even
the
kubernetes
org,
with
changes
to
bought
from
to
workflows,
I.
A
Mean
I
think
we
have
several
of
those
channels
already
that
you're
speaking
of
I
mean
and
that
are
less
less
noisy
than
kubernetes
dev,
but
I
think
you
know
a
meta
problem
is
now.
We
have
to
communicate
out
those
channels.
I
did
look
into
a
slack
solutions.
The
other
day
I
looked
and
to
see
if
we
could
do
an
announcement
only
channel
and
have
admins
post
so
that
there's
no
other
chatty
communication
going.
A
A
G
I
think
it's
it's
more
more
than
communication
I
mean
this
is
a
really
big
deal
and
it's
something
that
we
need
to
because
like,
for
example,
if
I
decide
as
a
release
leader
that
I
want
to
shorten
code,
freeze,
that's
a
that's
a
very
impactful
change
and
basically
I
should
be
able
to
get
feedback
on
that
and
decide.
If
that's
good
for
the
community
or
not-
and
you
know,
release
lead,
I
can
do
that
and
probably
people
will
accept
it.
But
that
is
that
the
right
thing
is
probably
not
I
mean.
G
There's
a
lot
of
changes
like
that.
The
process
changes.
You
know:
how
do
we,
how?
How
do
we
get
agreement
on
what
the
architectural
model
looks
like
or
there's
all
these
things
that
there
that
are
just
out
there?
Let's
change
that
needs
to
somehow
be
vetted,
because
when
it
gets
decided
in
an
in
a
vacuum,
and
some
of
these
are
very
small
vacuums
and
then
exposed
to
the
community,
the
community
rips
it
apart
and
and
rightly
so.
G
A
H
D
H
D
Suppose
I
tried
to
okay
so
that
I
guess
from
from
a
psych
testing
perspective.
There
are
these
two
very
explicit
questions,
one
of
them
being.
The
impact
of
this
release
are
sorry,
the
staler
closer
on
the
helm,
Rico
specifically
and
then
the
second
conversation
was
about
the
use
of
LG
TM
and
how
that
meshes
with
the
tech
and
dock
cell
JCM
used
in
the
documentation
repost.
D
How
does
a
is
it
appropriate
for
suggesting
to
say
we're
looking
for
direction
on
these
two
things
from
Sitka
Trebek's
and
then
be,
if
that's
appropriate,
like
how
do
we
expect
that
communication
to
happen?
Just
for
these
two
specific
things
before
sort
of
we've,
you
know
figured
out
this
brother
or
a
question.
D
B
I'm
so
I
wasn't
aware
of
the
discussion
from
the
helm
team
about
the
stale
and
rotten
the
status
of
issues,
so
I
need
to
read
into
that
a
little
bit
more.
Is
there
still
an
issue
with
the
LG
team
and
approved
because
the
last
when
I
was
following
that
thread,
it
sounds
like
doctors
having
trouble
with
it
and
then
Eric
and
some
people
from
cig
testing
spent
some
time
explaining
the
process
and
the
intention
and
they
updated
their
owners
file.
I
thought
I
saw
Steve
and
Andrew
comment
on
a
separate
issue
right.
B
D
Where
on
the
spectrum
like
so
right
now,
there's
like
the
the
core
kubernetes
algae
team,
approved
process,
implicit
approvals,
etc?
Then
there
is,
this
sort
of,
like
sort
of
you
know,
kind
of
different
defaults
for
the
process
in
that
repo,
where
you
know
they're
using
hold
and
a
combination
of
other
commands
to
make
it
look
like
the
old
docks
and
Technology
TM
and
I
guess
that's
sort
of
the
middle
of
that
spectrum,
then
the
Florin
to
that
spectrum
would
be
like.
D
Do
we
actually
write
code
to
specifically
look
for
doc
and
tech,
algae
teams
I
think
we'd
want?
Are
we
happy
with
like
where
there
are
right
now?
Were
they
using
a
difference
than
the
defaults
for
that
workflow,
but
sort
of
still
using
the
commands
that
everyone
else
has?
Does
that
seem
reasonable
for
new
contributors
that
are
maybe
are
more
comfortable
with
other
repos
that
come
into
this,
and
all
of
a
sudden
like
slash
cold,
has
a
pretty
different
semantics,
meaning
like
in
the
specific
context.
B
I
think
they
need
to
document
that
in
their
repo
I
think
everything
like
in
an
ideal
world
I.
Imagine
the
solution
or
the
the
it
looks
like
everything
is
defined
centrally
in
testing
for
this.
These
are
the
processes
across
for
kubernetes
repos
and
if
there
are
customizations
we've
written
them
down
in
our
repo
in
the
region
for
contributing
right.
So
if
they
want
additional
automation
for
technology,
TM
and
Docs
LG
TM,
and
they
want
the
approvers
mechanism
to
work
differently,
I
think
yet
they
can
write
it
and
it's
fine.
F
I
mean
when
I,
when
I
put
together
the
contributor
guide.
I
said
that
each
you
know
that
individual
sticks
or
projects
may
have
their
own
contributing
dogs,
and
we
should
absolutely
try
and
make
them
align
and
make
sense
with
each
other
and
have
this
logical
flow
of
hierarchy
where
you
get
familiar
with
the
core
concepts
first
and
then
look
at
the
special
requirements,
but
it
is
totally
fair,
I
think
to
have
certain
special
requirements.
F
A
And
you
know
what
I
just
realized
Quinn,
you
might
know
this
answers
in
ours,
I'm
gonna,
look
in
our
new
one
right
now
they
created.
Do
we
indicate
to
other
people
that
they
should
be
looking
in
the
contributing
MD
file
of
other
repos,
cuz
I.
Think
I,
don't
think
I've
seen
that
language
specifically.
A
D
A
So
confused
by
that
in
general,
I
think
I'm
gonna
go
on
the
record
and
say
that,
but
at
the
same
time
I
don't
think
any
of
us
are
here
to
tell
people
how
to
live
their
software
engineering
life
but
I
feel
like
there
is
a
process
that
we
could
help
them
out
with
on
maybe
pree
labeling
or
like
pre.
Commenting
that
like
this
is
gonna,
get
worked
on.
I,
don't
know
right.
D
D
D
I
think
I
think
I
totally
agree
with
that
is.
The
sort
of
symptomatic
is
something
else
happening
and
I
think
that
they're
using
those
issues
in
a
way
that
probably
the
rest
of
them
Oregon,
maybe
isn't
I,
was
hoping
I
mean
they're
there
summit
is
today,
so
they
can't
come
in
and
comment.
We
do
have
a
mechanism
and
test
interest
to
implement,
like
customer
bots
that
maybe
just
work
for
your
repo
and
so
potentially
yeah.
There
could
be
a
process
for
like.
Oh,
we
automatically
add
that
label
and
hey
you
know,
don't
touch
it
well.
D
A
G
That
said,
I
think
that
we
should
leave
the
the
bought,
as
is
for
the
time
being
and
have
the
case,
be.
Please
explain
to
us
why
we
shouldn't
do
this
as
opposed
to:
let's
not
do
it
and
then
you
know
could
I.
This
is
one
of
those
things
that
we
we
have
a
an
expectation
of
some
sort
of
response
time
around
issues
like
that,
and
so
you
can
always
reopen
them.
I
mean
anybody
can
reopen
an
issue,
and
so
I
think
that
that's
I
think
that
that
should
be
the
default
time.
Yeah.
D
A
The
cream
and
what
I
just
want
to
go
on
record
I'm,
not
judging
whatsoever
home
I'm
I'm,
just
saying
mean
a
general
statement
that
maybe
the
bond
is
actually
helping
us
here
with
with
helping
them
on.
How
can
they,
you
know,
do
better
in
certain
areas.
This
goes
for
any
repo
that
you
know.
The
BOC
could
pick
this
up
with
so
100%
judgment,
free
zone.
F
All
right
when
the
parts
where
it
talks
about
specific
contributing
MDS
and
it
doesn't
actually
talk
any
say
anything
about
individual
repositories,
so
I,
like
Ben's
suggestion,
a
lot
of
the
repositories
already
have
contributing
MDS
that
do
point
back
to
the
contributor
guide.
I
actually
went
through
them.
I
I!
Don't
have
my
notes
for
that
with
me
right
now,
but
I
actually
went
through
them
about
a
month
ago
to
see
what
was
going
on
there
and
some
don't
need
a
contributing
MD
or
they
have
a
contributing
MD.
F
A
A
C
F
I
B
D
I
I
But
we
don't
have
a
process,
a
good
process
for
rolling
out
right
now,
so
it
seems
like
it
might
be
fair
to
to
to
step
back
on
that.
Okay.
G
And
I'm
fine
with
that
I
just
roll
it
out,
I
I,
don't
have
any
problem
with
that.
It's
just
we.
We
just
need
to
be
mindful
of
the
fact
that
we
are
now
introducing
a
state
where,
if
it
goes
back
on,
that's
that's
a
totally
different
discussion
that
needs
to
have
some
parameters
around
it,
so
we
can
actually
make
it
or
the
people
involved
who
are
stakeholders
can
make
the
decision
around
it.
That's
all
I
would.
C
C
A
Right
so
next
on
the
agenda,
I
think
we
were
pretty
much
done
with
the
exception
of
documenting
labels,
which
Aaron
also
super
came
through
for
us.
Yesterday
we
were
about
to
start
documenting
the
labels
we
just
like
took
a
page
and
by
document
I
just
mean
to
find
so
that
we
can
have
a
good
place
for
both
new
contributors
and
current
contributors
to
get
like
genuine
definitions
of
some
of
them
and
he
pulled
through
for
us
and
did
it
he
still
needs
some
help.
A
A
A
A
The
only
thing
right
now
that
we're
waiting
for
at
this
point
is
for
Linux
Foundation
to
weigh
in
because
there
have
been
discussions
on
there
and
for
redoing
some
of
their
project
websites
and
that's
pretty
much
as
much
information
as
I
have
right.
Now,
on
that,
they're
supposed
to
be
weighing
in
hopefully
today
on
the
issue,
George
actually
wrangled
them
into
commenting
on
github,
just
because
we
have
some
of
that
stuff
via
email.
So
you
want
to
make
it
as
public
as
possible.
A
All
right,
I
definitely
could
use
suggestions
as
we
get
into
you
know
whatever
our
first
dig
is
here,
whether
its
requirements
gathering
or
working
with
Linux
Foundation
and
on
what
they
think
is
best
etc.
So,
with
all
all
suggestions
for
anybody,
that's
on
the
call
or
will
listen
to
the
call
leader.