►
From YouTube: Kubernetes Contributor Experience SIG 20180725
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
B
Hi
Jeffrey:
do
you
want
to
introduce
yourself
yeah?
My
name
is
Jeffrey
Sica
I
am
the
other
half
of
the
hive
mind
Bob
Dylan
is
the
first
half
of
the
hive,
mind
Bob
and
I
both
work
at
University
of
Michigan,
so
you
can
actually
see
my
desk
in
the
background
of
Bob's
camera.
If
you
really
look
yeah,
oh.
A
A
A
D
Okay,
so
so
the
last
week
has
been
again,
the
biggest
challenges
so
far
has
been
is
the
kind
of
relevance
piece
and
like
making
sure
that
we're
always
showing
the
right
answers
to
people.
D
It's
basically
been
an
endless
struggle,
kind
of
and
been
doing
this
for
a
while
and
still
haven't
found
the
silver
bullet,
but
but
making
lots
of
like
small,
you
know
changes
so
basically,
the
goal
here
is
to
so
I
mean.
Maybe
the
step
back
a
bit
is
like
when
we're
displaying
an
answer
to
somebody.
We
want
to
make
sure
that
it's
that
when
somebody
asks
a
question,
it's
the
most
relevant
answer
to
that
question.
D
So
this
is
basically
showing
like
the
yellow
and
blues
or
wrong
a
successful
answering
question
and
the
purple
is
when
somebody's
giving
us
feedback
that
it's
not
helpful.
So
we
want
to
you
know,
try
to
optimize
for
kind
of
the
yellows
and
the
light
blues
as
much
as
possible.
So
yeah,
it's
still
working
a
lot
on
that.
No
no
magic
bullet,
yet
I've
actually
find
like
even
starting
and
looking
to
find.
Like
you
know,
more
professional.
E
D
Science
and
opie
people
that
kind
of
figured
this
one
out
a
little
bit
better
so
other
than
that.
One
thing
that
I've
been
working
on
this
week
is
also
like
this
is
the
storing
pipeline
of
like
every
time
we
ask
hey.
Do
you
want
to
store
this
for
later?
So,
basically,
the
blue
one
is
every
time
we
ask
and
a
purple
one
is
what
actually
somebody
clicks
the
store
button
and
because
of
this
kind
of
large
drift
between
the
two,
especially
on
certain
days,
I'm,
realizing
that,
like
people
aren't
always
clicking
the
store.
D
D
So
there's
not
really
any
way
to
see
any
stats
from
that
and
then
kind
of
the
third
thing
that
I've
been
working
on
and
this
isn't
fully
finished
yet.
But
you
know
this
kind
of
still
work
in
progress.
Is
this
idea
around
like
dividing
the
content?
So
we
have
like
a
bunch
of
channels,
you
know
in
kubernetes,
and
then
this
is
kind
of
also
really
applicable
in
a
lot
of
other
places,
but
so
in
kubernetes
we
have
like
hoob
users
and
like
novice
and
then
like
mini
coop
and
stuff.
D
Those
are
all
like
the
very
technical
channels
and
then
we
have
like
career
channels
and
we
have
like
the
sink
channels.
Right
and
all
of
those
are
like.
You
know
they
have
their
own
answers
in
the
kind
of
their
own
context
and
trying
to
intermingle
answers
between
the
two,
probably
doesn't
really
make
sense.
So
the
idea
is
is
to
break
out
some
of
these
things
into
different,
like
groups
right.
D
So
then
you
have
like
well,
these
are
the
default,
but
then
you
have
like
coop
users
would
be
like
a
specific
list
of
channels,
and
you
know
it
would
the
information
there
would
be
shared
between
those
channels.
Then
the
integrations
like
we
would
pull
it
in
the
stack
overflow
questions
only
into
those
questions,
as
opposed
to
like,
for
example,
the
careers
channel.
We
can
roll
on
it.
Currently,
it's
not
part
of
this,
but
you
would
be
able
to
like
see
just
you
know,
not
the
Stack,
Overflow
questions
and
stuff.
D
E
Yeah
so
as
far
as
I
understand,
I
kind
of
one
of
my
co-workers
basically
submitted
it.
Pri
got
a
mention
to
master
and
really
wanted
to
have
support
for
111
in
110
as
well
and
submitted
cherry
picks
and
followed
the
instructions
and
did
all
the
things
and
then
it
just
kind
of
sat
there
and
then
was
unclear
what
was
going
to
happen
or
who
he
should
came
for
attention
right
and
so
so.
I
understand
that
we're
sort
of
blocked
on
automating
cherry
picks
horse
for
reasons
that
I
don't
understand
that.
E
Maybe
somebody
has
some
input
on,
but
at
the
same
time
I
just
wanted
to
improve
the
documentation
and
also
try
and
figure
out.
It
was
maybe
we
we
can
or
or
should
we
have
the
bot
pick
up
on
the
current
branch,
patch
branch
manager,
so
that
contributors
know
whom
to
pain
because
I
think
that
in
a
lot
of
other
communities,
people
aren't
an
assistant
or
in
you
know,
aren't
necessarily
as
willing
to
defend
or
fight
for
their
peers
because
they're
worried
about
backlash
or
bothering
people
or
something
like
that.
E
And
so,
if
we
had
an
official
thought
prompt
hey,
this
is
the
person
that
you
should
ping.
If
this
has
been
sitting
around
for
a
few
days,
that
might
be
a
good
thing.
I
yeah
I
dropped
a
link
to
Aaron's
umbrella
issue
or
someone's
umbrella
issue,
actually
from
that's
over
a
year
old
though.
So
this
is
I
think
a
recurring
issue
for
what
it's
worth
this
particular
contributors.
Experience
with
merging
into
master
was
just
fine.
It
was
the
cherry
big
process
that
seemed
like
really
confusing
and
off-putting,
and
I
tried
to
help
out.
E
I'm
like
on
the
release,
team
and
I
still
was
like
I'm
super
confused.
Who
is
in
charge?
What
is
what
is
who's?
The
branch
owner
I
don't
get
it
like.
Is
that
the
patch
release
manager,
oh
okay,
but
you
know
how
to
go
around
and
like
solicit
information
from
humans,
and
not
everyone
isn't
a
good
place
to
do
that.
A
So
I
know
we
we
were
looking
at
the
cherry-pick
process.
I
know
Aaron
was
going
to
take
a
look
at
it,
but
things
came
up
in
the
last
cycle
and
I
know
that
wasn't
that
work
wasn't
fully
completed
but
I
know
we
were
looking
I
know.
Jordan
legit
had
created
a
another
proposal
of
another
kind
of
path
to
overhaul
the
cherry-pick
experience.
A
There
might
be
some
incremental
improvements
we
can
make
now,
but
also,
at
least
in
my
opinion,
I
think.
The
entire
kind
of
experience
needs
an
overhaul
as
far
as
like
what
that
process
looks
like,
and
what
oh,
and
also
make
it
easier
for
branch
managers
to
understand
what
what
what
PRS
they
need
to
review
where
they
all
are
because,
right
now
at
least
my
understanding
is
the
branch
managers,
all
kind
of
have
they
kind
of
create
their
own
queries
in
their
own
system
for
themselves.
E
A
Opposed
to
kind
of
understanding
like
hey,
this
is
all
set
up
for
you.
You
just
need
to
kind
of
go
and
look
here
in
this
one
place
for
your
branch
to
know
like
what
what
is
at
least
queued
up
and
what
are
what
steps
are
still
needed,
whether
it's
you
know
approval
from
code
owners
or
whether
it's
just
the
branch
managers.
Final
final
approval
that
commits
it.
E
It's
it's
a
little
bit
weird
because
it's
literally
a
one-person
bottleneck
right
because
we
have
to
all
the
regular
approval
process
it
has
to
be
approved
for
the
milestone
it
has
to
be.
You
know:
sig
liens,
chapter,
okay,
it
and
approve
it
and
do
all
the
things
and
add
all
the
labels
and
there's
a
ton
of
labels,
and
then
it
just
sits
and
waits
for
the
branch
manager
to
remove
that
cherry-pick
not
approved
I'm,
not
sure
why
we
have
that
step
necessarily
but
I'm
sure,
there's
reasons
I
can.
F
Answer
so
after
the
dot,
zero
version
of
a
release
is
cut
the
entire
release
team
disbands,
and
there
is
no
more
release
team
for
patch
releases
going
forward.
That
means
it
falls
on
one
person
to
catch
everything
both
whether
or
not
they're
outstanding
issues,
whether
or
not
the
bill
is
ready,
Rico
and
so
the
cherry-pick
process
is
oriented
towards
making
their
lives
as
easy
as
possible.
F
So
all
this
stuff
that
was
referenced
about
discussions,
we've
had
in
the
past
liggett's
proposal,
the
possibility
of
using
a
bot
to
add,
like
a
slash,
cherry-pick
command,
which
is
openshift
folks,
have
been
doing
for
a
little
while
and
adding
additional
labels
that
can
be
swept
through
to
keep
accounting
for
like
what
is
what,
if
we
want,
one
pull
request
to
master
to
be
back
ported
to
like
three
different
branches.
How
can
we
account
for
that
in
an
automated
manner?
F
All
of
that
is
track
of
that
issue
and
then
yes
make
a
call,
but
I
sounded
like
because
I
could
articulate
all
this
like
I
was
the
guy
who's
gonna.
Do
it
and
then
I
changed
jobs
and
took
a
nice
long
break,
and
nobody
has
really
stepped
up
to
pick
up
the
work
and
I'm
not
going
to
be
able
to
pick
up
the
work
in
any
way
this
quarter,
so
I
feel
like
there
is.
Certainly
there
are
certainly
incremental
improvements
that
could
be
made
if
somebody
wants
to
volunteer.
E
Alright
I
would
I
would
support
that
and
I
wasn't
trying
to
say
that
we
should
make
anything
more
difficult
on
the
branch
manager
at
all.
I
was
I
was
actually
confused.
Why
we
have,
if,
if
we
have
to
go
through
a
regular,
proven
process,
which
we
do
because
who
knows
if
these
particular
features
will
work
with
a
particular
version
right?
Only
the
you
know,
code
owner
cygnets
have
a
reasonable
idea
of
that.
So,
as
far
as
I
can
tell,
the
branch
manager
just
puts
the
final
stamp
on
it
for
like
overview
purposes.
So
that's
that's.
E
A
It
is
procedural
that
you
you
picked
up
on.
It
absolutely
is
procedural,
but
there's
a
lot
of
cases
where
a
branch
manager
may
not
want
APR
to
immediately
merge
into
a
branch.
It
may
be
because
they're
freezing
the
branch
for
a
couple
days
before
cutting
a
release
and
they
need
a
one
like
a
solid,
green
CI
signal
over
a
couple
different
runs
to
know
that
they
are
safe
to
go
and
cut
the
next
point
release
and
they.
A
The
entire
branch
actually
for
longer
than
that,
if
the
branch
manager
through
like
non
public
channels,
finds
that
there
is
a
security
fix
that
needs
to
go
out.
So
they
may
actually
freeze
the
release
branch
for
longer
than
that,
and
they
can't
tell
anybody
that
they're
doing
that,
specifically
because
of
our
security
embargo
process.
So
there
may
be
cases
where
a
release
branch
is
frozen
for
a
month
or
longer
because
they
know
a
security
patch
is
coming,
but
they
can't
tell
anybody
just
yet,
but
a
security
patch
is
coming
because
of
the
embargo
process.
A
So
there's
a
number
of
different
reasons
why
a
branch
manager
would
choose
to
three
use
a
release
branch.
So
that's.
Why
there's
an
extra
step
and
why
everybody
like
whether
they
have
access
to
it
or
not?
Everybody
to
first
the
branch
manager,
because
that
branch
manager
is
being
altom
utley,
a
single
point
of
contact
responsible
for
the
stability
of
that
branch
and
if
they
call
a
relief
that
has
a
regression,
it
would
also
be
on
them
and
their
responsibility
to
fix
it.
A
F
Couple
meta
problems
here:
number
one
I
think
because
we
defer
to
the
branch
manager
is
the
singular
person
like
they
can
be
overwhelmed.
It'd
be
nice
if
we
had
a
better
release
process
like
more
of
a
small
release
team
for
each
branch,
but
so
that's
one
way
you
could
solve
the
problem.
The
other
way
you
can
solve
the
problem
is
to
make
it
really
I've
heard.
F
I
saw
some
chatter
in
the
channel
about
like
making
it
just
really
clear
sort
of
what
our
release
life
cycle
looks
like
and
where
a
given
branch
is
in
that
relief
cycle
release
life
cycle.
So
then
you
could
understand
like
what
the
rules
of
play
are
and
then
finally,
the
code
that
applies
the
cherry-pick
not
a
free
play.
Ball
is,
sadly
I,
think
Munter
in
munch
github.
F
This
way,
it's
an
informative
link,
it's
right
where
the
person
opened
their
PR
and
it
doesn't
actually
ping
anybody
with
a
notification
because
trust
me,
the
patch
managers
know
what
to
look
for,
but
I
don't
foresee
any
changes
being
pushed
in
too
much
github,
because
we
really
want
it
to
go
away.
So
we're
not
really
making
any
more
changes
to
munchers.
F
E
Cool
also,
thank
you,
everyone
for
explaining
this
I'm
rewriting
the
doc
a
little
bit
right
now.
So
this
really
helps
give
me
some
good
background.
I
appreciate
it
I'm
going
to
take
all
further
discussion
on
to
that
issue
that
you've
been
tracking
Aaron
and
just
kind
of
discuss
options
there.
So
we
have
a
record
okay.
F
E
We're
also
looking
into
a
an
issue,
discovery,
automation,
tool
and
they're,
released
to
you
right
now,
so
somebody
shared
this,
they
wrote
it.
It
looks
pretty
great
we're
gonna
see
if
we
can
make
it
to
something,
even
ever,
not
anyway,
maybe
yeah
anyway.
I'll
comment
on
the
issue.
A
A
Do
you
know
if
there
is
ongoing
efforts
behind
like
getting
those
last
month
out,
I
know
I
know,
there's
definitely
been
a
consistent
push
to
migrate
away
from
the
some
q,
but
I
know
there's
still
like
some
munters
like
the
milestone
and
like
the
cherry
pick,
but
there's
a
few
kind
of
last
Monday's
sticking
around.
Do
you
know
when
is
there
like
a
target
drop
dead
date
of
like
we
really
want
all
them
unders
and
that
entire
munch
cluster
to
go
away?
I
wish.
F
I
could
give
you
one
I
really
do
if
it
was
the
only
thing
that
was
on
my
plate.
I
would
tell
you:
is
this
quarter?
It's
not
I
think,
like
we
kind
of
need
to
answer
how
we're
gonna
make
the
cherry-pick
process
same
because
that
wipes
out
most
of
the
munchers,
then
there's
the
milestone,
maintainer
muncher
and
beyond
that
I'm,
not
a
hundred
percent
clear.
F
But
it's
like
this
is
where
I'd
like
to
go
reach
out
to
you,
pat
release
managers
and
branch
managers
and
understand
how
much,
if
at
all,
they
use
the
cherry,
pick
cube
for
their
day-to-day
work
and
if
any
of
the
munchers
are
of
any
help
to
them
right
so
I
have
an
issue
on
I
can
find
it
and
like
it,
I
have
an
issue
with
like
all
the
munchers,
but
know
that
there's
there's
never
been
like
time
attached
to
it.
Just
like
slowly
crossing
things
off
the
list.
F
So
kind
of
related
to
that
I
think
I'm,
just
gonna
roll
on
into
my
next
two
topics
and
I'm
gonna
jump
down
where
the
second
one
first,
because
it's
really
easy.
Just
the
notification
that
I'm
getting
my
great
priority.
The
priority
failing
test
github
label
too
kind
failing
test,
I've
sent
emails,
I
have
some
PRS
held
and
ready
to
go
I'm
just
waiting
for
any
further
objections
or
comments.
If
you
have
any
raise
them
by
3:00
p.m.
Pacific,
otherwise
I
will
do
the
needful.
That's
pretty
much
it
for
that.
F
The
next
thing
is
the
Thera
folks
at
the
cuvette
folks
in
the
cuvette
diem
repo
have
developed
this
pattern,
where
they
manually
add
an
active
label
to
issues
that
they
are
working
on,
so
that
people
know
that
that
issue
is
like
somebody's
got
it.
So
don't
you
know
like
no
need
to
jump
in
on
it
sort
of
deal,
and
they
were
wondering
after
talking
with
Ben,
with
her.
F
It
made
sense
to
add
it
to
the
like
the
set
of
lifecycle
labels
so
that
you
could
just
slash
lifecycle
active
instead
of
having
to
manually,
apply
this
label,
so
that
sounded
like
a
cool
idea,
but
that
kind
of
makes
me
think
that
that
overlaps,
an
awful
lot
with
the
status
in
progress
label,
that
the
release
team
uses
and
is
consumed
by
the
milestone.
Maintainer,
wonder
it
kind
of
feels
to
me.
F
Like
I
said,
that's
not
the
cuvette
DM
team,
but
we
wouldn't
necessarily
want
to
mandate
that
as
a
process-
and
we
probably
wouldn't
want
to
have
like
a
bot
sweep
through
and
automatically
like
apply
lifecycle,
active
labels
to
issues
that
have
been
touched
within
n
days
right.
It
could
be
just
an
extension
of
the
bot
that
goes
through
and
applies
life
cycle,
stale
to
issues
that
haven't
been
touched
in
30
days
or
some
threshold.
Like
that,
we
could
say
if
an
issue
hasn't
been
touched
within
10
days.
F
It
loses
its
active
label
so
that
people
know
that
maybe
that's
not
actually
being
worked.
So
I
kind
of
brain
dumped.
All
of
this
in
the
issue,
it's
linked
in
the
agenda,
but
I'm
really
curious.
What
like
release
team
folks,
a
perspective
is
on
this
because
I
see
two
former
release
leads
in
an
issue
triage
person
here.
So
the
first
thing
I'll
say
is
I
absolutely
agree
with
you
that
the
nagging
being
done
by
the
milestone
muncher
bot
is
at
this
point
ineffective,
because
people
get
too
much
traffic,
and
so
they
ignore
it.
F
E
E
F
Then
we
need
to
at
least
post
a
notice
in
the
comments
on
the
issue
that
it's
going
to
be
auto
closed.
If,
if
nothing
else
happens,
the
but
I
personally,
don't
see
a
good
reason
why
to
replace
LifeSite
status
in
progress
with
life
cycle
active
but
I,
don't
see
a
good
reason
not
to
and
for
some
reason
the
people
who
are
gonna
use.
It
really
prefer
life
cycle
active.
It's
not
a
problem.
I
found
in
the
111
cycle.
People
did
not
really
use
status
in
progress.
F
I
would
want
to
do
one
other
thing
with
that
to
reduce
the
impact
of
cookie.
Looking
for
those
unfamiliar
with
the
this,
this
big
EULA
slang
term.
That
means,
when
you
touch
an
issue
and
say
I'm
working
on
this
and
then
go
on
vacation
would
be
to
have
life
cycle
active
or
automatically
disabled.
If
there
isn't
activity
on
the
issue
or
PR
within
a
certain
period
of
time,
the
label
would
be
automatically
removed.
F
That'll
take
some
finessing
to
work
out,
though,
because,
like
in
the
case
of
the
coop
administers,
there
often
is
activity,
but
the
activity
is
in
the
cubed
mineral
posit
Orion,
not
in
the
active
one
that
they've
say,
mark
and
kubernetes
kubernetes
and
I'm,
not
really
sure
how
to
handle
that.
We're.
F
Yeah,
these
can
be
done
in
bite-size
steps
right.
So,
like
literally
the
y'all
know
the
the
bots
that
goes
through
and
applies
like
life
cycles.
Dale
is
literally
just
a
program
that
can
give
it
a
github
query:
go
like
post
a
comment
based
on
that
getteth
query,
and
it
just
so
happens
that
if
the
comment
includes
slash
commands,
then
it
does
the
same
things
that
a
human
could
do
if
the
human
posted
that
comment
with
this
slash
commands.
F
So
that's
how
we
have
the
query
set
up
for
like
if
an
issue
hasn't
been
touched
in
30
days
and
it
has
lifecycle
stale,
it's
going
to
have
life
cycle
rotten
added
to
it.
So
there's
nothing
saying
we
couldn't
start
tweaking
that
kind
of
fun,
stuff,
I,
just
thought.
One
of
the
advantages
of
lifecycle,
failover
status
in
progress,
for
example,
is
the
status
command
is
restricted
to
people
who
are
in
the
kubernetes
miles
the
maintainer
x'
team,
whereas
like
if
I
make,
if
I
turn
it
into
a
life
cycle
command,
anybody
can
use
it
literally.
E
It
so
this
sounds
like
a
pretty
good
refactor
to
me
honestly.
Just
have
pure
labels
have
one
label
that
does
similar
things.
The
only
thing
we're
so
basically
as
as
a
bug
triage
person,
the
timeline
under
which
I
need
action
on
a
particular
issue.
A
pull
request
keeps
getting
shorter
and
shorter
and
shorter
throughout
the
release
process.
So
I
don't
know
that
we
can
necessarily
sell
this
kind
of
us
and,
like
oh
hey
now,
issues
are
just
more
easily
discoverable
less
active,
because
that
label
means
nothing
if
it
only
gets
applied.
E
G
Like
part
of
that
that,
in
a
way,
the
label
is
implying
that
it's
assigned
like
if
assigned,
was
just
not
taken
but
I,
really
like
the
aspect
that
Aaron
mentioned
and
where
right
now,
you
can
only
assign
to
a
member
right
where
this
could
say
like
so-and-so
non-member,
is
trying
to
take
it
up
and
and
for
new
contributors.
That's
actually
important.
F
I
would
love
to
see
discussion
on
that
issue
like
I
said,
especially
from
early
steam
folks,
since
this
primarily
affects
your
lives
and
like
I,
don't
have
to
be
too
I,
actually
would
prefer
it
if
I
don't
be
the
guy
to
do
this,
like
I
think
this
is
another
like
great
task
for
somebody
else
to
take
on
if
they
want
to
it's
one
of
those
just
because
I'm
just
talking
about
it
doesn't
mean
like
I,
have
all
the
time
in
the
world
to
do
it,
but
it
seems
like
a
good
idea.
H
F
Not
really
sure
it's
possible,
but
again
that's
one
of
those
things
that
feels
a
little
bit
like
additional
process
for
process
sake.
H
F
Sorry,
no
it's
it's
I
just
haven't
seen
the
status
command
being
used,
so
I'm
not
sure
how
much
people
use
the
in
review
thing.
This
is
one
of
those
cases
where
I'm
trying
to
like
pave
the
cow
paths
where
I
can
see.
People
are
using
a
thing
called
active,
but
it
seems
to
make
sense
to
put
it
there.
Okay,.
F
I'll
say:
is
the
next
release
lead
I'm,
also
really
in
detail.
You
know
everything
else
being
equal
in
favor
of
anything
that
removes
required
labels
from
the
the
code
freeze
and
code
slush
process,
yeah
I
think,
like
Quinn's
earlier
point
about
the
contributor
having
to
add,
go
through,
like
all
these
ridiculous
labels
to
get
something
contributed
to
master
and
then
something
totally
different
for
a
release.
Branch
I
personally
feel
like
a
lot
of
those
ridiculous
labels
are
perfect,
so
process.
F
Scarring
right
is
where
we
made
a
mistake
once
right
and
then
we
created
a
whole
new
process
and
a
whole
new
set
of
things
to
do
it,
and
then
we
never
actually
looked
back
to
see
if
it
helped
us
it's
just
process
for
like
it.
Just
seemed
like
a
good
idea
at
the
time
and
then
that,
because
of
what's
the
word
anyway,
like
the
next
release,
team,
basically
built
on
top
of
that,
instead
of
looking
to
see
if
the
root
cause
was
addressed.
So
it's
unclear
to
me
how
helpful
those
things
have
been.
G
Release
member
perspective,
I
feel
like
one
of
the
things
like
that,
exactly
that
that
sort
of
scarring
that
you
described
is
happening,
but
also
the
release
team
is
going
to
have
to
do
some
level
of
tracking
on
their
own.
That's
outside
of
github
and
I
have
some
some
sense
somewhere
else
of
what
is
active,
what's
important
in
a
very
subjective
way
and
or
what's
worrying,
and
by
pushing
that
into
labels
that
everybody
in
the
community
all.
G
However,
many
thousand
people
have
to
comprehend
and
keep
track
of
and
keep
up
to
date,
I
think
that's
unfair
of
us
on
the
release
team
and
right
now
that
the
system
doesn't
work
ideally
for
us,
but
while
we're
trying
to
figure
out
how
to
make
it
better,
we
should
incur
most
of
the
hip
I.
Think
nots,
the
entire
community.
E
I
have
a
comment
that
I'm
not
sure,
makes
sense,
but
when
I
hear
lifecycle,
active
I,
don't
necessarily
immediately
jump
to
this
is
being
worked
on.
I,
don't
know
what
the
lifecycle
is.
Is
it
the
release
cycle?
Is
it
the
I
whose
life
cycle
the
PRS
life
cycle
do
I
have
to
be
part
of
a
life
cycle?
Now
it
sounds
kind
of
like
a
big
and
scary
thing,
so
it's
not
a
very
intuitive
name
for
a
label
when
we
want
it
to
mean
hi
I'm
working
on
this
right,
I
mean
it
really
is.
E
That's
that's
what
we're
trying
to
say
it's
supposed
to
be
an
overall
hello,
I
am
working
on
this.
This
is
active
and
then
we
can
get
some
automation
going
that
recognizes
that
label
and
checks
against
the
time
of
the
last
activity
on
that
issue.
A
pull
request,
pull
request
in
this
case
right,
but
or
issue
I,
guess
anyway,
I.
Don't
I,
don't
like
the
word.
Lifecycle,
active
and
I
understand
that
it's
a
label
that
we
already
have,
but
for
like
general
use,
I'm
like
whew.
What's
a
lifecycle?
Is
there
a
metamorphosis?
Is
there
you
know.
G
F
The
state
machine
Georgia
on
the
web,
so
it's
it's
true
again.
It's
not
it's
the
sort
of
thing
where
I
don't
want
to
create
like
a
required
lifecycle
for
everybody,
it's
just
a
convenience.
The
lifecycle
label
is
already
being
used
right,
I'm,
not
sure
if
you've
looked
at
an
issue
with
life
cycle,
stale
and
scratched
your
head
in
the
same
way
wondering
what
that
means,
but
you
also
have
like
documentation
or
description
for
the
labels.
So
if
you
about
it,
you
can
go.
Look
it
up.
Yeah.
E
And
when
the
and
then
a
blog
puts
that
label
on
there
right,
that's
the
Phaedo
bot
and
then
I
understand.
Oh
yeah.
There
has
been
no
activity,
it
literally
says
there
has
been
no
activity
on
this
right.
What
but
that's
a
different
situation
right,
because
that
label
gets
put
on
there
automatically
and
it
comes
with
a
not
with
an
explanation.
So
yeah
I
know
what
that
means,
but
I
as
a
contributor
who's,
just
like
hey
I,
want
to
do
this.
E
E
E
F
Today,
the
label
is
just
named
active
and
it's
just
on
the
cuvette
DM
rebuttal
right,
and
so
people
have
to
have
write
access
to
that
pepo
and
they
have
to
manually
apply
the
label.
I
am
proposing
that
it
turned
into
something
you
can
apply
with
a
slash
lifecycle,
and
so
the
label
turns
into
you.
Life
cycle
is
slash
food
because
I,
like
the
pattern
where
food
slash
bar,
can
be
applied
with
slash
blue
bar
right.
A
So
my
understanding
is
correct.
The
main
difference
between
like
an
issue
that
does
not
have
the
label
versus
one
that
does
have
the
label
is
lifecycle.
Active
means.
A
human
has
confirmed
that
somebody
is
working
on
this
actively,
but
otherwise
there
is
no
difference
as
far
as
the
way
BOTS
treat
those
labels
at
all.
C
C
However,
a
lot
of
the
retros
have
picked
up
process
improvements
that
need
to
happen
before
the
automation
can
happen,
so
we're
sort
of
in
a
blocked
State,
if
you
will
so
if
anybody
on
the
line
is
heavily
invested
this
year
on
mentoring
initiatives,
I'd
love
to
work
with
you
to
get
some
of
these
blockers
unblocked,
and
this
would
just
be
process
improvements.
I'll,
give
you
a
prime
example.
So
we
have
this
thing
called
the
one-on-one
hour
and
I.
C
Think
three
of
our
most
asked
for
things
as
far
as
mentoring
is
concerned,
is
code-based
tors
pair
programming
and
code
reviewing
either
going
through
someone's
code
as
a
reviewer
or
actually
someone
getting
their
code.
Reviewed
live.
Those
are
the
most
in
my
eyes,
most
three
requested
things,
especially
from
current
contributors,
so
the
one
on
one,
our
addresses
those
those
three
things
specifically
as
well
as
other
things,
but
there's
a
lot
of
little
teeny
things
in
this
process
like,
for
instance,
what
tools
do
they
use?
C
So
if
you're
interested
I'd
love
to
also
set
up
a
either
a
weekly
or
bi-weekly
cadence,
just
depending
on
discussions
from
the
group
with
mentoring
initiatives,
so
we
can
give
each
other
updates
and
set
tasks.
I
can
even
set
a
project
board
for
us
so
that
we
can
really
kick
this
thing
off
and
then,
hopefully,
by
the
end
of
the
year,
have
all
of
our
mentoring
initiatives
rolling
that
meet
all
of
our
needs.
So
that's
that's
mentoring.
C
E
E
C
C
Another
thing
that
I'd
love
to
evaluate
is
our
communication
pipelines
right
now
we're
doing
a
lot
with
figuring
out
what
works
best
for
the
community
for
different
means
and
different
audiences
and
what
a
better
way
to
ask
and
the
community
themselves.
So
we
can
evaluate
things
like
slack
and
mailing
lists
and
I.
C
C
Essentially,
but
we'll
also
do
like
a
blog
post
and
tweet
and
we'll
get
a
little
communication
strategy
going
around
it
like
C
and
C
F
will
most
likely
tweet
it.
We
do
blog
posts
and
stuff
like
that
and
then
of
course,
definitely
pass
it
along
to
through
your
individual
work
channels
and
and
kubernetes
channels.
A
F
F
A
Yeah
github
management
I,
it's
established
now
I
need
to
herd
things
together,
basically
so
as
be
kind
of
the
current
owner.
That's
a
project.
I
need
to
kind
of
figure
out.
You
know
get
some
things
down
as
far
as
like
what
our,
what
our
priorities
would
be.
Get
feedback
from
the
sig
kind
of
just
establish
the
framework
of
it.
I
also
have
an
open
question
that
I'm
asking
about
the
like
org
owner
permissions
into
ticket
around
the
security
org
that
I've
asked
out
to
the
product
security
team
to
understand.
A
Whatever
the
product
security
team
wants
to
take
responsibility
for
their
org
or
whether
they
want
control
backs
to
help
with
them
and
then
based
on
their
feedback,
then
we'll
know
okay,
what
what
is
basically
the
purview
which
orgs
are
we
going
to
take
on
and
kind
of
go
from
there?
I
should
have
some
more
stuff
and
kind
of
framework
as
far
as
where,
at
least,
where
I
see
the
direction
going
next
meeting,
and
then
we
can
kind
of
and
click
the
feedback
and
kind
of
go
from
there.
Okay,.
F
That
sounds
cool
I,
think
my
personal
opinion
is
figuring
out
who
the
group
of
people
are
that
have
the
superpowers
would
be
a
good
early
step
in
one
place
we
could
codify.
That
is
the
people
who
service
the
kubernetes
membership,
Google
Group
right
now
and
have
the
ability
to
add
people
to
different
orgs.
That
seems
like
a
thing
that's
going
to
continue
to
exist.
F
A
Has
that
that's
kind
of
the
direction
I
was
going
to
I,
know
kaylynn
cycles
I
wanted
to
touch
base
with
Caleb,
but
his
cycles
and
his
time
zones
are
off
right
now,
as
he
is
in
another
part
of
the
world.
So
when
he
gets
back,
I
haven't
talked
to
him
and
see
like
how
he
wants
to
deal
with
that,
but
I
wanted
those
Grayson
Caleb
and
he
or
because
they're
they're
doing
most
of
that
work.
Today,
anyways
for
kubernetes
membership
and
yeah
get
some
feedback
from
them,
but
that's
kind
of
the
direction
I
was
thinking.