►
From YouTube: Kubernetes SIG Architecture 20190425
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
A
C
Hi,
so
in
this
meeting
we
don't
want
to
go
over
the
exact
list
of
things
that
we're
either
broken
or
you
know,
got
patched
in
subsequent
patch
releases
or
things
like
that.
But
we
can
do
that
in
a
subsequent
meeting.
But
right
now,
I
was
trying
to
bring
awareness
to
the
fact
that
they
were
they.
There
are
things
that
are
breaking
in
the
dot
zero
releases,
which
gets
fixed,
and
sometimes
it's
very
hard
to
for
people.
C
What
adopting
the
latest
releases
they'll
have
to
wait
for
a
few
dot
releases
before
things
get
stable
before
it
can
actually
be
used
in
production.
So
this
is
the
anecdotal
evidence
at
this
point,
but
then
I
need
to
kind
of
collect
information
both
from
the
release
teams,
as
well
as
end
users
to
try
to
figure
out.
You
know:
where
are
we
going
around?
C
One
anecdote
that
we
got
was
one
of
the
Prometheus
metric
stuff,
which
was
causing
either
CPU
or
memory
to
be
blown
out
of
proportion
happened
three
times
because
people
from
three
different
SIG's
merge
code
without
realizing
that
it
would
break
so
I,
don't
know
if
sander
is
here,
he
was
the
one
who
brought
that
up
which
triggered
me
to
raise
this
item
here.
So
in
general,
what
do
you
guys?
What
do
you
all
sorry
I
shouldn't
say
guys?
What
do
you
all
think
about
the
issue
here?
Is
this
a
valid
concern?
What
is
your
experience?
E
Since
the
beginning
of
the
project
and
I'm
sure
Jordan
could
probably
speak
at
length
to
this,
to
is
really
smiling
immediately.
Is
that
you
know
anyone
whose
work
downstream
has
never
recommended
Ozzie
release,
because
I
think
this
is
our
part
because
of
our
release
process,
we
don't
actually
release
a
beta
release
and
have
sort
of
signal
coming
in
from
the
wild
before
it
actually
gets
blown
out
to
the
community,
so
our
dot
zero
release
is
is
pretty
much
like
a
big
release.
C
Right
so
the
related
to
this
is
we
do
have
retrospectives,
but
those
are
held
by
sig
release
and
it
covers
only
things
that
were
that
are
of
consequence
to
their
working
and
we
don't
have
retrospectives
either
the
sig
level
or
at
the
overall
project
level.
Is
that
a
good
thing
to
do?
When
do
we
do
it?
Who
needs
to
be
involved
any
thoughts
there?
F
That
I
sort
of
informally
collected
myself
that
I
think
would
be
helpful
to
track
for
all
of
the
changes
that
we
put
back
into
release
branches
just
categorizing
them
like
is
this
fixing
a
regression?
Is
this
something
that
this
release
progressed,
that
we're
fixing,
or
is
this
above
a
bug
fix
that
happens
to
be
severe
enough,
that
we
want
to
push
it
back,
just
not
a
ton
of
really
detailed
information,
but
just
kind
of
flipping
a
bit
in
each
category
like
is
this
a
regression?
Is
this
security
issues?
F
Is
a
bug
fix,
or
is
this
something
else
having
that
information
like
the
retrospectives
are
sometimes
helpful
for
collecting
how
people
feel
about
a
release,
but
actually
having
numbers,
so
we
can
see
which,
where
we
were
dressing,
what
were
those
regressions
centered
around
I
think
that
would
be
helpful.
I
can
I
took
a
stab
at
collecting
some
of
this
by
and
and
I
can
share
that
out,
but
if
we
wanted
to
make
that
part
of
the
cherry-pick
process,
when
you
take
something
back
to
a
previous
release,
you
need
to
explain
like
what
is
this.
F
C
G
The
different
commits,
but
I
looked
at
numbers
of
commits
and
past
releases.
There
were
in
release
branches,
so
I
posted
some
of
those
to
the
chat.
Of
course,
the
most
recent
ones
will
have
fewer
just
because
fewer
bugs
have
been
encountered
pretty
much
the
dot.
One
of
every
release
has
a
few
hundred
already,
which
basically
is
an
indication
that
that
release
is
just
not
done
right,
but
the
way
we
do
our
release
process
where
we
can
neither
move
the
change.
G
So
this
has
been
true
ever
since
we
implemented
this
policy
and
1.3
and
I
think
it's
been
getting
worse
rather
than
better
over
time,
but
you
could
easily
see
that,
just
by
looking
at
every
release
since
1.3,
of
course,
q4
will
always
be
less
just
because
less
goes
into
the
queue
for
release,
and
then
you
know,
I
think
dot.
One
dot
11
is
the
most
recent
release
in
wide
use.
So
I
would
expect
that
to
be
approximately
at
steady
state
now.
G
So
you
know
somewhere,
like
7800
commits,
seems
to
be
where
they
top
out,
but
yeah.
Almost
certainly
a
fair
number
of
those
commits
are
just
loose
ends,
that
of
stuff.
That's
not
done,
then
a
smaller
number
will
be
reported,
bug
fixes
and
then
a
very
small
number
security,
emergency,
CB
e
type
security
patches.
G
I
think
both
make
downgrade
work
and
we
need
to
get
more
diligent
about
what
can
go
into
patches,
and
this
is
why
I'm
a
fan
of
feature,
branches,
I
think
we
need
some
way
to
to
gate
what
goes
into
releases.
Other
projects
have
get
flow
and
other
sorts
of
patterns
where
stuff
that
gets
checked
into
the
development
branch
doesn't
hit
a
release
automatically
like
there
are
multiple
different
ways
to
solve
the
problem.
If
we
don't
like
release
branches,
we
should
find
a
different
way.
G
You
can
push
everything
into
separate
repos
and
you
know
have
some
sort
of
integration
where
we
pin
to
known
working
versions
or
something
there.
There
are
many
ways
to
solve
the
problem.
We
just
need
to
choose
some
set
of
solutions
and
move
towards
that.
If
we're
ever
going
to
change
the
current
situation,
otherwise
people
will
be
using
releases
that
are
a
year
old,
like
anybody
using
it
in
production,
we'll
just
have
to
use
old
releases.
Those
are
the
only
ones
that
have
been
sufficiently
tested.
G
We
look
at
some
other
projects.
You
know
more
test
coverage.
Obviously
you
can
help
as
well
and
I.
Don't
even
know
that
we
know
how
to
credible
information
about
what
our
test
coverage
is,
but
yeah
I
miss
it.
This
is
now
that
we
have
lots
and
lots
of
people
using
kubernetes
in
production.
This
is
increasingly
becoming
a
concern,
and
this
is
where
some
of
the
pressure
for
things
like
LTS
come
from.
So.
E
So
I
just
had
met
a
point
here
is
that
safe
release
be
owning
these
thing
in
general,
like
it's
necessarily
our
view,
we
could
talk
about
a
shirt
but
I
think
this
kind
of
a
responsibility
of
soon
release
to
manage
and
we're
going
to
maintain
this
aspect
and
I
do
think.
That's
it.
Release
has
been
under
staffed
with
the
appropriate
technical
skills
required
to
actually
solve
the
fix
for
some
like
the
time.
So
perhaps
we
can
channel
efforts
towards
making
awareness
of
the
problem
and
trying
to
get
folks
engaged
with
that
particular
sake,
I
mean.
E
H
A
Can
can
I
suggest
just
a
couple
things
before
we
pass
over
Quentin
we've
talked
about
feature
branches
and
I
think
that
would
fall
under
the
code
organization.
Some
project
we
have
here
so
Tim's
is
that
something
you
could
add
to
the
list
of
agenda
items
there,
and
we
can
now
move
that
conversation
there
I'm.
C
D
G
D
You're
saying
we
in
in
just
the
first
patch
release
we
have
a
hundred
and
fifty
commits
over
and
above
what
went
out
in
the
initial
release
for
at
least
a
couple
of
releases
that
I
looked
at.
That
was
the
case.
Yes,
good
lord.
That
is
quite
disturbing
now
the
reason
I've
mentioned
this
was,
if
you
look
at
that,
if
you
look
at
those
numbers
that
you
published
I
mean
I,
guess
the
good
news
is
we're
not
obviously
getting
a
lot
worse.
H
F
D
Well,
what
it's
worth
that
I
had
a
quick
look
at
is
how
many
point
releases
we
have
per
release
and
that
seems
to
vary
between
you
know
kind
of
high
single
digits
and
low
teens,
but
again
doesn't
seem
to
have
a
you
know,
clear
upward
trajectory
which
imply
we're
not
getting
dramatically
worse
unless
that's
covering
up
some
other
badness.
There's.
C
C
So
that's
why
I
was
suggesting
that
we
have
a
separate
meeting
for
that,
just
like
the
retrospective
and
run
by
people
who
run
the
cig,
release
retrospective
and
invite
people
from
the
cigs
and
do
this
periodically
not
not
like
a
one-time
thing.
Try
to
do
this
or
every
release,
that's
what
I
was
going
for
go
ahead.
Jaron
ken
thirsty.
I
So
is
the
vision
to
get
to
a
point
where,
when
we
cut
a
branch
for
release,
the
branch
is
basically
an
RC
and
then
we're
not
expecting
a
large
number
of
commits
to
merge
to
it.
After
that,
like
effectively,
we
expect
that
master
is
stable
almost
to
release
at
that
point,
and
we
cut
the
release
branch
or
is
that
like
out
of
scope.
F
So
I
think
there
are
a
lot
of
different
dimensions
to
this
cig
release
owns
part
of
it.
Sig
testing
owns
part
of
it,
the
individual
SIG's
that
run
the
components
where
we're
seeing
regressions
more
often
own
part
of
it,
and
so
the
best
case
scenario
is
all
of
those
dimensions.
Get
engaged
and
owned.
They're
part
of
the
dimension
of
the
worst
case
scenario
is
all
of
them
say:
oh
well,
there
are
other
dimensions.
F
C
So
can
I
ask
show
of
hands
who
wants
to
work
with
me
on
this,
so
we
can
come
up
with
like
a
spreadsheet
with
some
information
and
then
use
that
to
do
the
next
step
like
setting
up
a
meeting
and
they
talk
about
stuff
quinton.
Can
you
add
your
name
to
the
to
the
agenda
and
say
that
you
are
interested
in
this
anybody
else?
Looking
for
help.
F
C
A
Right,
thank
you.
We
have
three
other
areas.
I,
don't
know.
If
we'll
get
through
them
all
Brian
did
you.
Are
you,
okay,
pushing
the
issue
triage
to
the
end
and
see
how
much
time
we
have
left
for
that
and
if
not,
we
can
push
it
to
next
time.
Yes,
okay!
Thank
you.
The
next
section
we
have
is
actually
sub
project
updates,
I'm,
hoping
that
these
will
be
much
quicker
than
last
week
where
we
went
into
depth.
F
We
got
the
request
out
to
siblings,
to
start
identifying
people
and
there's
things
we're
gonna
be
participating
and
about
half
of
them
have
pointed
up
people
which
is
great,
as
we
run
into
requests
for
other
areas,
we're
reaching
out
to
the
ones
who
have
not
given
those
names
individually.
So
we
make
sure
to
get
them
engaged
a
few
specific
areas.
We've
broken
out
discussions,
so
I
met
with
some
of
the
folks
from
single
windows
yesterday,
talking
about
their
run
as
user
name,
identity
needs
around
pods
and
then
I
know.
F
Tim
and
Clayton
met
with
some
of
the
cluster
life
cycle.
Cluster
API
machine
API
people
yesterday
I
think
yesterday
to
walk
through
some
of
their
initial
box.
So
yeah.
If
you
want
to
see
the
latest
date,
look
at
the
project
board.
If
there's
something
that
is
not
getting
attention,
take
a
look
at
the
board
to
see
if
it's
even
on
anybody's
radar
and
if
not
feel
free
to
ping
me
and
we
can
make
sure
it
gets
routed
to
someone.
So
you
can
see
where
it
isn't.
You.
E
It's
delightfully
kind
of
a
boring
update.
We've
been
trucking
along
very
steadily
yeah.
We
making
good
progress
I
believe
we
had
like
11
approvals
last
round.
We
should
have
big
good
progress
by
the
next
time
too,
as
well.
I
do
have
a
issue
that
I
would
like
to
bring
up
to
sick
arch
for
clarification.
There's
two
guiding
issues
that
exists
inside
of
the
main
conformance
doc
and
I.
Don't
think,
there's
ambiguity
with
regards
to
I
think
there's
a
little
bit
of
a
duty
with
regards
to
people's
understanding
there
and
what
actions
they
can
take.
E
Specific
events
are
generated
as
we
make
no
guarantees
for
an
offense
and
the
second
one
is
they
say
that
checks
optional,
conditional
fields
such
as
reason
or
message
there
I
understand
the
reasoning
behind
that,
but
people
are
confused
by
what
they
need
to
do
or
how
they
can
go
about
doing
concrete
examples
that
showed
better
usage.
This.
G
E
Or
shows
concrete
examples
of
how
people
can
make
a
change.
That's
positive!
That
removes
that,
because
it's
difficult,
because
there's
a
lot
of
implicit
state
built
into
the
system
versus
explicit
state
machine.
So
at
a
lot
of
the
tests,
if
you
actually
do
a
crock
of
the
entire
test,
suite
there's
on
the
order
of
hundreds
of
tests
that
fell
into
that
category,.
G
C
C
So
that
was
the
main
update
from
me.
We've
been
chugging
along
on
a
few
things
and
including
a
change
to
HCB.
To
remove
the
I,
don't
know
how
to
say
it.
The
you
gorgey
package
which
we
removed
from
KK.
We
wanted
to
do
the
same
thing
in
HCD
that
went
through
you
know
it's
merged
in
master,
I've
done
a
back
boat
and
that's
gonna
go
in
next
and
then
we
gonna
cherry-pick
that
back
and
see
what
gains
we
get
Jordan
did
you
have
something
some
other
things
to
cover.
F
That's
a
good
example
of
the
kind
of
gridlock
that
we're
in
and
so
recognizing
that
and
asking
for
sort
of
more
creative
ways
to
bring
in
those
fixes.
So
the
azure
cloud
provider,
maintainer
x',
were
able
to
cut
patch
releases
on
older
tags
that
hold
in
just
the
fixes
they
need
needed.
So
that
was
great
that
they
were
able
to
do
that.
F
I
think
as
we
are
making
progress
towards
getting
those
things
out
of
tree,
asking
people
to
be
careful
about
huge,
sweeping
changes
and
make
targeted
changes
where
possible,
knowing
that,
like
six
nine
months
down
the
road,
hopefully
a
lot
of
these
big
dependencies
will
be
out
completely.
So
it's
great
that
they
were
able
to
do
that.
We
just
encourage
all
dependency
to
be
sensitive,
that
and
look
for
ways
to
avoid
huge
sweeping
changes.
If
we
can
right.
C
D
I
had
one
brief
question
actually
to
the
group.
So
topic
came
up
in
like
a
code
organization,
discussion
I
believe
it
was
Clayton
who
mentioned
that
we
should,
you
know,
have
some
guiding
principles
around
how
we
reorganize
code,
where
we
reorganize
it.
So
we've
actually
got
concrete,
measurable
improvements
and
I
sort
of
implicitly
signed
up
to
kind
of
potentially
write.
Such
a
document
I
gave
it
some
thought
this
week
and
occurred
to
me
that
it
has
some
overlaps
on.
D
So
what
I'm
thinking
is
that
something
like
a
very
brief
as
brief
as
possible
kind
of
a
constitution
things
we
believe
to
be
true
and
that
we
sort
of
strive
for
with
code
organization
and
I?
Guess
it's
going
to
the
left
to
some
extent
into
architecture
and
even
possibly
releases
so
that
there's
such
a
document
sound
useful
and-
and
is
there
already
such
a
document
that
sounded
like
it
wasn't
one
in
which
case
I'm
happy
to
kind
of
crawl,
a
few
people
together
and
cobble
something
together?
F
C
F
G
I
think
there
are
an
approach
that
would
make
sense
to
me
there's.
Certainly
multiple
approaches
would
be
to
write
up
some
kind
of
user
journeys
of
things.
We
expect
people
to
be
able
to
do
without
extreme
pain
in
terms
of
how
they
utilize
our
code
from
the
different
personas
contributors
to
specific
components.
G
D
That's
a
good
idea,
it
did
occur
to
me
in
this
kind
of
two
different
directions.
One
can
take,
one
is
to
say
these
are
the
things
we
believe
to
be
true,
because
you
know
we
probably
all
thought
you
have
a
bunch
of
opinions
like
that
and
associated
with
each
one,
explain
why
we
think
this
is
a
good
thing,
or
this
is
a
bad
thing
and
the
other
one
is
to
start
with.
C
D
Not
I
totally
agree,
I.
Think
I
think
it's
useful
to
to
just
put
down
what
we
believe
to
be
true
on
a
piece
of
paper
so
that
we
can
actually
either
agree
on
some
of
the
items
or
disagree
on
them.
And
if
we
disagree
on
them
we
can
delete
them
because
I
think
some
of
the
you
know
we
end
up
reorganizing
code
and
and
and
the
reason
we
have
debates
about
where
the
code
should
be
or
how
it
should
be
organized
is
because
we
haven't
even
agreed
on.
D
You
know
what
we
believe
to
be
true,
so
that
was
sort
of
my
thinking
behind
it.
If
we
can
at
least
agree
on
what
we
on
the
Constitution,
then
you
know
the
legal
framework
falls
out
of
that,
as
opposed
to
the
other
way
around
all
right,
it
sounds
like
people
think
it
might
be
useful,
I'll,
try
and
bear
something
together.
A
Right,
the
next
topic
we
have
in
the
agenda
is
something
that
showed
up
on
the
mailing
list,
but
I
don't
know
that
there
are
any
responses
to
it.
It's
brought
to
us
by
cig
scheduling
its
how
to
host
a
process.
That's
our
project,
that's
crossed
sig.
The
example
here
is
coup
batch,
which
they're
renaming
to
volcano
or
calling
it
that
now
and
so
do
we
have
somebody
on
to
talk
about
that.
Yeah.
C
A
In
our
stance,
because
we
discussed
this-
the
the
two
six
or
six
scheduling
and
see
gaps,
and
so
we
discussed
this
in
Monday's
meeting
of
say,
gaps
and
the
whole
idea
was.
We
were
okay
with
sig
scheduling,
owning
this,
and
if
we
felt
the
need,
we
would
engage
with
the
project.
Our
folks
would
go
be
in
the
owners
file
and
engage
on
it.
If
that
was
a
case,
and
so
we
are
okay
with
sig
scheduling,
owning
the
sub-project
yeah.
I
As
when
an
event
like
well
matt
said
we
don't
have
any
developers
and
sig
apps
were
in
the
owners
files
for
the
batch
stuff
or
for
volcano
and
we're
very
supportive
of
them
doing
the
project
at
best.
They
want
to
do
and
we'd
love
to
collaborate
with
them
if
they
win
or
not,
but
we're
not
really
:
or
somebody.
At
this
point,
the.
G
C
Right
there
are
a
few
aspects
to
it
like
it's
not
for
use
by
other
P:
it's
not
code
that
is
directly
imported
by
other
projects.
It's
beyond
the
scope
of
the
six
scheduling
as
such
then
signal
they
were
talking
about
singularity
so
that
so
Oh
it
just
mushroomed
into
a
point
where
we
said
this
seems
like
something
that
needs
to
go
in
the
CNC
F
level.
So
can
you
please
explore?
That
was
one
of
the
suggestions
that
came
out
of
the
meeting
yesterday
anyway.
D
No
I
think
that's
about
it.
I
think
it's
safe
to
say.
Without
wanting
to
preempt
anything
I
think
it's
I've
said
that
the
inclination
is
to
move
it
into
the
ciencia,
that
that
seemed
like
the
preference
of
the
steering
committee,
and
it
seems
like
the
most
practical
thing
that
the
reason
we
didn't
do
that
initially
was
because
the
stuff
is
all
fundamentally
changes
to
the
core
of
kubernetes.
So
it
seemed
like
it
belongs
in
kubernetes.
D
It's
not
something
built
on
top
of
communities
or
rounded
or
plugging
in
the
side.
It's
kind
of
like
fundamental
changes,
I
mean,
admittedly
using
using
our
extensibility
mechanisms,
but
it
is,
it
is
fundamentally
changing
or
building
new
schedulers
building
new
container
runtime
interfaces,
potentially
building
new
cubelets
building
new
job
abstractions.
You
know
some
of
the
fundamental
workload
abstractions
of
kubernetes,
so
it
sort
of
tastes
a
little
different
than
something
like
helm,
which
is,
you
know
clearly
built
on
top
of
communities.
D
But
the
steering
committee
seem
to
feel
that
that
didn't
mean
that
it
shouldn't
go
into
the
C&C
F,
so
we're
gonna
explore
that
and
the
other
option
is
to
you
know,
put
a
cap
together
and
sort
of
a
different
process
to
say
how
could
we
accommodate
this
in
a
practical
fashion
inside
the
kubernetes,
org
or
SIG's?
You
know,
structure
and,
and
so
those
are
the
two
things
on
the
table
and
we'll
figure
out,
which
one
looks
the
best.
I
There
is
another
alternative
and
I
know
you've
considered
in
orbit
even
attracted
to
you,
but
if
you
look
at
Kuby
flow,
for
example,
they're
not
quite
at
the
point
where
they're
implementing
their
own
container
runtimes,
but
they
do
implement
a
lot
of
different
abstractions.
They
leverage
a
lot
of
different
other
things
in
the
community.
They
built
their
own
kind
of
just
project
and
process
outside
of
kubernetes,
even
though
they
layer
on
top
of
it
so
I
mean
you
can
go
onto
the
CNC
at,
but
there's
nothing.
There's
no
need
to
actually
do
that.
D
That
is
true,
I
mean
we
do,
need
it
to
be
in
a
foundation
and
to
be
a
sort
of
multi
company
effort
and
and
to
be
clear,
I
mean
cube.
Flow
actually
runs
on
top
of
part
of
volcano
at
the
moment,
which
is
called
cube
bachelor.
So
there's
a
lot
of
overlap
there,
but
yeah
there
is
a
preference
to
have
it.
You
know
housed
somewhere
in
in
a
foundation
like
the
CN
CF
seems
to
be
I
mean,
given
that
it's
essentially
changes
to
kubernetes.
D
A
G
I
can't
share
my
screen,
though,
but
just
start
talking
so
number
of
the
six
are
starting
to
do
more
issue
triage
during
meeting.
So
it
was
suggested
that
we
do
that
in
Sagarika
sure
is
well
to
try
to
usually
crowdsource
the
curation
of
our
backlog,
and
that
sounded
like
a
good
idea
to
me.
So
most
sig
arch
issues
are
in
just
two
repos.
G
But
still
you
know
there
are
significant
number
ones
in
communities,
communities,
47,
open
issues,
taxing
architecture
right
now,
Sukie
the
community
repo,
where
some
of
the
project
contributor
documentation,
lids
and
enhancements
repo,
which
is
where
caps
are
so
I
thought
we
just
go
through
Rubin,
think
ranae's
and
the
community
rebo
quickly.
The
general
triage
approach
that
I
use
not
just
for
cigar
cutter
but
generally,
is
to
winnow
down
the
set
of
issues
that
need
to
be
addressed
right
now.
G
So
the
first
cut
is,
is
cig
architecture,
the
right
categorization
of
the
issue,
or
that
should
have
really
belonged
to
differencing
or
set
of
things
so
that,
as
a
first
determination,
tane
really
cigar
cutter
is
about
you
know,
trading
the
processes
and
policies
that
enable
all
the
other
SIG's
to
do
the
right
thing
and
in
self-aligned.
So
it's
really.
The
generalization
of
issues
that
come
up
that
are
should
predominantly
fall
just
in
architecture.
G
So
if
it
is
something
just
just
affects
one
specific
technical
area
of
the
project
like
networking
or
storage,
then
it
probably
doesn't
belong
in
a
cigar
structure.
In
the
next
consideration.
To
make
is
how
important
or
urgent
is
the
issue,
because
it's
not
important
or
urgent,
then
we
can
come
back
to
it
later.
So
you
know
we
have
some
priority
labels
that
we
don't
use
consistently
or
rigorously
across
the
project
and
they're
hard
to
maintain
much
like
health
wanted
labels,
and
things
like
that.
G
G
Well,
so
anyway,
yeah
you
can
people
who
are
maintainer
x'
can
just
still
change
labels
until
that
goes
away,
but
also
the
box
fans
just
be
aware
that
if
you
use
a
bot
commands
to
categorize
or
prioritize
or
a
sign,
you'll
get
subscribed
to
the
issue
and
that's
a
pain
point
for
me.
I,
don't
know
how
much
of
a
being
weighted
is
for
other
people.
So
then
also
remember
to
go
unsubscribe.
G
If
you
don't
actually
want
to
follow
that
as
you're
going
forward
having
the
right
set
of
people
monitor
comments
to
issues
like
updated
questions
or
blood
reports
from
users
is
an
unsolved
problem
in
the
projects
and
with
github
generally
I
would
say
so
like
if
any
individual
touches
an
issue
at
any
time
in
the
past,
the
updates
will
go
to
them
and
if
new
people
logically
become
the
owners,
they
don't
get
automatically
get
at
it.
So
you
know
even
give
teams
don't
really
solve
this
problem.
G
So
the
only
way
it
really
works
is
some
sort
of
polling
and
can
go
look
at
issues
occasionally
that
you
feel
are
important.
Given
the
number
of
issues
you
have,
that's
not
very
feasible
so
anyway,
siga
architecture
itself,
luckily
doesn't
have
that
many
of
the
third
is,
if
it
is
important
or
sufficiently
urgent,
then
try
to
find
someone
to
assign
to
you.
G
So
if
we
go
and
look
through
the
set
of
issues
right
now,
there
are
some
recent
ones
that,
for
example,
our
code
organizations.
So
this
is
where
we
have
it
also
a
an
effort
to
what
we
call
formalized
sub
projects
and
plum
stuff
projects
through
all
of
our
machinery.
We
really
need
per
self
project
labels
in
the
past.
Originally
we
had
well
not
originally,
but
it's
on
point.
G
The
past
I
created
a
bunch
of
these
area,
labels
now
and
probably
be
more
appropriate
to
have
some
project
labels,
so
that
is
something
we
still
need
to
do.
If
someone
is
interested
in
helping
contributor
experience
implement
that
that
would
be
awesome,
otherwise
Erin
will
probably
end
up
doing
it
wearing
one
of
his
mini
hats,
but
it'd
be
great.
If
someone
else
stepped
up
to
help
with
that,
so
the
first
issue
I'm
looking
at,
is
this
inconsistency
of
imports
to
corby
one
package
I
just
from
reading
the
title.
I
would
guess
that
that
is
navy.
G
You
know
so
sometimes
it
takes
some
context
to
read
through
the
issue
and
understand
what
it
is.
I
would
just
say,
don't
be
afraid
to
ask
others
for
advice
or
to
punt
it
to
someone
else
were
in
fact
just
to
skip
it
and
don't
assign
a
priority
if
you're,
not
sure
and
and
someone
else
can
come
up
with
it.
On
the
past
on
the
next
pass.
G
G
I
Of
the
large
problems
is
it
we
are
we're
a
multilingual
community
so
for
a
lot
of
people
who
are
contributing,
I
see
this
particular
gasps
you're
contributing
English
is
not
necessarily
their
first
language.
So,
looking
at
the
issue,
title
isn't
necessarily
like
it's
not
going
to
be
enough
in
very
many
cases,
and
I
can.
G
So
this
is
pointing
out
another
problem
with
our
automation,
which
is
one
thing
you
can
do.
If
you
are,
if
you
have
write
access
to
the
repo,
is
you
can
edit
the
title?
I
don't
believe
we
have
a
box
man
for
that,
but
that
would
be
really
great
is
to
have
a
chance
or
this
whoever
does
read
the
issue
or
PR
and
figure
out
what
it's
really
about
can
actually
fix
the
title,
so
other
people
don't
have
to
go
through
that
same
process.
G
F
G
G
Like
in
ideal
cases,
you
would
be
able
to
even
categorize
whether
it's
a
feature
or
a
bug
or
something
else
from
the
title
like
this
enhanced
Kellogg,
to
split
up
log
files
when
it
grows
to
128
gigabytes,
I
can
read
that
that's
a
pretty
good
title,
I
can
read
done
so
yeah.
It
probably
has
a
reasonable
categorization
or
network
internet
tests
for
pod
tales
on
Azure
kind,
Kaling
test
yeah.
That's
probably
you
know
thinking
about
that.
Well,
why
does
that
have
a
cig
architecture
label?
G
So
you
can
get
some
of
these.
If
you
do
the
triage
enough,
you
can
get
see
these
kinds
of
patterns
where
you
can
figure
out
what
likely
action
you're
going
to
need
to
take
for
that
issue
like
for
this
one,
probably
reducing
the
set
SIG's
associated
with
that
you
know
if
everybody's
responsible
then
nobody's
responsible,
so
that
would
probably
be
the
action
to
take.
There
probably
say
architectures
tagged
because
you
know
if
it's
a
conformance
test,
for
example.
G
Ideally,
you
would
say
that
in
the
title
but
afterward
conformance
test,
then
it
might
be
questioning
whether
this
is
a
reasonable
thing
to
test.
In
conformance
we
actually
do
have
a
conformance
label,
and
that's
not
on
this.
So
I
don't
know
that
that
is
the
issue,
so
this
is
probably
clicked
ad
enough.
That
I
would
probably
open
it.
Learning
my
conformance
hat
and
go
figure
out
if
that's
related
and
if
it's
not
really
cigar
fish
are
losing
architecture
and
any
other
things.
G
You
know
something
like
moving
master/slave
architecture
to
peer-to-peer.
That
sounds
like
it's
a
radical
we
are
tech.
Chure
I
would
put
that
at
lowest
priority
and
move
on
because,
practically
speaking,
that's
not
yeah,
that's
not
happening
or
I
would
just
close
it.
You
know.
Thank
you
for
your
suggestion.
Build
your
own
system.
G
G
G
C
C
I
G
J
Too
many
new
buttons
control
box
is
actually
in
the
middle
of
doing
this
exact
thing
right
now.
There's
a
PRN
flight
I'll
put
it
in
the
chat
to
create
some
issue,
triage
guidelines
for
us,
but
they're
also
like
issue
triage
guidelines
are
usually
pretty
general.
There
might
be
some
extra
like
specific
ones
add
in
there.
J
If
you
have
comments,
please
like
respond
on
the
PR,
and
hopefully
we
can
get
something
that
is
maybe
general
across
all
the
things
and
then
like
architecture
and
any
others,
things
that
have
specific
extra
things
that
they
want
to
add
for
further
issues.
We
can
get
it
together
in
a
and
the
common
guide.
H
Can
I
actually
disagree
with
Consensus
I?
Think
it's
not
good
to
have
a
few
silent
people
go
off
and
do
your
triage,
I
think
doing
a
group
triage
is
a
great
way
for
newcomers
to
your
space,
to
learn
the
scope
of
your
city
or
project
or
whatever
it's
a
good
training
exercise
and
and
even
if,
even
if,
it's
still
like
a
couple
of
senior
people
doing
most
providing
most
of
the
input
to
the
meeting
like
it's
good
for
everybody
else
to
observe
their
thoughts.
She
directed.
C
J
I'd
also
add
that
it
may
not
be
mutually
exclusive,
like
you
could
do
both
like
have
if
you
record
a
triage
session
with
the
logic
from
the
senior
folks
in
the
groups.
I
can
say
like
oh,
this
is
why
we're
deciding
this
goes
here,
and
this
is
why
we're
fighting
us
goes
here
and
then
have
a
mechanism
to
like
train
and
mentor
new
people
into
that
as
well.
C
A
F
A
F
What
this
is
kind
of
orthogonal,
something
we
found
helpful
and
some
of
the
other
thing
is
just
kind
of
looking
at
each
dimension.
Like
is
categorizing
what
kind
it
is
separately
from
priority,
and
sometimes
it's
easier
to
do
that.
So,
like
have
a
query
that
says,
show
me
everything
that
doesn't
isn't
categorized
at
all
and
just
put
it
in
a
bucket,
like
don't
think
about
priority.
B
Time,
yeah
so
I
I'm
that
topic
I
opened
an
issue
with
contraband
and
a
half
ago,
ish
about
adding
a
new
label
that
comes
in
to
all
issues.
My
default
is
set
basically
saying
triage
needed
or
say
gak
required
or
something
there
wasn't
debate
about
what
this
semantics
really
was.
As
far
as
I
know,
there
was
general
agreement
that
we
can
do
that.
I,
don't
think
it's
actually
been
done,
but
like
I
need
this
in
Signet
work
too
so
I
can
keep
track,
of
which
of
the
hundreds
of
backlog.
B
G
A
G
No,
not
really
other
than
you
know
we're
trying
to
get
the
sig
arch
to
be
more
productive
and
effective.
So
getting
her
act
together
with
the
issue.
Triage
is
yet
and
another
step
there.
If
you
have
other
thoughts
about
improving
execution
of
the
sig,
definitely
offer
up
your
ideas
either
on
the
email
list
or
in
the
future
meeting.