►
From YouTube: Kubernetes SIG Contributor Experience 20171101
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).
C
Okay,
I'm
gonna
try
to
go
real,
quick,
so
first
I
contribute
a
cheat
sheet
to
so
I
did
a
poll
on
a
cheat
sheet
of
URLs
and
stuff
for
the
project
that
that
feels
like
I
use
all
the
time,
but
always
forget
so
I
started
to
do
that.
Any
feedback
on
that
will
be
great.
It's
currently,
my
personal
namespace
I
was
thinking.
It
would
be
great
to
put
it
someplace,
which
leads
to
my
second
topic,
which
is
a
contributor
guide.
I
posted
the
link
in
slack
as
well.
C
Will
be
a
good
start
for
a
contributor
guide
and
we
can
put
things
like
the
contributor
cheat
sheet
in
there.
The
developer
guide
that
people
are
working
on,
put
it
in
there
and
kind
of
just
do
just
like
redo
the
whole
thing
to
be
awesome,
because
a
lot
of
it
is
like
organic
and
we
committee
final.
So
the
good
news
is
well
the
first
bad
news
is
when
I'm,
when
we
imported
everything
was
65
pages
of
documentation
and
then
the
first
bit
of
good
news
is
just
by
restructuring
it
and
reorganized.
C
We
cut
it
down
ten
pages,
so
it
was
about
55
pages.
The
bad
news
is
are
still
missing
a
lot
of
things
that
need
to
be
written.
So
what
I've
done
here?
If
you
like,
we
don't
have
to
run
through
it
through
the
meeting
or
wherever.
But
if
you
hit
the
sidebar,
so
you
can
see
the
outline
on
the
side.
Please
don't
judge
the
content,
because
it's
basically
copy
and
paste
of
what
to
github
and
a
lot
of
it
repeats
unnecessarily.
Things
like
that.
George.
C
C
And
your
first
contribution
so
there's
like
a
skeleton
there
on
the
side,
so
I
just
kind
of
picked.
These
I
didn't
really
like
it.
I
looked
at
different
contributor,
guys
from
different
organizations
and
I
kind
of
just
picked
them
with
an
idea
of
just
saying
hey.
If
everyone
can
kind
of
agree
with
the
outline
is
you
can
see
like
where
we're
missing
stuff
at
what
parts
need
to
be
rewritten
and
things
like
that,
so
I'm
really
looking
for
a
lot
of
feedback
on
this
I
was
very,
very
aggressive.
C
With
the
cutting
some
of
the
stuff.
We
have
a
lot
of
the
documentation.
That's
sitting
and
github
like
repeats
itself
unnecessarily
because
spread
all
over
the
place,
so
I'm
kind
of
going
from
an
angle
of
aim
should
list
things
once
and
then
link
to
them
as
opposed
to
a
bunch
of
little
files.
So
if
anyone
has
any
questions,
it's
going
to
be
like
a
long-term
project
that
I'm
just
going
to
be
working
on
any
help
here.
If
you
want
to,
if
you
feel
strongly
about
a
section,
I
was
talking
about
a
about.
C
E
I
did
start
an
issue
on
the
website,
repo
answer
Chen's.
Actually,
the
docs
person
that
I've
been
working
with
on
this
on
the
side,
I'll
update
the
I'll
update
the
agenda
with
the
issue,
but
he's
well
aware
that
this
is
coming.
This
is
actually
a
hot
kind
of
ties,
hand
in
hand
with
their
personas
slash
user
journeys
project,
because
ultimately,
this
will
be
feeding
into
what's
gonna
be
known
as
the
code
contributor.
E
F
I
also
just
one
note
from
me,
so
we
had
absolutely
independent
initiative
since
the
beginning
at
CN
CF.
So
my
plan
was
to
create
the
spreadsheet
for
the
beginners,
how
artists
have
contributing
for
communities
and
so
on
that
we
can
lately
expend
for
also
CN
CF
projects,
and
it
has
happened
that
this
initiative
came
life
exactly
in
the
same
time
when
Georgie
Paris,
FJ
initiative,
forget
in
cabinet,
is
sheet
sheet
and
contributor
guide,
so
we've
been
speaking
with
juror
bounded
and
would
like
to
align
all
these
initiatives
together.
F
C
G
E
By
computers
that
hit
kubernetes
dot
IO,
though,
and
the
third,
the
survey
that
I
just
did
and
I
can
show
everybody
the
TLDR
in
one
second,
when
I'm
up
by
the
survey
that
I
said
at
least
20%
of
surveyed,
which
was
20
people,
because
we
had
about
110
survey.
Respondents
all
said
that
github
was
not
an
appropriate
place
to
house
contributor
Docs
when
all
the
rest
of
the
docs
are
on
kubernetes
at
I/o
I.
B
That
I/o
is
sort
of
code
for
a
website
that
most
people
think
of
when
they
go
to
kubernetes
for
the
first
time
and
also
a
place
that
has
tech,
writers
and
dock
maintainer
x'
and
the
slightly
more
active
group
of
people
maintaining
it
so
I
don't
have
a
strong
preference
on
which
place
I
have
a
strong
preference
that
we
actually
prune
away.
All
the
needless
stuff,
going
from
65
pages
of
content
to
10
sounds
very
good,
great
and
typically
I.
B
E
This
is
not
to
necessarily
replace
the
contributing
dot.
You
know
markdown
file
that
would
be
in
the
repo
I
mean
the
repo
would
ultimately
link
to
these
Docs.
So
it's
not
like
we're
cleaning
house
completely
of
all
contributing
Docs
within
the
you
know
within
the
said,
repo,
it's
just
displaying
it
in
a
more
forward-facing
manner
to
feed
you
know
all
of
the
public
and
not
just
people
who
loved
further.
You
know
they're
kind
of
first,
you
know
they're.
First,
you
know
action
if
you
will
as
a
contributor,
so
yeah.
C
D
B
E
D
E
Mean
they
they
would
ultimately
be
housed
within
this
document
as
well,
I
mean
the
only
reason
why
we
I
think
that
everything
should
have
their
own
contributing
guide
and
I
mean
it
in
a
very
short
summarised
way
is
because
I
know
each
cig
does
have
minor
differences
as
far
as
their
contribution
process
and
kind
of
like
all
they
operate.
So
it's
important
that,
if
there's
differences,
then
they
should
have
a
contributing
guide.
I
mean
I'm,
looking
look
to
like
six
CLI,
for
instance,
or
storage
or
multi
cluster.
E
B
D
E
This
would
ultimately
be
a
kubernetes
kubernetes
general
project
umbrella,
what
you're
seeing
on
kubernetes
IO
and
then,
ultimately,
there
would
be
verbage
in
there.
That
would
tell
them
where
to
dig
and
where
to
look
and
where
the
resource,
where
their
resources
would
be
to
go
to
those
different
channels.
I,
don't
that's
kind
of
where
my
thought
process
was.
G
You
made
the
point
about
other
sub
projects,
doing
their
own
thing.
I
think
that
was
you
yes,
yeah
cops,
for
instance,
does
not
have
a
formal
design
process
like
Korean
a
screw.
Bernays
has
so
that's
a
perfect
example
where,
if
I
was
a
developer
and
I
was
following
the
kubernetes
kubernetes
guide,
I
would
go
into
community
put
in
a
design
proposal
to
get
into
cops.
That's
not
how
it
works.
So.
D
C
So
I'd
have
to
cigar
just
specifically
about
this
and
they
basically
told
me
they're
kind
of
in
the
process
of
thinking
about
incue
bation
and
the
processes
for
things
like
cops
that
aren't
like
cork
or
so
I
imported
all
the
incubation
stuff
and
then
I
just
kind
of
left.
It
there
kind
of
pending
outcome.
B
B
That's
probably
gonna
have
to
follow
the
Corcoran
Eddy's
way
so
the
whole
like
Hoover,
Nettie's
extension
proposal
thing
will
probably
apply
to
anything
that's
considered
before
kubernetes
and,
however,
we
define
things
that
are
not
core
kubernetes
that
are
in
the
broader
ecosystem
are
probably
free
to
make
whatever
kind
of
sausage.
However,
they
feel
great
to
make
sausage
right
much
like
a
CNC.
B
F
doesn't
particularly
dictate
how
its
individuals,
its
individual
projects,
run,
though
it
does
mandate
certain
requirements
for
a
project
to
graduate
from
incubation
status,
to
full-fledged
projects,
which
kubernetes
is
the
first
one
that
I
think
is
I'm,
not
sure
we
actually
graduated
yet,
but
we're
getting
ever
closer
anyway.
I
want
to
him
back
to
our
moderator,
because
I
think
we're
running
long
on
this
one
topic:
yeah.
D
Spike
interrupt
you
real,
quick
I
just
want
to
make
a
decision
on
that
George
I
think
a
lot
of
people
have
mentioned
that
they
love
the
idea
for
the
contributor
cheat
sheet
and
you
kind
of
glossed
over
it.
Real
quick
I
agree
that
it
needs
to
live
somewhere.
We
all
have
a
ton
of
links
that
we
visit
regularly.
C
D
E
E
And
all
right,
so
this
is
a
deck
that
I've
put
together.
That
will
ultimately
talk
about
mentor
strategy.
I,
don't
want
to
send
this
out
just
yet
I
need
to
finish
my
sites.
I
have
a
reference
dock
in
the
back,
so
I
just
want
to
make
sure
that
it's
fully
sighted
before
I,
send
it
out
so
chris
loves
also
on
the
call
too
he's
been
helping
me
with
the
mentor
guidelines
we'll
get
to
that
in
a
second,
but
also
Chris
suggested
that
we
name
that
these
mentors
pilots
so
I
think
that's
a
great
idea.
E
I
don't
know
if
anybody
else
has
any
decisions
on
that,
but
we
can
talk
about
that
after
that's
the
warm
and
fluffy
so
really
briefly,
I
did
get.
We
did
get
inspirations
from
many
programs.
This
is
not
a
template.
The
many
program
logos
are
right.
There
I'm
also
going
to
breeze
through
these
slides
by
the
way,
because
it's
20
of
them
and
I
only
have
a
couple
minutes.
E
Not
too
many
open
source
projects
do
group
mentoring,
but
with
the
in
the
inspiration,
slide
a
couple
of
other
projects
and
other
like
bootcamp
types
like
the
ADA
initiative,
and
things
like
that
have
to
great
success
and
I've
done
a
lot
of
research
on
group,
mentoring
and
the
power
of
fruit
mentoring
and
some
of
that's
in
the
in
the
resource
list
on
the
back,
but
cohort
tracks,
event-based,
contributor
activities,
contributor
office
hours
and
potential
classes,
and
as
long
as
also
outreach
e.
So
what
is
group
mentoring?
E
This
is
ultimately
going
to
be
a
class
of
individuals
who
all
have
the
same
goal
in
mind,
goal
being
to
get
to
that
next
level.
Whatever
that
next
level
is,
and
also
include,
multiple
pilots
and
again
pilot
being
mentor
here,
not
necessarily
like
beta
tests
or
anything
like
that,
and
they
would
essentially
be
learning
together
with
individual
goals
in
mind.
Benefits
of
group
mentoring
is
that
we
all
have
clear
goals
again
that
they're
all
working
towards
the
same
thing.
E
Why
not
one-on-one
I
hear
that
often
one
because
one
over
one
doesn't
necessarily
scale
and
if
we're
looking
to
scale
of
rapidly,
for
whatever
reason
for
whatever
goal,
then
group
mentoring.
If
we
have
10
mentors
in
a
class
and
only
3
issues
made
10
mentees
and
then
the
only
three
mentors
/
pilots,
you
can
see
the
scale
right
there
time.
You
know
we
always
from
both
mentees
and
mentors
that
time,
for
that
kind
of
relationship
is
strained.
The
survey
that
I
ran
and
again
I'll
put
the
TLDR
executive
summary
in
the
release.
E
E
And
of
course
it's
been,
you
know,
news
within
the
last
few
years
about
one-on-one
mentoring
is
that
forced
mentoring
relationships
can
often
be
toxic.
The
QZ
is
just
in
reference
to
a
reference
that
I
have
on
the
back.
So
how
would
one
be
a
pilot
in
this
situation
or
what
is
a
pilot
in
this
situation?
It's
obviously
somebody
that's
displaying
the
principles
of
the
project,
they
believe
in
the
growth
of
the
contributors.
E
There's
the
expectations
again.
I'll
put
this
deck
out
in
in
a
few
hours,
but
the
pilot
expectations
are
there
and
Cris
has
put
in
a
lot
of
work
to
that.
So
definitely
thank
Chris
on
that
piece
and
then
so
how
would
one
be
a
and
what
is
a
mentee
in
this
situation?
Oops,
obviously
they're
interested
in
more
structured
learning,
not
necessarily
somebody
that
wants
to
just
read
my
the
contributor
markdown
files
in
the
community
folder
desired.
E
A
shortened
learning
curve
want
to
meet
others
with
similar
goals,
strong
interest
in
growing
kubernetes
and
your
role
in
it.
Ideally,
these
people
would
be
filling
on
a
contributor
info
form.
This
is
where
the
cool
kind
of
comes
into
play,
because
we
don't
have
one
currently,
and
this
would
be
declaring
a
tenth
of
of
why
you
are
contributing
to
the
project,
obviously
optional
as
well.
So
no
we're
not
going
to
force
down
people's
throats
that,
yes,
you
have
to
fill
out
this
form
in
order
to
contribute.
This
is
really
just
a.
E
How
can
we
help
you
and
help
us
type
of
form
but
I
other
ideas
that
we
had
would
be
to
auto
trigger
it
from
from
the
bot
or
a
bot
after
their
first
time
contribution
into
the
project,
so
we
get
a
good
sense
of
who
they
are,
what
they're
doing?
Why
they're
doing
it
and
then
also
I,
did
put
together
an
expectation,
/
guidelines
that
was
similar
to
the
pilot
expectation
and
guidelines
that
you
can
check
out
in
there
and
then
ideal
process,
as
you
can
tell
I
like
emojis
the
ideal
process.
E
E
E
So
this
is
kind
of
what
I
need
from
everybody
on
the
call
right
now,
because
what
we're
going
to
be
doing
is
going
through
this
beta
test
and
the
beta
test
is
going
to
have
a
predetermined
group
of
mentors
and
mentees.
Why?
Because
it's
a
beta
test
and
I
just
want
to
see
if
this
whole
structure
and
process
is
going
to
work
within
our
culture
and
again,
our
process
is
so
what?
Here
is
what
should
we
do
on
first?
Should
we
focus
on
new
contributors?
E
The
members
members
to
reviewers
and
reviewers,
who
are
approvers
Aaron,
showed
us
the
dev
stats
in
the
last
community,
major
community
meeting,
and
it
looks
like
we
do-
have
a
lot
of
human
roadblocks
at
the
approver
stage.
So
it
might
be
good
to
have
the
beta
test
cover
reviewer
to
approver,
to
see
if
this
would
be
something
that
would
work.
However,
that
would
be
obviously
a
lot
harder
and
a
lot
less
structured
for
learning
since
reviewers
already
know
a
lot
about
the
governance
and
how
things
work.
E
Let's
see
some
ops
details,
so
we
have
here,
they
would
be
set,
they
would
be
doing
their
day
to
day
and
in
a
private
slack
channel
again.
This
is
because
of
the
peer
mentoring
element,
the
feeling
like
there's
a
safe
space,
to
ask
very
small
questions,
and
the
pilots
obviously
are
included
in
this
weekly
stand-ups
would
be
used
as
as
issue
grooming,
depending
on
the
level
so
I
mean,
if
they're
new
members,
then
obviously
these
mentors
need
to
put
time
in
to
issue
grooming.
E
They
would
be
covering
a
weekly
like
I,
said,
a
weekly
topic
like
one
of
the
following
they're
listed,
and
this
is
a
definitely
a
work
in
progress,
but
rewards
and
recognition
like
what
kind
of
recognition
are
these
people
going
to
be
getting?
They
aren't,
they
are
devoting
their
time.
So
that
is
a
crucial
piece
and
what
kind
of
rewards
would
they
be
getting
as
well?
E
Just
some
of
the
things
that
I
had
on
here
is
like
blog
posts
and
tweets
and
then
rewards
these
people
would
be
having
insights
into
other
SIG's
and
how
they're
sick
processes
work.
So
we're
going
to
be
ultimately
graduating
a
class
of
people
who
are
probably
more
well-rounded
than
usual,
but
also
still
specialized
in
that
special
thing.
E
Oh
hey!
Oh
no,
my
light
just
went
out,
but
anyway,
oh
well,
I'm
in
the
dark.
So
our
et
is
a
program
that
is
a
third-party
program
where
they
pay
interns
who
are
underrepresented
in
the
open-source
face.
A
stipend,
CN
CF
has
actually
stepped
up
and
said:
they'll
pay
for
our
first
one
to
see
how
it
goes.
So
we
actually
just
selected
someone
last
night.
We
have
yet
to
hear
back
from
her.
E
Unfortunately,
today,
though,
it's
only
been
a
couple
hours,
but
that's
through
cig,
CLI
and
Phil
and
Sean
are
actually
going
to
be
mentoring
that
that
individual
together
to
see
how
that
goes
and
that's
a
semester
based
type
program,
and
we're
really
excited
about
that
to
see
you
know
what
that's
look
that
could
potentially
give
us.
We
had,
oh
by
the
way
we
also
had
like
15
awesome
applicants,
which
was
really
amazing.
We
got
a
lot
of
really
great
press
out
of
it
and
and
kubernetes
had
a
lot
of
great.
E
You
know
a
lot
of
great
things
to
say
from
people
event-based
that
mentoring
activities.
These
are
long-term
strategies,
I'm,
not
necessarily
any
go
through
this
like
slide
into
too
much
detail,
but
thinking
contributor
workshops
like
goes
had
one
recently:
speed,
mentoring
at
events
and
then
also
in
both
of
those
that
would
include
some
kind
of
mentor
training
as
well.
E
Here's
my
timelines,
so
group
mentoring,
has
its
own
timeline.
Since
it's
such
a
beast
present
a
present
today,
obviously
and
get
your
feedback
about,
you
know
what
you
think
of
the
program
is
is
like,
and
also
where
you
think
we
should
start
and
then
ultimately
launch
pilot
right
before
cube
con
and
then
ideally
launch
something
that's
more
finessed
and
more
well-documented
sometime
in
January,
and
then,
of
course,
the
other
strategies
on
the
right
over
there
and
then
my
favorite
slide
is.
We
need
help
especially
Chris.
He
loves.
E
He
would
love
some
help
on
the
mentor
guides
and
he
can
definitely
fill
you
in
on
what
he's
thinking
there
he's
on
the
call
right
now.
I'd
love
some
help
on
the
mentee
guidelines
as
well,
topics
to
cover
for
each
type
of
cohort,
meaning
like
what
development
areas
we
should
be
covering
I
need
contributors
for
contributor
office
hours
once
a
month,
I'd
say
about
two
and
then
of
course,
more
interest
in
outreach,
e-4
next
semester
and
there's
that's
it
we're
done
any
questions.
I
just
flew
through
that.
So
I
apologize.
E
B
You
know,
how's
it
appropriate
to
phrase
your
your
feedback.
What
sorts
of
things
should
you
be
nitpicky
about
what
sorts
of
things
don't
you
care
about
where,
as
approvers
I
feel
like
each
individual's
sake?
Much
like
each
individual
project
probably
has
like
its
own
way
of
doing
things
and
you're
gonna
have
a
much
tougher
time,
hurting
the
sakes
to
a
consistent
reviewer
to
approve
your
process.
I
see,
no
reason
why
we
can't,
as
a
community,
apply
pressure
to
the
existing
set
of
approvers
and
say:
hey
your
bottleneck.
What
do
you
want
to
do
about
that?
B
G
One
of
the
things
that
I've
noticed
in
most
mentoring
programs
is
you
don't
have
mentors
for
the
mentors
and
I
think
that's
a
real
challenge
in
it
self.
So
we
need
to
find
a
couple
people
for
the
initial
beta
that
are
going
to
mentor
the
mentors
and
we
need
to
get
a
sign-off
and
exactly
which
segment
we
are
mentoring.
Initially,
you
know
I
kind
of
have
a
stream
of
consciousness
on
the
mentoring
guide
right
now
in
some
parts,
still
work-in-progress.
E
A
Thank
You
Paris
next
on
the
agenda.
D
So
I'll
follow
up
with
him
offline
about
that,
but
regarding
design
Docs
just
a
couple
things,
we
did
a
reorg
of
the
design
proposals
directory
I
know
it
broke
a
lot
of
links
to
it.
I
think
it
will
help
improve
both
finding
reviewers
in
the
future.
Since
we
now
have
owners
files
in
each
of
the
cig
directories,
thanks
Chris
and
it'll
also
help
new
contributors
kind
of
organize
themselves
and
see
where
things
live.
I
know
I
was
having
some
trouble
finding
design
Docs.
D
Additionally,
another
topic
that
came
up
on
the
mailing
list
was
from
David
Oppenheimer,
who
asked
about
subscribe
to
a
repo,
but
only
getting
certain
updates.
So
community
gets
a
number
of
PRS
that
are
like
fixed
syntax
errors
or
fix
misspellings
or
grammatical
errors
of
these
little
things,
but
I
think
the
meet
of
the
work
really
comes
in
the
design
proposals
and
a
lot
of
people
are
just
interested
in
following
the
design
proposals
and
understanding
the
discussions
are
going
around
there.
D
So
his
question
was:
how
can
I
get
more
targeted
updates,
just
updates
around
design
proposals,
and
he
had
some
suggestions.
I
think
that
he
sent
out
last
night
or
this
morning,
I
don't
know
if
he
wears
on
the
call
you
ever
might
have
I
have
some
suggestions
as
well:
I
just
haven't
bothered
to
respond
to
the
email,
but
once
you
put
them
in
here
and
I'll
respond
to
email
or
you
can
either
way
my.
B
But
we
don't
have
the
feature
in
place
today.
I
kind
of
thought
that
about
six
months
ago
there
is
literally
Cote
in
place
to
add
labels
entries
to
owners
files
so
that
pull
requests
that
touch
certain
directories
could
automatically
be
labeled
with
whatever
happens,
to
be
specified
in
an
owner's
file,
the
idea
being,
if
a
pull
request
touches
something
in
a
directory.
B
That's
clearly
owned
by
API
machinery,
then
you
could
automatically
label
the
pull
request
with
sage
API
machinery
that
never
got
turned
on
it
got
stuck
in
a
quagmire
somewhere
and
if
you're
interested
in
pushing
that
forward,
I
can
point
you
to
the
right
place
to
help
out
there.
It's
not
presently
on
site
testing
roadmap,
but
we're
in
the
midst
of
reporting
the
owners
file,
parsing
and
/
to
prowl.
B
So
we'll
get
to
the
point
where
these
benefits
can
be
rolled
out
more
quickly
across
Lord
Rico's,
with
less
effort
as
we
move
forward,
oh
yeah,
but
my
bigot
or
and
then
like.
Maybe
maybe
this
is
a
sign
that
if
there
are
people
who
are
just
interested
in
all
the
design
proposals
for
all
the
things,
maybe
having
these
teams
that
each
have
design
proposal
on
the
end
isn't
actually
the
right
thing
like
we
have
a
github
team,
that's
just
for
API
reviews.
D
Agree
but
maybe
that's
a
cultural
issue
and
people
aren't
aware
of
like
a
workflow
that
could
exist,
because
a
lot
of
people
might
be
having
this
issue,
and
that
could
be
the
solution.
The
the
problem
is,
it
requires
the
author
of
the
design
proposal
to
do
work
like
they
are
required
to
tag
a
team
like
at
API
machinery,
design,
proposals
or
something
like
that,
which
is
easy
to
forget.
So
I
like
the
auto
labeling
idea,
just
without
without
putting
too
much
thought
into
it.
That
sounds
like
a
great
idea
that
might
solve
the
problem.
B
Be
spent
for
is
this
committee,
Rene's
enhancement
or
yes,
that's
what
caps
do
I
thought
caps
were
sort
of
supposed
to
be
the
way
design
proposals
weren't
going
forward,
but
I
literally
don't
I
have
an
attendant
saying
architecture
nobody's
broadcast
to
me
what
caps
are
and
how
they
work.
Yet
so
I
I
don't
know.
I
can.
F
I
Your
sister
any
of
this
okay,
sorry
so
yeah
the
that
is
the
the
way
proposals
are
supposed
to
be
put
forward.
There's
a
PR
out
there
that
has
all
the
description
of
how
this
is
supposed
to
work.
I'll,
look
it
up
and
maybe
I
can
post
it
and
the
the
slack
channel
for
the
second.
So
we
can
look
it
over
but
yeah.
Essentially
it's
it's
a
repo
entry
for
each
sake
that
basically
has
a
proposal
that
MD
and
then
that
breaks
down
to
issues
in
each
release.
I
So
basically
you
have
capped
as
a
giant
deliverable
bit
of
stuff
at
Norma
General
there
and
then,
when
it
comes
to
implementation,
I
each
release
milestone,
will
have
a
series
of
issues
that
breakout
or
chip
off
specific
bits
of
the
cap
that
will
be
worked
and
then
those
issues
are
actually
what
what
get
worked
for
the
release
increment.
Does
that
make
sense,
I.
I
A
You
great
next
topic
did
somebody
want
to
speak
to
really
quickly
the
suggested
member
scripts.
D
D
So
I
I
feel
like
this
is
a
painful
topic
that
comes
up
pretty
often
and
that
there
are
so
many
these
typo
fixes
and
they
should
be
really
easy
to
deal
with
I've
seen
people
suggest
Auto,
closing
them,
but
I
don't
know
if
that's
necessarily
the
right
answer.
If
we
look
I
just
did
a
quick
search
on
like
the
extra
small
PRS.
D
So
someone
sent
me
an
email
just
asking
if
intermix
can
start
to
think
about
ways
to
improve
this
I'm,
not
sure
what
the
answer
is.
I
know
that
we
can
probably
work
on
the
approve,
no
issue
thing,
so
the
link
that
I
posted
when
I
said
this
kind
of
stuffs
painful,
it's
a
like
tiny,
syntax
error
or
a
syntax
error
in
a
comment.
I
think
it's
a
posture
fee
and
there
are
I,
don't
know
how
many
comments
on
it.
D
B
These
should
be
like
tracer
bullets
that
I
would
totally
suggest
that
a
new
contributors
of
minute
I
po
XP,
are
I,
have
zero
problem
with
this.
All
this
does
is
highlight
the
fact
that
our
process
is
really
clunky
and
we
are
bottle
necked
on
approvers
I,
really
think.
If
we
career
the
approver
pool
that
we
could
totally
get
these
type
of
fixes
through
the
particular.
This
is
painful.
Thing
is
like
people
who
don't
have
approval
rights.
A
B
B
D
B
Also,
I
think
your
query
is
great
right.
That's
a
good
set
of
like
pretty
small
PRS
that
people
who
are
interested
in
being
reviewers
can
do
and
then
may
reviewers
are
supposed
to
be
taking
on
the
practice
of
nagging
a
potential
approver
or
something
I
feel
like
this
lines
up
pretty
well
with
dims
in
Gmail
the
other.
B
C
On
the
flip
side,
however,
I
did
approve
a
bunch
of
like
really
trivial
ones
that
it
took
a
bunch
of
time.
So,
while
while
I
was
doing
Gary
last
week,
you
had
me
go
through
contributing
to
MD
to
make
sure
that,
like
the
links
were
broken
and
stuff
I'm
a
PR
and
I
took
the
time
to
add
a
trivial
edit
section
to
contribute
the
MD
innocence.
Er
I,
put
in
there
that
kind
of
is
a
collaborative
like
hey
there.
C
Policy
on
trivial
edits,
they
call
it
I,
but
it
kind
of
encourages
people-
hey
you,
don't
just
fix
one
thing,
look
at
the
whole
file
and
see
if
it
makes
sense,
not
that
we
should
encourage
people
to
fix
things,
but
you
know
I
I
did
find
that
it
was
sometimes
there
was.
This
person
who
was
just
clogging
up
I
mean.
A
D
A
A
You
should
we
do
a
status
update
on
our
goals
for
1.9.
D
B
And
I
really
apologize
for
stealing
the
Thunder
there,
but
like
we
had
the
room
for
it,
and
he
was
talking
a
lot
about,
but
I
think
like
I
would
really
encourage
you
to
put
it
in
front
people's
faces
again.
So
I,
like
I,
have
a
couple
entries
down
at
the
bottom
of
the
meeting
notes
here
on
dev
stats,
where
I'm
trying
to
demonstrate
that
look.
B
If
you
open
an
issue
in
dev
stats,
they
actually
respond
and
do
stuff
like
there
was
a
PR
SH
dashboard,
but
they
listened
to
issues
H
dashboard
and
now
there
is
because
I
asked
for
it
so
stuff,
like
that
and
I
think
George
had
a
question
about
like
hey.
How
can
Singh's
actually
use
this
in
an
actionable
way?
I
personally
haven't
had
much
time
to
go
through
and
discover
and
look
for
new
stories
or
new
actionable
insights.
A
K
We
knew
so
this
is
Matt
I'm
gonna
pipe
up
here,
I've
been
quiet
for
the
most
part.
When
you
talk
about
dev
stats,
can
you
please
because
I
know
that
the
data
came
from
OpenStack
and
a
lot
of
folks
don't
know,
and
so,
when
I
started,
looking
at
things
like
company
velocities
I
realized
that
a
bunch
of
people
who
are
feeding
into
that
are
at
other
companies.
Now
the
de
nada
is
not
up
to
date
as
far
as
where
it
came
from
with
get
diem.
Okay,
I
can.
B
K
Harp
on
it
everywhere
with
directions
on
how
they
can
update
it,
because
otherwise,
it's
not
useful
data
when
it
comes
to
company
names
right.
B
This
group,
personally
personally
I,
think
this
group
is
way
more
interested
in
all
of
the
exporters
that
do
not
have
companies
on
their
name
so
like
TRS
age
issues,
age,
the
time
dashboard
that
shows
how
long
it
takes
to
get
issues
merged
through
the
different
or
sorry
pull
requests
merge
through
the
different
phases.
I'm,
not
saying
that's
a
valid
thing,
I'm,
not
sure
this.
Is
this
a
comment
we're
happy
to
like
broadcast
it,
but
you're,
maybe
might
be
the
more
appropriate
person
since
is
representing
its
the
MTF.
F
That's
correct,
so
if
you
see
any
in
current
date
or
a
good
in
your
company
affiliation
of
somebody
else,
company
inflation
at
the
moment
so
feel
free
to
submit
a
PR
to
DDM
rave
on
the
cnc
organization
on
github.
Draw
two:
is
one
of
them?
Is
company
developers
listen
develop
the
issues
releases,
so
please
review
them
and
if
you
see
en
you
see
any
inconsistency,
we
are
open
to
your
peers
and
will
omit
at
the
merger
them
all.
The
links
are
in
our
church.
C
D
C
D
Maybe
you
can
link
to
the
issue
Paris.
Can
you
have
the
link
there
yeah.
A
B
There's
one
just
the
bigger
dose
last
thing
is
I,
don't
know
who,
if
anybody
in
this
group
owns
metrics
but
like
CN
CF
did
a
great
thing.
By
putting
this
thing
together,
I
find
it
to
be
fascinating,
but
the
amount
of
time
I
can
actually
dedicate
to
exploring
it
and
asking
like
what
are
the
actionable
things
I
can
come
up
with
from
this
turns
out
to
be
far
less
than
I
had
hoped.
B
I
tend
to
squirrel
around
on
a
bunch
of
different,
like
steering
committee
related
things
at
times
when
I
can
I'm
trying
to
come
to
Deb
stats
with
the
question
how
you
know
like
if
I
have
a
question
about
what
would
make
things
better?
How
can
I
use
that
stats
to
see
where
we're
at
today
and
if
I
can't
do
that?
Can
I
ask
them
to
fill
that
gap?
B
That's
what
caused
the
issues
age
dashboard,
one
of
the
things
that
confuses
me
most
is
that
often
times
many
of
the
dashboards
have
repository
groups
like
API
or
project
infra.
Things
like
that
or
or
apps
and
I.
Don't
actually
know
what
repo
belongs
in,
which
group
so
I
asked
about
this
and
I
like
oh
yeah.
It's
in
this
sequel
file
that
doesn't
I'd
love
to
find
a
way.
I,
don't
know
if
you're
fond
it
well
enough,
but
I'd
love
to
find
a
way
to
highlight
that
more.
B
My
hope
and
dream
was
that
you
could
have
alternate
dropdowns
like
one
for
just
all
the
repositories
and
one
for
groupings
and
the
groupings
could
like
selecting
to
the
repositories
but
I
don't
having
taken
a
look
at
the
data
more.
That
doesn't
quite
make
sense
so,
like
maybe
it's
just
me
like.
Maybe
it's
actually
not
useful
to
see
things
on
a
curve
repository
basis,
but
then
maybe,
like
the
groupings,
aren't
quite
right
because,
for
example,
cubes
ETL
is
grouped
under
apps
right
now,
which
I
don't
think,
makes
a
lot
of
sense
and.
B
Like
kubernetes
versus
kubernetes
incubator
repo
to
spread
across
these
groupings
where
I
might
want
to
see
it
broken
up
by
board
so,
like
my
meta
thing,
is
really
calling
out
to
people
to
please
like
use
this,
please
think
about
this
Brian
grant
sent
out
multiple
docks
Lou
this
group,
the
like
project,
health,
dashboard
thing
and
there's
an
email
sometime
at
the
beginning
of
this
year.
That
was
about
like
what
are
the
metrics
we
want
when
we
think
about
trying
to
improve
our
situation.
How
can
we
use
dev
stats
to
to
measure
this
this
forward?
B
I
haven't
looked
at
it
lately,
but
like
does
it
I,
don't
know
if
it
answers
the
question
like
do
we
have
overloaded
particular
individuals
who
are
overloaded
for
review?
Do
we
have
particular
individuals
who
are
taking
way
too
long
to
review
the
PRS
that
they're
assigned
to
questions
like
these,
like
the
tool
is
here
now?
It's
not
perfect,
I
think
there's
a
lot
of
iteration
required
and
if
anybody
has
the
time
to
help
iterate
on
it,
please
do
so
because
I
think
it's
great
okay.
C
The
thing
of
the
thing
I
was
gonna
case
when
I
found
that
bug
was
the
quote:
unquote,
make
it
easier
for
SIG's,
but
it's
too
big
of
a
topic,
so
I'm
planning
on
talking
with
the
guy
at
Q
con,
because
it's
like
a
complicated,
that's
the
same,
but
I
was
taking
a
week
if
we're
going
to
be
breaking
things
down,
but
making
it
useful
for
SIG's
individually
would
be.
You
know,
like
I,
think
the
like,
through
the
data
different
ways,
as
opposed
to
you,
yeah.
B
I
think
one
thing
that's
lacking
from
a
couple:
different
dashboards,
for
example,
if
some
of
them
don't
slice
by
sake,
some
do
some
don't.
That
would
be
helpful
because
if
you
guys
remember
the
was
it's
a
foe
or
whatever
a
while
back
that
showed
the
open
issue
counts
and
the
open
PR
counts.
By
saying
we
lack
that
equivalent
for
for
PRS
anyway.
That
kind
of
lines
up
nicely
what
the
question
dooms
was
asking
about,
whether
we
want
to
consistently
apply
cig
labels
to
PRS
the
same
way.
B
We
do
the
issues,
that's
off
topic,
but
anyway,
yeah
just
like
that
that
sort
of
stuff,
even
if
it's
like
additional
facets,
you
want
to
filter
by
that
that
all
would
be
just
super
helpful
and
I'm
trying
to
like
just
use
the
issues
thing
to
raise
the
questions,
since
that
seems
to
be
channels
of
engagement,
I
want
to
move
on
real,
quick
for
running
oil
on
time.
What
does
it
talk
briefly
about
owners?
I
alluded
to
it
earlier.
B
The
owners
files
that
are
used
in
communities,
kubernetes
and
many
other
repos
are
consumed
by
munch
github
we
are
moving
to
have
them
instead
be
consumed
by
prowl.
The
reason
we
are
doing
this
is
because
you
have
to
deploy
a
separate
lunch
github
instance
for
each
repository
that
you
want
how
to
do
stuff
for
prowl
instead
can
be
pointed
at
multiple
organizations
and
all
repositories
within
those
organizations.
B
It
can
also
be
customized
on
a
per
recode
basis,
so
we
moved
the
owner
file
parsing
code
like
copy
whatever
the
owner
of
a
person
code
into
pro,
and
then
there
are
a
couple
different
plugins
that
rely
on
the
owners
files
that
were
starting
to
use.
So
apparently
Chris
Christopher
just
said,
like
the
thing
that
label
auto
labels
pull
requests
based
on
owners
files
is
actually
live
in
prowl
the
approval
handler
that
Munch
github
dude
uses
so
that
that
comment.
B
That's
like
here's,
the
owners
files
that
your
PR
touches
and
here
the
people
that
need
to
approve
your
PR.
Because
of
that
we've
got
that
as
a
proud
plugin.
It
is
active
and
turned
on
and
testing
for
now.
If
we
are
happy
with
it,
we
will
let
the
community
know,
and
we
will
plan
on
rolling
that
out
to
other
repos
once
we
do
that,
it's
the
other
big
one
would
be
blunderbuss
the
one
that
like
assigns
people
based
on
whose
own
owners
files
to
pull
requests.
B
Once
we
do
that,
we
can
turn
on
randomly
assigning
people
and
then
pretty
much
any
repo
that
has
a
navona
file,
so
I've
been
trying
to
go
through
and
touch
every
single
repo
that
has
an
owner's
file,
because
many
of
them
still
use
a
deprecated
assignees
field
which
doesn't
make
any
sense.
We
want
to
remove
the
assignees
field,
it's
basically
the
same
thing
as
having
an
owner's
file
that
just
as
approvers
so
I've
I
gained
the
system.
B
I
created
a
small
PR
across
almost
every
repo
in
our
organization
I'm
the
problem
right
here,
but
it's
also
been
a
useful
experience
to
understand
which
repositories
requests
that
I
sign
my
commits,
which
repositories
are
using
Travis
for
CI,
which
repositories
are
being
super
responsive
which
repositories
are
having
a
more
involved
discussion
about
what
this
change
means.
So
it's
been
interesting
in
that
regard.
I
would
anticipate
to
hear
more
from
state
testing
about
this
as
we
progress,
but
we
can
start
like
using
other
files
owner's
files
more.