►
From YouTube: Kubernetes SIG Contributor Experience 20170920
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
D
I
will
see
Dan
Khan
from
CN
CF.
Here
Caleb
asked
us
to
Lucas
myself
to
come
on
and
show
a
quick
preview
of
the
dashboard
that
we've
been
Fiat.
We've
been
building
for
the
steering
group
room
for
the
whole
community
and
I
apologize
for
pressing,
but
I
have
a
hard
stop
at
half
an
hour
as
well,
and
I
was
wondering.
Maybe
we
could
go
second
or
third
yeah.
D
A
E
D
D
D
It
is
not
showing
so
Brian
grant
and
other
members
of
the
leadership
team
made
a
request.
Almost
a
year
ago
now,
I
believe
to
trying
to
have
better
insight
into
what's
going
on.
What's
working
and
not
in
the
project
and
there's
been
a
couple
different
efforts
at
it
and
now
CNCs
has
thrown
its
hat
in
the
ring.
So
there's
this
URL
cm
C
F,
test,
dot,
IO
and
the
data
is
live,
and
so
I
definitely
encourage
you
to
spend
some
time
in.
D
But
it's
an
example
if
I
go
into
PRS
merged
and
folks
can
see
that
where
I
don't
see
yes,
okay,
thanks
and
so
what's
been.
Pretty
amazing
about
Gravano
is
that
if
I
then
want
to
zoom
in
specifically
and
see
what's
happened
in
the
last
few
months?
I
can
drag
across
that
and
it's
extremely
responsive
about
zooming
in
and
responding
to
that
data,
and
then
the
other
piece
that
I
just
want
to
point
out
is
up
here
at
the
top
left,
where
I
have
week.
D
D
But
the
process
is
kind
of
interesting
that,
in
order
to
get
the
data,
it's
not
sufficient
to
just
go
to
get
the
github
API
and
ask
it
for
the
latest
results,
because
we
actually
want
to
see
changes
over
time,
and
so
instead
we're
using
this
free
data
set.
They
make
available
called
github
archives
and
we
actually
download
every
single
action
public
action
that
anyone
has
done
on
github
in
the
last
three
years.
D
D
That's
doing
live
calls
on
the
influx
DB
in
order
to
display
this
data,
and
so
it's
a
seemingly
inefficient,
and
yet
it
actually
only
takes
a
couple
hours
to
throw
out
all
that
useless
data
and
then
we're
we
running
at
every
hour
on
the
latest
of
this
and
updating
all
of
our
values
as
a
result
of
this.
So
this
is
a
very
actively
Lukas
who's.
D
A
contract
developer
for
CMC
F
is
working
on
this
full-time
right
now
and
all
of
his
work
is
publicly
available
and
I'll
just
put
that
URL
here
as
well,
and
we
would
love
to
get
suggestions
and
comments.
Improvements,
there's
a
doc
that
Brian
grant
put
together,
which
are
safe.
Essentially
his
wish
list
of
everything
that
he
would
like
to
have
done
and
all
the
visibility
that
he
wants,
but
I
think
as
you
imagine,
as
he
sees
individual
graphs,
he
says.
Oh,
that's,
not
quite
right.
D
I
need
the
fifteenth
and
85th
percentile
I
need
this
data
or
that,
and
so
it's
naturally
just
going
to
be
an
iterative
process.
But
part
of
the
idea
here
and
I
should
also
mention.
This
is
actually
based
on
the
velodrome
work
that
originally
came
out
of
Google.
But
part
of
the
idea
here
is
that,
because
everything's
open
source,
any
of
you
can
fork
the
repo
download
the
parse
data.
So
you
don't
have
to
do
all
that
heavy
parsing
we've
done
and
then
make
improvements
or
suggestions
and
return
them
as
pull
requests.
D
D
B
B
D
G
D
Right
but
the
thing
that
I
want
to
emphasize
is
we
actually
believe
that
we
have
better
data
on
company
affiliation
than
has
ever
been
created
before,
where
we
went
through
and
analyzed
over,
a
thousand
unknown
email
addresses
and
matched
them
to
LinkedIn
or
github
or
other
kinds
of
sources
and
bolete
now
I'm
sure
there's
some
errors
in
there.
But
it
was
a
very
legitimate
attempt
to
try
and
be
comprehensive
and
it
also
includes
states
associated
with
it.
So
the
analysis
does
try
and
actually
track
job
changes
over
time.
D
We
think
it's
biased
in
the
wrong
way
of
focused
just
on
commits
and
not
enough
on
all
the
other
actions
that
really
matter
like
reviews,
issues
and
documentation.
Other
sorts
of
things-
and
so
we
said,
okay,
we'll
put
that
get
DM
work
on
hold,
go
focus
on
the
dashboard
and
now
we're
pulling
it
into
the
dashboard
piece,
but
trying
to
make
it
part
of
a
holistic
view
on
the
project.
I.
A
D
You,
and
it
really
is
a
work
in
progress,
so
I
mean
my
main
call
for
this
group
and
for
your
colleagues
is
that
in
the
next
month
or
so,
if
you
can
go
in
and
the
more
specific
you
can
be
about,
oh,
you
need
a
graph
that
does
X
or
oh,
this
graph
isn't
as
useful
as
it
could
be,
because
the
state
is
wrong.
We
really
do
and
try
be
very
responsive.
G
And
would
be
great
if
anybody
wants
some
specific
graph
also
include
some
directions.
How
exactly
can
I
extract
this
data
from,
for
example,
some
kind
of
labels,
or
maybe
texts,
or
what
comments
or
something
like
this?
If
I
have
cleared
the
clear
directions,
how
to
get
this
I
can
deliver
graph
very,
very
fast.
That's
all.
H
A
Okay,
so
now
to
the
second
item
of
business
for
today,
which
is
doing
reviewing
the
1.8
plan,
so
I
feel
like
we
have
already
started
talking
about
this
identify
metrics,
trending,
contributor
experience
and
project
velocity,
and
so
we've
just
saw
some
some
progress
on
that.
I
think
that
that
actually
also
helps
with
B
as
well
empower
the
community
to
find
custom,
metrics
and
visualizations.
B
A
Right
I'm
gonna
quickly
pop
this
over.
A
I
A
A
B
A
I
Yeah,
so
you
know
we
discussed
earlier
that
the
clear
guideline
we
created
for
Cuban
industry
people
and
that
should
be
applied
to
all
other
reports
in
a
community
and
related
reports
right,
but
I
think
we
did
not
have
a
consistent
label
across
all
the
Reapers.
So
I
think
this
is
no
big
dependency
were
there,
but
once
we
have
labels,
consistency,
I
think
we
can
modify
the
guideline
little
bit.
I'll
work
on
it,
sort
of
we
can
have
it
for
all
the
repos
okay.
A
B
A
J
B
A
I
D
A
Okay
for
promote
project
health
and
stability
to
find
a
community-based
user
support
rotation,
George
I
did
not
see
him
on
yeah,
okay
and
then
socialized
commands
for
labeling
instead
of
manually,
applying
labels
merging
Garrett.
Is
it
on
I'll
check
back
with
him
on
that
measure,
Stock
Exchange
health
and
office
hours,
okay,
so
I'll
check
in
with
George
about
this
later
offline
support
the
release
team
Jake,
oh
and
Jase,.
C
A
J
There
are
several
places
that
are
currently
hosting
contributor
guide,
slash
developer
guides,
so
the
intention
here
was
to
combined
most
of
those
and
have
one
place
where
we
can
point
people
to
to
all
mourn.
For
instance,
the
ticket
that
is
in
the
dock
is
the
start.
Paul
Mori
did
but
you'll
see
from
the
ticket
that
there's
multiple
conversations
going
on.
J
So
the
real
issue
that
we
need
to
solve
for
right
now
is
defining.
What's
the
differences
between
a
developer
verse
as
a
contributor,
because
both
need
guides
I
think
this.
This
saying
should
of
the
contributor
guide
experience
the
developer
guide,
TDA
for
kind
of
who
owns
what,
and
it
would
be
great
to
hear
from
you
all
on
what
kind
of
like
save,
slash
or
working
group
should
be
around
a
developer
guide,
but
I
actually
have
an
tro
on
the
call
as
well
from
docs
and
the
reason.
J
Why
is
because
this
fits
nicely
with
user
journeys
at
the
six
docks
team
is
going
to
do,
and
ender
can
kind
of
talk
about
that
in
a
second
from
a
high
level,
but
we
essentially
need
personas
from
that
in
one
of
the
personas.
So,
actually
to
the
personas,
ultimately
be
developer
versus
contributor
and
then
get
various
checklists
and
stats
based
off
of
that.
J
So
right
now
we're
just
unpacking
all
these
terms
coming
up
with
the
resources
that
we
already
have
again
because
they're
in
multiple
spots,
whether
it's
in
the
the
devil
section,
whether
it's
in
the
community
section.
What
have
you
wherever
it
is,
so
that's
the
project
that
we're
embarking
on
right
now
we
are
talking
to
some
of
the
key
players
within
that
issue
or
within
that
issue
is
about
to
call
it
a
ticket
within
that
issue,
and
I
would
love
to
if
anybody
wants
to
participate
and
or
help
or
has
content
already.
J
J
He
added
a
couple
bullet
points
very
specific
towards
like
API
naming
conventions,
and
things
like
that.
So
we'll
beef
up
the
guy
based
off
of
the
suggestions
that
are
in
that
issue
Andrew
did
you
want
to
give
a
kind
of
like
a
whole
about
user
personas
in
case
anybody
in
this
group
doesn't
know
what
what's
going
on.
K
Yeah
sure
the
TLDR
is
that
we
want
to
sort
of
customize
people's
experiences
depending
on
like
kind
of
what
the
role
is
or
what
their
specific
needs
are.
So,
for
example,
like
an
app
developer,
doesn't
need
to
know
necessarily
like
cluster
operation
stuff.
So
we
want
to
have
you
know
specific
journeys
for
them,
so
they
can
focus
on
what
they
need
to
know
for
that
and
then
so
to
the
ones
that
we're
talking
about
here.
K
They
for
some
reason
we
are
getting
conflated,
but
one
is
like
the
code
contributors
right
who
are
contributing
to
the
open-source
code
base
and
then
the
other
one
is
seems
to
be
customizing
kubernetes,
so
they
may
be
like
extending
the
API
or
adding
to
it.
But
it's
not
contributed
back
to
the
community,
but
it's
for
their
specific
project
because
they
need
to
kind
of
like
beef
up
the
architecture
or
something
for
their
specific
needs.
B
B
H
J
Then
what
about
this
developer
guide
piece
I
mean
there
I
think
someone
on
the
call
actually
could
comment
it
on
the
issue.
I'm,
sorry,
I!
Don't
I,
don't
have
my
browser
up
right
now,
but
they
mention
that
contributor
is
kind
of
a
top-level
term.
I
do
agree
with
that,
but
at
the
same
time
a
developer.
That's
building
on
top
of
an
API,
that's
not
contributing
to
the
community
is
not
a
contributor.
In
my
eyes
they
are
a
developer
Nettie's
developer.
J
Essentially,
so
you
know
again
unpacking
these
terms
seems
to
be
in
getting
some
consistency
across
the
board
seems
to
be
a
key
thing,
a
part
of
this
project,
as
well
as
many
other
projects
that
I'm
seeing
so
I
think
the
user
journey
piece
where
we're
defining
these
personas
is
going
to
water
down
into
many
other.
Excuse
me,
many
other
projects
would
love
to
hear
like
opinions,
and
you
know
if
you,
if
anybody
on
the
call
wants
to
be
added
into
some
of
these
initial
meetings
to
to
hash
this
out.
J
J
J
B
But
I
just
want
to
have
one
last
thing:
hot,
so
I
view
developer
and
contributor
a
sort
of
a
Venn
diagram,
there's
an
intersection
there.
There
is
a
subset
of
contributors
and
I
care
more
about
that,
personally,
probably
from
like
a
state
testing
perspective
right
that
when
it
comes
to
how
do
I
code
around
the
shape
of
kubernetes
and
think
about
the
kubernetes
way,
89.
B
Lot
of
guidance
to
give
and
architecture
probably
has
a
lot
of
guidance
to
give
around
so
API
machinery
around
like
conventions
and
the
kubernetes
shape
and
way
of
thinking
and
architecture
around
the
appropriate
boundaries
sort
of
defined
to
place
things,
and
with
that
I
have
to
go
to
burn
down
thanks.
Thank.
K
I
feel
like
part
of
the
issue,
is
the
terminology,
because
developer
is
a
very
overloaded
term,
like
we
have
basically
kind
of
three
flavors
right:
there's
like
application,
developer,
who's
using
kubernetes
right
and
then
there's
like
a
developer
who's,
contributing
to
the
codebase
and
there's
a
developer,
that's
kind
of
like
extending
the
platform
right.
So
all
of
those
are
developers
but
then
mean
something
different.
When
you
talk
to
different
people,
like
you,
know,
see
developer
and
they're
kind
of
thinking
in
their
context,
so
I
hope
I.
What
am
I
I
wish.
K
We
could
also
have
kind
of
converge
on
some
commonly
used
terminology.
That
is
clear.
So
when
we're
saying
like
this,
you
know
like
code
contributor,
we
know
that
that's
the
kind
of
developer,
because
if
we
just
say
I'm
a
developer,
then
people
are
gonna
be
like
well
with
which
one
are
you
talking
about,
or
they
just
assume
it's
the
one
that
they're
used
to
dealing
with.
L
I
Yeah
so
yeah
to
me,
I'll
just
you
know
on
one
of
your
comment
earlier
to
me.
It
seems,
like
you
know,
contributors
like
I
said
right,
it's
more
top
lower
term,
because
anybody
right
regardless
they're,
going
to
tell
provide
any
code
contribution
like
end,
which
is
saying
right.
They
need
to
know
certain
things
right
as
they
got
on
board.
You
know
like
knowing
this.
I
You
know
different
things,
for
example
right
you
know
or
how
the
project
is
structured
right
and
just
just
for
them
to
provide
in
any
contributions
right,
any
any
feedbacks
and
user
experience
or
whatnot
by
and
then
you
know,
developers
and
one
thing
I
had
on
like
three
different
categories
and
you
mention
right.
We
also
consider
dark
as
a
call
code
right.
You
know,
I
mean
for
many
people.
J
And
this
is
in
no
way
taking
away
from
other
personas
by
the
way,
there's
multiple
other
personas
mean
Andrew
and
I
lists
it
out.
I
think
it
was
like
set
at
least
seven
personas
LA
yesterday,
and
so
just
before
this
project,
based
on
a
contributor,
slash,
developer
guy,
that's
the
personas
that
were
that
we're
focusing
on
for
this
piece,
but
as
Andrew
builds
out
the
user
journeys,
then
I
want
to
talk
for
Andrew,
but
as
he
builds
up
user
journeys,
we're
going
to
have
things
like
a
Docs
contributor.
J
You
know
doc
slash
community
contributor,
because
that
is
different
than
say.
You
know
this
is
how
you
go
through
a
code
review
process,
for
example.
So
you
know
each
one
of
those
personas
is
going
to
have
different
checklists
and
some
some
sharing
some.
You
know
sharing
content,
some
not
so
definite.
A
M
M
But
again,
local
cube
bootstrapped
was
not
working
well
for
me
and
this
new
one,
you
know
I
asked
for
I've
been
asking
for
that
for
a
while
and
it's
gone
in
and
it's
it's
wonderful,
so
I
you
know
suggest
giving
it
a
shot
if
you
actually
not
actually,
but
if
you
do
any
kind
of
development
mini
cube.
Oh
it's
just
trying
giving
it
a
giving
it
a
shot
and
saying
it'll
be
different
because
it
has
our
back
and
it
has
a
bunch
of
the
plugins
and
stuff
enabled
by
default.