►
From YouTube: SIG Chair's and TL's Monthly Meeting for 20200310
Description
SIG Chair's and TL's Monthly Meeting for 20200310
A
All
right,
everyone
welcome
to
marches
edition
of
the
kubernetes
chairs
and
tech
leads
meeting.
My
name
is
Paris
still
I.
Think
and
we
have.
It
looks
like
twelve
bucks
on
the
line
today
and
today
is
triage
for
Tuesday.
Our
tea
is,
tea
is
for
Tuesday
and
triage.
So
we
have
a
little
bit
of
a
theme
going
on
today.
It's
all
triage,
but
first
things.
First,
we
do
have
a
code
of
conduct.
Please
be
excellent
to
each
other.
A
A
Big
announcement
is
that
the
EU
contributor
summit
is
postponed.
I
know,
I,
don't
think
Jeff's
on
the
line.
Right
now
is
Jeff
on
the
line.
I
don't
know,
but
just
in
a
general
way.
Just
so
I
can
get
through
announcements
really
quick.
They
are
going
to
be
doing
some
virtual
things
more
TVD.
Yes,
there's
going
to
be
an
EU
summit
when
it's
postponed,
so
everybody's
happy
TLDR
more
coming
soon.
We
have
new
tech,
leads
and
say
Docs
or
any
of
them
on
the
line
right
now,
Karen
or
Tim
I,
don't
think
so.
A
I'm
looking
right
now,
I
see
Jim,
shout
yeah
shout
out
to
new
tech,
guys
it's
a
whole
new
thing.
Cursing
docs
they've
never
had
sex
before.
So
that's
pretty
awesome,
they're
they're,
taking
that
chair
role
and
splitting
it
so
that
they
can
have
some
different,
some
different
things
going
on
there,
and
then
we
also
have
new
chairs
and
sig
instrumentation
I,
see
both
of
them
on
the
line.
Right
now.
Welcome
and
Wayne
icon
to
our
lovely
party
here
of
chair
ship
and
tech
leadership
in
their
in
their
case,
chair
ship.
A
If
you
need
anything
from
us,
this
is
where
you
come
for
the
good
stuff,
yeah
and
also
the
chair
and
tech.
Lead
slack
channel
is
good
for
you
too,
and
then
it
looks
like
there
is
an
announcement
of
a
new
cap
as
well
that
that
chair
should
be
taking
a
look
at
who
added
this
to
the
agenda.
Steven.
Do
you
want
to
give
a
really
quick
overview?
Yeah.
B
C
We've
been
working
on,
I
could
hear
yes
and
we've
been
working
on
a
kept
about
this
for
a
while.
The
modular
we
have
up
at
the
moment
is
to
extend
the
support
window
by
one
release
currently
or
particularly,
to
make
it
a
calendar
year.
That
means
to
the
support
we
know
will
be
one
calendar
year,
yeah
it's
for
two
reasons,
one
to
make
it
so
that
it's
easier
for
people
to
fit
this
into
their
yearly
cadence,
but
also
a
lot
of
stuff
about
extending
it.
Changing
anything
to
do
with
support
is
kind
of
unknown.
D
C
A
E
C
C
B
I
will
I
will
say
in
advance
that
it
will
concern
you
somehow.
We
may
not
know
the
shape
of
how
it
will
concern
you
just
yet,
but
please
please,
please
take
a
look
at
it.
I
know
that,
from
from
the
cab,
some
there
was
some
mention
of
like
well.
What,
if
we
expanded
the?
What
if
we
decrease
the
interval
of
releases
right
did
three
releases
ear
instead
of
four,
then
you
would
get
your
yearly
supporter
because
of
what
I
mean
because
of
what
we
already
do
in
terms
of
support
cycle
and
three
so
yeah
it's.
B
A
All
right
moving
along
here,
alright,
so
let's
just
do
a
really
quick
last
mini
last
meeting.
Recap
I
actually
might
want
to
spend
a
little
less
time
on
this,
but
I
wanted
to
review
some
of
the
open
issues.
I've
been
trying
to
get
good
with
filing
issues
based
on
actions
that
we
have
here,
or
at
least
conversations
that
we've
had
here
and
things
that
we've
drawn
out
from
those
conversations.
Let
me
share
my
screen
just
in
case
folks.
Don't
have
access.
A
A
Some
chairs
were
saying
how
they
wanted
to
make
their
own
for
their
own
sake,
and
things
like
that
and
I
was
just
very
curious
to
see
what
a
baseline
rulebook
would
look
like
based
off
of
our
sake,
governance,
Docs
and
other
governance
Docs,
and
this
is
kind
of
what
I
drew
from
that
and
again.
These
are
like
the
things
that
I'm
in
the
duties
and
responsibilities
section
if
it
doesn't
have
like
I
suggested
by
next
to
it.
Let
me
get
my
little
pointer
like
if
it
doesn't
have
a
suggested
by
someone
next
to
it.
A
It
means
that
it
came
from
like
one
of
these
two
docs
up
here
verbatim.
It's
just
not
necessarily
in
this
like
duties
and
responsibilities.
Fashion
so
anyway,
I
just
wanted
to
bubble
that
up.
As
please
comment,
leave
any
comments
here
and
then
what
we
can
do
now
is
just
Park
will
Park
this,
for
if
we
have
time
at
the
discussion
at
the
end,
okay,
did
anybody
have
any
quick,
quick
comments
or
concerns
about
the
chair,
rulebook.
A
A
So
if
you
were
not
on
those
calls,
go
ahead
into
that
doc,
that's
linked
in
there
and
add
your
preferred
communication
channels
and
that's
what
we're
gonna
do
the
baselines
off
of
so,
for
instance,
right
now,
it
looks
like
everyone's
on
slack
based
on
and
everybody
prefers
slack
for
the
most
part,
as
far
as
like
a
way
to
get
a
hold
of
them.
Direct
so
like
in
the
case
of
the
release
team
having
an
issue
they
wouldn't
like
the
baseline
here
would
be.
A
The
release
team
will
need
to
DM
you
on
slack,
and
then
you
have,
you
know
72
hours
to
get
back
to
them
or
something
that
would
be
like
the
SLA
but
cutting
out
some
of
those
very
specific
cases,
especially
in
the
case
for
new
chairs,
who
are
just
getting
used
to
the
ecosystem.
I
think
this
will
be
really
important.
Okay,
I
see
a
track,
come
up,
okay,
so
any
comments,
questions
or
concerns
about,
or
even
like
what?
What
are
we
doing
here?
If
you're
new
to
the
call
for
this.
A
All
right,
that's
awesome,
all
right,
stopping
that
chair
all
right
and
that's
pretty
much
what
what
we've
got
going
on
from
wrapping
up
some
of
the
other
calls
so
again,
just
getting
a
baseline
of
comms
and
SL
A's
and
really
getting
a
baseline
of
what
we
do
is
chairs
and
seeing,
if
there's
any
kind
of
standardization
that
we
could
do
so.
Your
comments
are
definitely
appreciated
on
both
of
those
issues.
B
A
Awesome
alright.
Now
we
are
to
the
main
event
now
I'm
just
kidding
not
the
main
event.
Now
we
do
we're
doing
a
kept
overview
right
now,
Stephen,
if
you
want
to
share
your
screen
to
for
the
for
the
cap
and
Stephens
gonna,
tell
us
a
little
bit
about
what's
going
on
in
that
the
issue
triage
land
as
far
as
this
caps
concern
and
why
you
as
chairs
should
be
interested
in
this.
Take
it.
A
B
Yeah,
okay,
so
so
the
idea
was
essentially,
we
have
a
role
in
the
release.
Team
called
triage
and
bug.
Triage
is
kind
of
a
conflation
of
bug
and
issue
tree
our
issue
and
PR
triage.
So
the
idea
of
this
role
is
throughout
the
cycle.
They
essentially
watch
all
the
PRS
that
are
in
the
milestone
for
kubernetes
kubernetes
and
so
for
this
capital.
Currently,
right
now,
we've
got
nine
seven.
Nine
hundred
and
seventeen
open
pull
requests
and
2093
open
issues
right
and
that's
a
lot
right.
B
You
know,
at
least
from
the
release
team,
we're
bringing
on
in
every
cycle
we're
bringing
on
a
set
of
new
shadows
for
each
of
these
roles,
as
well
as
a
new
lead
for
four
role,
specific
duties,
and
these
people
may
not
necessarily
have
the
appropriate
context
to
be
able
to
to
triage
something
as
a
sake,
wood
right.
So
the
the
thought
process
is
what,
if
we
could,
you
know
make
it
easier
for
you
to
do
that
job
and
we
had
opened
an
issue
somewhere.
B
There's
some
mailing
lists
discussions
going
back
all
the
way
to
2016
I'm
gonna,
open
an
issue,
so
deadlines
are
horrible.
This
email
from
Tim
Hawken
is
pretty
good
around
being
able
to
around
finding
the
time
and
not
being
oversubscribed
to
actually
execute
on
on
doing
triage
or
to
refuse
for
issues
and
PRS
and
there's
also
yes,
this
issue
that
was
open
around
the
kubernetes
kubernetes
triage
workflow
improvements
and
this
kind
of
spun
out
like
we,
we
talked
about
a
lot
of
things.
I
proposed
a
state
machine
for
some
of
the
labels
and
stuff.
B
So
eventually
we
said
hey,
we
need
a
kept
for
this
right
and
that
stalled
out,
because
I
think
that
what
people
have
been
trying
to
do
is
I
think
we've
been
concerned
with
boiling
the
ocean
and
solving
all
of
these
problems
instead
of
trying
to
get
like
one
net
improvement
out
of
this
right.
So
the
like
this
is
a
fairly
long
thread
if
you
want
to
check
that
out,
that's
linked
in
my
Kevin,
so
the
idea
I
state
at
the
beginning
like
this
is
provisional.
The
details
are
intentionally
light.
B
There
are
a
bunch
of
discussions
that
are
already
happening
like
we
want
to
scope
a
single
deliverable
first
rate
so
like
to
figure
out
so
with
regards
to
user
stories,
but
I
dropped.
Some
quick
ones
here,
like
I,
want
to
be
able
to
easily
triage
my
groups
as
a
group
lead
gonna,
be
able
to
easily
change
my
groups,
group
backlog
of
open
issues
and
PRS,
accelerate
merge,
velocity
and
issue
resolution
for
reviewers
and
approvers
I
want
a
simple
system
to
categorize
issues
and
PRS
in
my
purview.
B
So
I
can
prioritize
what
to
review
first
and
as
contributors
I
want
to
be
able
to
submit
issues
or
pr's
and
understand
how
the
community
works
to
address.
The
new
submissions
have
assurance
that
they
will
be
routed
to
the
correct
group
and
have
them
addressed
in
a
timely
manner
and
I
think
that
those
are
all
reasonable
requests.
B
So
the
the
phase
zero
that
we're
proposing
is
to
labels,
write
a
needs,
triage
label
and
the
needs
trio
and
a
lifecycle
ready
label
I,
don't
really
care
what
the
labels
are
called
just
that
we
have
some
first
system
in
place
that
we
can
start
to
tweak
around.
So
the
idea
behind
that
needs
triage
labels.
It
serves
the
same
function
as
the
needs
kind
or
it
would
serve.
It
would
operate
in
the
same
way
that
the
needs
kind
needs
priority
needs.
B
B
That's
being
discussed
rate
are
the
change,
that's
being
discussed,
so
that's
kind
of
a
solved
problem,
but
from
the
issue
side
the
idea
would
be
every
issue
that
comes
in
would
be
labeled
as
needs
triage
right
and
when
you
apply
some
label,
whether
its
life
cycle
ready
triage,
ready,
some
bot
command
that
essentially
remove
you
know
they.
Those
two
labels
would
be
mutually
exclusive
and
applying
the
you
know,
applying
the
spot,
command,
lifecycle,
ready
or
triage
ready
or
whatever
we
want
to
call
it
would
remove
the
needs
triage
label
right
so
from
there.
B
However,
your
cig
works
to
do
stuff.
You
would
do
that
right.
Basically,
we
just
want
to
figure
out.
We
just
want
to
get
you
to
the
point
where
you
can
determine
if
it's
something
someone
in
your
sig
has
touched
already
or
something
that
someone
has
touched
and
appropriately
triage
right
like
this
is
big
work.
This
is
a
little
work,
we're
going
to
do
it
in
119,
or
we
can't
do
this
until
121,
because
blah
blah
blah
blah
blah
right.
B
B
B
G
F
B
B
Okay,
so
okay
yeah,
more
more
ideas.
Why
are
you
do
this?
One
things?
This
is
mostly
a
discussion
point,
because
we
want
to
make
sure
that
whatever
thing
we
put
in
place
works
for
a
large
portion
of
people,
I,
don't
think
we're
gonna
catch
everyone,
but
I
want
to
make
sure
that
it
works
for
a
bunch
of
people
and.
B
A
H
D
I
wonder
the
people
from
the
six
that
are
already
doing
some
triage.
They
will
try
to
understand
how
this
proposal
seat
or
you
know,
yeah
fit
together
with
what
they
are
doing.
That
was
the
reason.
I
was
silent
because
I
was
talking
to
Han.
You
know
we
do.
We've
been
doing
our
thing.
That
I'm
going
to
briefly
explain
it's
not
perfect
I'm
trying
to
see
how.
How
can
we,
for
example,
I'm
pretty
sure
we
have
a
backlog
of
issues
that
are
old
and
that's
why
they
are
there.
D
D
B
D
H
B
B
And
it's
also
for
things
that
may
not
have,
may
not
even
have
a
process
right,
just
give
them
a
starting
point
to
develop
one.
So
what
I
can
do?
There
have
been
comments
on
the
cap.
I
would
like
more
sig,
chairs
and
technical
leads
to
comment
on
the
cap
once
I'll
give
it
a
few
days
or
something,
and
then
I'll
rework
some
of
that,
and
then
maybe
we
can
call
a.
B
F
Sorry
I
just
figured
well,
there
are
a
bunch
of
different
sig
leads
here.
I
guess
my
only
other
thought
is
maybe
it's
kind
of
unclear
whose
responsibility
it
is
to
triage.
Sometimes
maybe
I'm
selfishly
bringing
this
up
as
like
a
horizontal
stick
that
gets
dinged
for
a
lot
of
things
and
oftentimes.
Our
triage
is
that's
not
our
six
responsibility.
F
B
So
yeah,
if
you
look
at
the
I,
mean
the
state
machine
that
I
have
here
is
out
of
date
at
this
point,
but
if
you
check
this
out
and
I
didn't
want
to
redraw
it
until
we
had
more
ideas.
But
if
you
look
at
the
triage
state,
basically
the
entry
criteria,
the
description
is
sig
triage
is.
Let
me
just
share
my
screen.
B
So
say,
triage
is
issued
to
determine
if
it
needs
more
info
should
be
closed
or
moved
to
the
backlog
so
having
the
sig
label
and
needs
triage.
The
human
actions
would
be
needs,
I,
don't
know
if
I
want
to
do
this
needs
info
thing,
whether
or
not
you
close
it.
If
it's
going
into
the
backlog
or
it's
going
into
some
ice
boxy
thing
you
apply
kind
and
priority
right
and
yeah.
This
definitely
needs
to
be
reworked,
but
the
idea
is
that
you
know
at
a
baseline.
Ideally
it
has.
B
It
has
a
sig
and
anyone
I
think
I.
Think
a
decent
chunk
of
contributors
have
enough
context.
You
realize
that
it's
not
there
sig
and
maybe
hand
it
off.
Erin
I
run
into
the
same
thing
with
the
safe
release.
Stuff,
especially
you
know
you
have
the
you
have
the
the
kind
of
the
you
know,
the
intersection
of
the
sig
released
of
the
sig
testing
stuff,
where
you
know
the
the
in
the
blocking
and
informing
jobs
where
like.
B
If
someone
calls
a
failing
test
for
a
job,
that's
a
GCE
job
that
technically
doesn't
really
have
an
owner.
The
default
owner
becomes
sig
release
right,
so
it's
something
that
we
may
not
have
any
context
on,
but
our
people
have
to
poke
at
so
yeah
I
think
the
first
step
is
actually
determining
that
the
it's
in
the
right
Sigmund
then
handing
it
off
if,
if
not,
but
yes,
that
would
remove
the
needs.
That
would
not
remove
the
needs.
Triage
illegal.
A
B
A
A
A
D
D
D
D
Sometimes
it
bubble
up
into
the
Sigma
things
which
is
okay,
but
usually
the
Sigma
things
are
happen
every
two
weeks
and
and
also
they
are
not
the
right
place
to
get
into
you
know
if
you
have
40
or
80
as
we
have
some
weeks
pull
requests.
You
cannot
go
through
in
those
meetings,
so
we
started
with
a
simple
idea
of
getting
together
twice
a
week.
D
Yes,
I
can
give
access
later
to
the
deck
twice
a
week.
30
minutes.
Sometimes
you
need
more,
but
we
don't
go
over
time,
but
sometimes
you
need
less.
We
started
doing
that
internally
and
we
realized
that
this
was
a
huge
value
for
Google
and
last
year
we
opened
it.
So
basically,
what
we
do
is
I
cannot
share
my
screen,
so
I
cannot
do
it
live,
but
you
know
we
had
to
very
and
the
please
don't
laugh
and
I.
D
Think
having
the
kit
and
having
a
process
is
going
to
be
great,
because
I
will
tell
you
what
we
do
so
we
have
as
Barry
Oh
query
like
you
can
open.
One
of
those
like
the
beers
varies.
If
you
want
so
everything
that
is
an
issue
and
it's
open.
Sorry,
it's
not
open.
I
will
explain
later
and
he's
labeling
API
machinery.
So
we
track.
Let's
say
that
last
week
or
last
meeting
we
were
able
to
go
up
to
I,
don't
know
one
of
the
ones
that
are
at
the
bottom,
eight
eight
nine
six
six.
D
So
we
track
that
number
and
then
we
go
through
all
the
ones
that
are
new
since
last
meeting.
Okay,
can
we
go
back
to
the
slide?
Thank
you
so
with
all
through
every
single
one
of
the
pull
requests
on
the
list
since
last
meeting,
and
also
through
every
single
one
of
the
issues
we
read
through
the
details.
D
Sometimes
it
requires
more
attention
like
we
need
to
see
what
files
are
changing.
What
is
the
change
you
will
get
and
I'm
sure
everybody
here
is
familiar
depending
on
you
know.
If
the
person
is
somebody
new
or
everybody
has
a
different
style,
some
people
put
more
details.
It's
super
clear
what
they
are
trying
to
do.
Sometimes
you
need
to
decipher
what
they
are
trying
to
do.
D
So
this
is
what
David
was
saying.
First
of
all,
I
think
we
determine
if
that
is
a
PA
machinery
or
not.
Sometimes
it
is
IPM
actually,
and
it's
also
other
six,
so
we
might
label
all
the
six
to
hoping
that
that
will
bring
it
to
their
attention.
Sometimes
we
because
APA
machinery
said
it's
in
a
special
place
in
difficult
three
set
of
files
that
you
know
are
in
our
folders,
but
are
not
necessarily
ap
machinery.
D
D
D
Can
back,
we
will
take
a
look.
Usually
one
of
the
two
deals
of
the
sea
is
present
in
these
meetings.
So
Tuesdays
we
had
a
bead
Thursday,
we
have
Daniel
and
then
there
is
a
lot
of
other
random
people
from
the
sea,
not
only
from
Google.
You
know
from
different
companies
and
from
the
open
source
in
general
that
participate.
D
Everybody
has
kind
of
a
sense
of
who
is
a
good
person
to
look
at
something
you
know
depending
on
the
area.
So
what
Indian?
We
want
to
make
sure
that
you
know
we
either
CC
people
to
make
them
aware
or
assign
it
to
people,
so
they
can
take
care
of
the
issue.
I
want
to
say
the
last
two
things
and
three
and
four.
We
use
this
opportunity
to
thank
some
issues
as
help
needed
or
a
good
first
issue.
I,
remember
the
exact
wording,
but
we
do
that.
The
retail
is
whiskey.
Cherry
Peaks.
D
We
skip
the
ones
that
are
close.
We
get
a
lot
of
traffic,
usually
in
ATM
machines,
so
we
you
know
we
try
to
optimize.
For
that
and
number
four
is,
since
you
know,
I've
been
more
involving
API
machinery
and
I
become
the
chair.
Some
people
come
and
say
you
know
a
what
can
I
do
to
participate
more
on
the
sea
work
and
I
start
I
always
suggest
you
know.
Come
join
these
meetings.
Just
you
know,
sit
there,
listen
learn
if
you
feel
like
there
is
something
an
issue
or
a
peer.
That
sounds
interesting
to
you.
D
You
know
speak
up
or
send
me
a
message.
I
will
assist,
see
you
on
that
one,
you,
you
can
see
the
progress
you
can
use
it
another
opportunity,
each
other
and
the
last
slide
yeah.
What
else
so
I
think
the
biggest
lesson
learned
and
I
hope
that
and
if
it
would
agree,
is
that
we
make
it
regularly
and
consistently.
D
There
are
weeks
when
we
are
getting
closer
to
code
freeze
when
it
gets
crazy.
We
get
like
you
know
two
full
pages
of
code
request
which
is
like
you
know:
100
pull
request
into
lace
or
something
like
that.
There
is
no
way
that
we
can
have
a
large.
You
know
three-hour
meeting
to
go
through
that
like
every
week
would
be
great,
so
consistency
and
regularity
I
think
pays
off.
That's
great
and
those
are
our
numbers
we
could
be
doing
better.
I
suspect.
D
D
D
D
G
J
D
D
We
I
had
somebody
on
my
team
some
time
ago,
like
two
years
ago,
also
build
an
application
to
see
how
much
we
were
assigning
to
people
to
avoid
overloading
people.
I,
don't
know,
I
think
we
want
to
keep
it
lightweight
and
simple
if
anybody
is
getting
too
much
because
you
know
the
person
that
is
running
the
meeting
doesn't
realize
country,
you
know
it's.
D
G
D
D
D
B
I
really
like
the
idea
of
triage
teams
or
having
triage
events,
I
think
that
I
was
kind
of
failing
to
see
it
until
chatting
on
this
call,
but
like
release,
has
a
set
of
different
triage
teams
right,
so
bug
triage
the
enhancements
team.
All
these
people
that
are
doing
I
mean
it's
a
lot
of
it
as
doing
work
so
that
the
leads
don't
have
to
rate,
and
that
has
worked
out
pretty
well
for
us
at
least
I
mean
you
know
we
have
these.
B
We
have
it
in
place
for
essentially
the
quarter
right.
So
every
milestone
gets
a
new
set
of
people,
so
I'm
trying
to
figure
out
how
to
better
share
that
knowledge
across
milestones,
because
the
like
the
body
of
I
mean
the
body
of
understanding
that
you
build
up
while
learning
how
to
do
triage
for
for
the
enhancements
are
for,
for
bugs
or
for
failing
tests
is,
you
know,
I
think,
is
globally
useful
right
now,
just
a
release,
but
everywhere
I'm
right.
So
this
brown
boy.
D
J
A
All
right:
well
now
we
are
at
the
discussion
phase
of
our
journey.
We
can
stop
reclined
of
don't
want
to
stop.
Recording,
so
do
want
to
ask
some
poignant
questions
to
y'all
that
I
think
others
might
take
value
in,
but
on
the
same
topic
of
triage,
you
know
same
questions
for
you
that
I
asked
Fetty
like
what,
if
would
have
your
groups
tried
that
didn't
work?
What
is
what
are
some
things
that
do
work
for
your
groups,
anything
that
you
want
to
share
with
your
crew
or
maybe
other
open-ended
questions
like
fetty's
question:
hey?
F
I
F
Take
that
as
a
signal
that,
like
somebody,
cares
that
it
stay
open,
but
nobody
cares
enough
to
actually
do
anything
about
it
and
I
feel
like
eventually
that
begins
to
accumulate
a
lot
of
cruft
and
I'm,
not
like,
like
fatty
I'm,
not
entirely
sure
what
to
do
with
it,
because
maybe
sometimes
these
document,
like
known
deficiencies
that
would
be
nice
to
fix,
but
they're,
just
there's
so
low
priority
that
the
history
speaks
for
itself,
that
nobody
has
decided.
It's
high
priority
enough
to
do
anything
about.
D
D
We
can
still
be
nice
and
have
a
discussion
in
the
sig
meeting
about
a
proposal,
and
you
know
decider,
says
see
if
we
want
to
move
forward
or
not
and
see,
you
know
give
people
the
opportunity.
We
had
a
lot
of
those
you
know.
Sometimes
in
the
triage
meetings
there
is
an
issue,
there
is
a
little
bit
progression
or
you
know
it's
divided
the
opinions,
so
maybe
that
one
is
worse
to
us.
D
G
D
B
Yeah
so
I
try
not
to
I'm
trying
to
care
less
about
about
the
things
that
are
stale
or
rotten,
not
to
say
that
they're
not
important
but
like.
If
you
take
something
like
the,
we
have
a
an
issue
that
was
open
by
show
and
March
of
2017
to
move
to
move
containers
out
of
like
Google
containers
right
and
we're
only
now
doing
that
because
I
mean
part
of
it
is
like
we
don't
have
access.
B
We
didn't
have
access
to
do
that
before
and
we
didn't
know
the
shape
of
the
problem
right
so
like
some
things
will
bubble
themselves
back
up,
but
I
spend
more
time
on
triaging
active
issues
and
PRS.
Then
the
and
I
think
it's
more
important
to
triage
the
act
of
PRS
and
and
issues
then
the
the
older
ones.
If
it's
it's,
it's
kind
of
like
the
like.
B
All
of
us
probably
have
insane
inboxes,
and
you
know
if
it's
the
you
know
the
saying
like
if
it's
important,
they're
they'll
email
again
right
like
so
like,
if
it
will
I
think
if
it's
important
to
the
community
or
the
sig
or
the
area
sub
project,
whatever
you
want
to
call
it,
it
will
raise
itself
and
then
it
becomes
something
fresh
that
you
triage
right.
So,
like
I,
try
to
prioritize
the
freshness
of
the
issue
or
the
PR,
as
opposed
to
the
length
of
time.
It's
been
open,
I'm.