►
From YouTube: [SIG ContribEx] Weekly Meeting for 20230118
Description
[SIG ContribEx] Weekly Meeting for 20230118
A
A
As
a
reminder,
we
do
have
a
code
of
conduct
that
we
abide
by
which
generally
says
to
be
respectful
of
your
fellow
attendees
and
the
speakers
and
generally
be
excellent
to
each
other,
and
so
first
off
we
already
mentioned,
we've
got
a
note.
Taker
wonderful
and
looks
like
folks
have
mostly
added
themselves
to
the
attendee
list
before
we
dive
into
our
topics.
B
C
B
Course,
yeah
actually
I'm,
not
new
for
the
sick
dogs
and
seek
contributor
Summit
staff
events,
but
for
the
experience
actually
I
have
not
here
for
a
while
and
last
year,
I
was
there
for
during
the
Valencia
conference,
preparation,
I
hope.
You
remember
me
yeah.
B
Yeah,
so
I
was
not
here
for
a
while,
so
again,
I
coming
back
with
the
back
so.
D
B
Hope
to
contribute
for
the
community
and
help
and
learn
the
things
and
that's
what
not
yeah.
D
D
E
D
To
the
community
I'm
still
getting
familiar
with
the
Community
six
meetings,
I
am
first
time
attending
a
meeting
and
I'm
still
learning
about
what
community
is
and
mostly
about
dating
stuff
in
CNC,
closed
glossary
type,
kubernetes,
kubernetes
stuff.
Sorry
for
my
English
I
am
perfect.
D
A
A
All
right,
if
you'd
like
to
hop
in
at
any
time
to
introduce
yourself
just
let
us
know
and
you're,
also
welcome
to
do
so
in
the
chat
since
we
do
have
a
couple
of
newish
folks
on
at
least
I'll.
Do
a
little
reminder
here
that
we
are
the
special
interest
group
for
contributor
experience
and
please
excuse
the
cat
if
she
pops
into
frame
so
as
the
special
interest
group
for
contributor
experience.
A
A
lot
of
our
work
focuses
around
the
contributors
who
make
kubernetes
what
it
is
and
making
sure
that
they
have
a
good
experience
being
part
of
the
project
that
they
have
the
resources
that
they
need
to
support
them
all
of
that
kind
of
stuff.
So
we'll
go
for
a
variety
of
Topics
in
this
meeting,
a
variety
of
projects
that
we
do
in
order
to
support
our
contributors
and
with
that,
let's
dive
in
we
have
an
opening
topic
from
Tim.
All
clear.
Would
you
like
to
tell
us
about
it.
G
Yes,
thanks
hello,
I'm
Tim,
all
Claire,
not
new
to
the
kubernetes
community,
I've
been
working
on
kubernetes
since
2015,
but
haven't
spent
too
much
time
in
a
contributor
experience
so
happy
to
be
here.
G
Yeah,
so
there's
been
a
kind
of
a
conversation
going
on
for
a
while,
where
people
are
dissatisfied
with
the
way
our
triage,
Bots
Mark
issues
and
PRS
as
stale
raw
in
and
eventually
close
them,
I
think
the
the
number
one
complaint
that
I
hear
from
contributors
is
that
it's
too
frequent
and
that
it
ends
up
kind
of
spamming
people's
inboxes
I
know
personally,
when
I
go
through
my
GitHub
notifications,
especially
issue
notifications.
G
F
G
And
rotten
so
that
was
kind
of
the
the
primary
motivation
of
this
PR.
Actually,
let's
see
yeah,
so
don't
yeah.
So
I
guess
that's
that's
the
primary
thing.
We're
looking
to
fix!
There's
also
some
discussion
about
whether
Auto
closing
is
the
right
thing
to
do.
At
all.
I
know:
Ben
Elder
made
a
change
I
think
late
last
year
to
stop
Auto
closing
help
wanted
and
good
first
issue
issues
so
but
yeah.
G
This
is
mostly
focused
on
just
changing
the
the
the
time
to
Mark
things
as
rotten.
So
with
that,
the
changes
that
I'm
proposing
are
one
is
to
kind
of
use
the
existing
triage
tags
that
we
have,
and
so
with
this
change.
If
an
issue
has
already
been
triaged
by
maintainers,
and
so
it
has
that
label
I
can't
remember
exactly
what
it
is,
but
triage
accepted.
G
I
think
it
is
so
if
it
has
that
label
on
it,
then
we
don't
ever
Mark
the
issue
as
stale
or
rotten
or
Auto
close
I
can't
remember
if
I
made
that
change,
but
if
it's
not
marked
raw
and
it
won't
Auto
close.
G
So
that's
that's
kind
of
the
first
change.
That's
the
biggest
one
is
to
kind
of
stop
tree
Auto
triaging
those
triaged
things.
G
The
second
piece
is
to
actually
unmark
tree
things
as
being
triaged
after
one
year,
so
this
is
a
much
longer
timeline
than
the
three
months
to
Mark
as
stale,
and
this
makes
TR
the
triaged
step,
essentially
the
first
part
of
the
life
cycle,
and
it
also
does
force
maintainers
to
look
at
issues
and
kind
of
confirm
if
it's
something
that
is
still
needed
after
one
year
and
then
yeah.
G
The
third
piece
is
just
removing
a
workflow
that
was
redundant
after
this
change
and
then
in
response
to
some
comments
from
Sergey
I
reverted
the
changes
or
I
separated
out
the
pr
workflow.
G
I
G
Those
are
the
changes
that
I
was
proposing
with
that.
Any
questions
comments.
A
A
Group
has
been
talking
a
lot
about
using
tags
to
keep
track
of
of
issues.
So
I
think
these
are
some
interesting
changes.
J
D
J
G
No
I
think,
based
on
our
experience,
30
days
to
stale
felt
too
fast,
absolutely
yeah.
We
could
double
that,
but
I
felt
like
going
all
the
way
to
a
year.
I
think
a
lot
of
issues
are
still
are
still
relevant
after
a
single
release
cycle,
which
is
now
approximately
four
months,
and
so
this
says,
like
you
know,
if
it's
been
open
across
three
release,
Cycles.
G
G
K
K
Like
I'm
I'm,
all
for
it,
I
haven't
really
taken
a
look
at
the
pr
itself,
but
most
of
the
repos
outside
of
KK
don't
use
the
triage
labels.
K
So
the
main
thing
is,
we
just
have
to
make
sure
that
it
is
configurable
on
a
per
repo
basis
and
not
being
applied
uniformly
to
I'm
twinkling
of
the
name
of
the
component
in
Pro.
G
If
a
repo
is
not
using
the
triage
labels,
then
they
will
have
the
existing
experience
unchanged.
Okay,.
K
Someone
else
actually
recently
I'm
trying
to
find
the
issue
proposed.
Some
other
potential
changes
to
how
we
triage
things
of
the
life
of
me.
I
can't
find
it.
K
G
Yeah
I
had
seen
this
again
it's
an
interesting
proposal,
but
yeah
I
agree
that
I
don't
think
that
it
has
any
conflicts
with
the
changes
that
I'm
using.
J
K
But
well
I'm,
just
saying
like
if,
like
you
know,
we
I,
like
Tim
I'd,
bump
your
thread
on
the
list
for
another
chance
for
people
to
comment
just
because
December
was
kind
of
like
the
yeah.
K
K
G
I
think
it
won't
have
any
immediate
effects
because
of
the
so
if
there,
if
it's
untriaged
the
behavior
is
the
same.
If
it
is
a
triaged
issue,
then
it
would
only
get
marked
unmarked
triage
if
it
didn't
have
any
activity
for
a
year,
but
it
would
have
been
marked
as
stale
in
less
than
a
year
which
counts
as
activity,
so
that
wouldn't
happen.
I.
D
G
It
might
affect
it
might
cause
some
I
suppose
it
could
cause
some
life
cycle,
Frozen
triaged
issues
to
get
untriaged,
but.
K
Even
if,
if
life
cycle
Frozen
is
on
it
and
the
trash
label
potentially
bumps
off,
it's
not
necessarily
a
problem
to
go
revisit
the
Frozen
issues,
because
we
still
have
some
from
like
2016
that
aren't
really
I
think
we
actually
went
through
and
closed
them.
But
we
had
some
as
of
like
last
year
from
like
2015
2016,
that
weren't
really
relevant
anymore.
H
My
my
only
thought
is,
if
we
did
it
in
the
middle
of
a
release
cycle,
if
anyone
happens
to
be
mentally
relying
on
that
beep,
the
same
way
that
I
mentally
rely
on
the
fact
that
my
microwave
beeps
every
single
minute
after
it's
already
done,
if
that
affects
anybody's
workflow
in
the
middle
of
a
release
cycle
that
could
potentially
affect
something
that
gets
done.
Yeah.
But
that's
a.
L
There
is
a
comment
from
someone
who
couldn't
join
the
meeting.
Sergey
cannot
join
the
meeting,
maybe
differentiate
By
Priority,
going
back
to
issues
seeming
relevant
through
release
Cycles,
it's
not
ideal
to
keep
priority
slash
importance
soon
untouched
for
a
year
those
either
need
to
be
closed
or
re-prioritized
as
a
backlog,
not
sure
how
priority
law
important
long
term
should
be
treated
just
a
comment
that
clearly
watching
the
agenda
as
we
go
through,
but
left
a
note.
G
Yeah
it's
an
interesting
idea,
so
I
guess
with
what
Sergey
is
proposing.
Then
maybe
after
three
months
or
so,
we
un
triage
important,
soon
issues
yeah.
K
G
One
thing
that's
important
to
remember
is
that
this,
this
issue,
commenter
bot,
is
just
using
a
GitHub
query,
and
so
you
can
make
these
same
queries
yourself.
Just
in
the
like,
you
know,
issue
search
field,
so,
for
instance,
if
you
wanted
to
see
like
show
me
issues
that
are
marked
important
soon,
that
haven't
been
touched
in
the
last
90
days.
G
It
should
be
possible
to
do
that.
Yeah.
K
For
what
like
I
I,
don't
think
going
back
to
the
beep
question,
I,
don't
think
many
people
are
relying
on
the
beep.
In
fact,
most
people
actually
have
rules
to
ignore
the
beef.
The.
K
Yeah,
the
only
thing
I
could
I
could
really
think
of
would
be
people
potentially
having
their
own
search
workflows.
Looking
for
when
stale
and
all
that
is
applied,
like
oh
I-
need
to
look
at
this,
but
there
are
other
alternatives
for
getting
that
sort
of
information
too.
So
that's
not
necessarily
A
like
I
would
not
consider
it.
A
blocker
in
general
I'm
support,
I'm
I'm,
a
plus
one
for
the
idea
and
can
comment
on
the
issue.
K
G
Yeah
I'm
happy
to
bump
the
thread
and
I'll
continue
discussing
with
Sergey
on
the
pr
comments.
K
I
I
So
having
that
documented
I,
think
sergey's
comment
makes
a
lot
of
sense,
so
at
least
for
priority
importance
soon.
It
should
be
excluded,
in
my
opinion
and
then
re-prioritize
back
to
backlog,
which
is
then
in
the
same
cycle
as
the
current
proposed
change.
I'll
put
this
up
on
the
on
the
pr
as
well,
so
that
it's
not
lost
in
discussion
but
like
while
everyone's
here,
okay,
the.
K
The
one
thing
I'll
say
like
there's
what
the
description
says
it
should
be
and
what
people
actually
do
and
and
those
tend
to
be
very
different
with
the
most
of
the
priority
things
just
being
the
like,
the
the
what
you
call
it.
One
needs
to
get
resolved
right
now,.
I
Oh
yeah
for
sure,
but
important
soon
and
critical.
Urgent
are
two
things
which
yeah
or
at
least
I've,
seen
like
there's.
No
there's
no
drift
in
the
meaning
of
those
okay.
A
If
we
wanted
to
try
to
popularize
a
interpretation
of
something,
we
may
have
a
sub-project
that
could
help
with
that
foreign.
A
A
So,
let's
talk
about
events.
First
item
office
hours.
A
A
A
L
All
right
and
if
somebody
can
take
notes
so
that
I
can
talk
and
take
and
not
be
taken
notice
at
the
same
time.
So
one
of
the
things
that
we're
realizing
over
time
is
that,
in
terms
of
topics,
a
lot
of
the
topics
are
getting
duplicated
for
the
community
meeting
between
the
community
meeting
and
the
leads
meeting
and
people
don't
want
to
talk
about
it
till
it's
finished
at
the
leads
meeting,
but
by
then
no
one
really
wants
to
talk
about
it
ever
again.
L
Also
in
general,
we're
not
really
getting
a
lot
of
community
topics
coming
in
no
matter
how
much
we've
tried
to
kind
of
put
a
form
out
there
put
other
ways
of
like
tagging
us
on
things,
anything
like
that
and
we're
also
starting
to
see
a
drop
in
interest
in
showing
up
to
the
meeting
which
we've
seen
for
a
while
now,
but
we've
noticed
it
with
other
meetings
as
well
like
meet
our
contributors
office
hours,
things
like
that.
So
all
of
that
being
said.
L
L
Otherwise,
some
thoughts
are
like
short
videos
that
people
could
watch
or
like
triggering
regular
threads
in
the
kubernetes
contributors
channel
on
Slack,
something,
but
in
general,
I
think
that
the
community
meeting
is
no
longer
really
giving
us
what
we
had
hoped
for
in
the
past
like
two
or
three
years,
and
it's
probably
time
to
consider
other
alternatives
so
wanted
to
bring
that
to
the
group
open
the
floor
and
see
what
people
have
to
say
about
it.
L
H
My
first
thought
is:
maybe
we
just
addressed
the
Cadence,
because
enough
people
have
burnout
that
maybe
moving
to
like
a
quarterly
meeting,
might
make
more
sense
and
potentially
promote
it
as
something
less
of
a
community
meeting
and
more
of
a
all
hands
or
something
I,
don't
know.
That's
that's
my
thoughts
as
rambly
as
they
are.
L
K
That's
that's
actually
sort
of
what
I
was
thinking
like
between
between
releases
might
be
a
good
time
to
have
like
hey.
This
is
what's
happened
in
this
past
release.
K
This
is
what
we're
working
on
forward
here
are
large
things
we
are
proposing
and
the
release
team
is
already
doing
some
of
that
work
to
collect
things
for,
like
you,
know
the
the
release
blogs,
so
we
might
be
able
to
do
something
there
with
that
I,
don't
know
if
we
still
call
it
the
the
community
meeting
either
way
like
on
on
the
steering
side,
we
need
to
remove
the
like.
We
just
need
to
remove
the
governance
requirements
for
it,
because
we
no
one's
Meeting,
those
so.
E
L
J
L
L
L
K
Yeah
George.
K
L
Yeah,
there's
definitely
a
lot
of
people
who
I
go
I
approach
them
about
hey.
We
need
just
somebody
just
to
come.
Kick
off
the
discussion
about
the
topic
and
they're
like
not
this
time,
because
I'm
not
ready
or
not
this
time,
because
I
don't
think
it's
a
good
enough
topic
or
we
need
to
discuss
it
longer
or
or
or
or
of
course,
there's
a
lot
of
people
who
don't
really.
K
When
going
on
like
actually
like
Tim
your
thing
too
or
like
okay,
we're
putting
this
into
effect,
this
release,
you
know
I'm
using
as
an
example,
even
though
yours
can
go
in
in
really
whenever
that's
also
when
those
things
can
be
announced.
L
Yeah
I
definitely
would
still
call
it
like
a
community
meeting
instead
of
a
contributor,
All
Hands.
That's
I
agree
that
it
kind
of
sounds
a
little
like
I'm
still
at
work.
Feeling
I
don't
know,
but
if
we
did
do
it
out
almost
quarterly
I
imagine
we
could
time
it
with
kubecon
as
well,
so
it
could
be
a
event
at
contributor
Summit
twice
a
year
and
then
twice
a
year
it's
on
Zoom,
which
might
also
help
with
some
of
the
zoom
fatigue.
L
K
K
L
K
K
We
do
sort
of
talk
about
those
things
at
the
Summits,
but
like
the
way,
the
releases
and
all
that
tend
to
be
timed
like
try
to
factor
in
around
well
around
kubecons,
and
sometimes
it
winds
up
being
sort
of
in
a
release.
This
come
with
the
way
the
schedule
plays
out.
L
Yeah
yeah
because
we
don't
really
have
much
control
over
when
they
schedule
kubecon
most
of
the
time
it's
really
based
on
whatever
City
they
choose
what's
available
and
when
and
all
that
that's
fair
would
be
nice
to
hold
at
least
one
though
at
the
contributor
Summit,
because
I
feel
like
it
would
socialize
it
a
little
bit
more
and
get
more
people
to
show
up
for
it.
Maybe
that's
just
me.
J
Yeah
I
mean
I
agree.
It
would
probably
get
more
people
to
show
up,
but
I
don't
know.
If
that's
what
do
we
really
want
to
sit
there
and
talk
about
that
as
like
I'm
talking
about
the
time
it's
going
to
take
thinking
about
that
aspect
of
it
right
like
if
we
had
every
Sig
talk
about
their
enhancements
or
whatever
every
release.
This
meeting
would
be
like
four
hours,
long
yeah.
D
A
D
J
Curating,
here
of
you
know,
what's
what
do
we
want
to
highlight
and
we
can
lean
on
the
leads
for
that,
but
we
also
have
to
be
like
you
know
like
give
us
your
important
ones
or
limit
them
to
a
certain
amount
of
time
or
topics
or
something
yeah,
because
I
think
we
all
agree
a
full
hour
meeting
going
longer
than
that
is
nuts.
J
J
K
J
Yeah,
it's
it's
a
couple
things
right
like
a
you
need
the
gear
to
take
the
standard,
video
camera,
feed
and
turn
it
into
something
that
can
be
streamed,
and
then
you
need
the
bandwidth.
You
need
like
the
horsepower
and
then
Mike's
that's
people
to
run
it
all,
and
then
everything
else
it
gets
really
expensive,
really
fast.
M
There's
there's
also
the
aspect
that
a
lot
of
the
sessions
at
contributor
Summit
tend
to
be
collaborative
as
well,
especially
like
the
unconference
sessions
and
the
Sig
meeting
great
sessions
and
those
even
if
we
did
try
to
live
stream
them
they're
generally
very
hard
to
participate
in
remotely,
because
you
have
multiple
people
that
are
talking
at
the
same
time,
and
you
know
you,
you
become
kind
of
like
an
outsider
in
the
remote
experience.
In
those
cases.
H
L
Yeah
regarding
the
question
about
like
the
sigs
and
24
cigs,
five
minutes
taking
two
hours
just
in
case
some
folks,
don't
know
just
to
give
a
bit
of
context
to
the
community
meeting
like
two
or
three
years
ago.
What
it
used
to
be
is
that
we
had
three
cigs,
sometimes
four
at
every
community
meeting
that
were
assigned,
and
it
was
a
rotating
assignment
system
where
you
were
assigned
to
come
and
give
a
short
presentation
on
what
you
were
up
to.
L
So
it
was
more
of
like
a
state
of
the
community
walking
through
each
Sig
had
to
give
a
presentation
that
was
then
removed,
because
the
annual
reports
were
doing
the
same
exact
thing
when
they
got
reworked
and
so
people
were
like.
L
Why
are
we
giving
an
update
to
the
community
at
the
community
meeting
and
doing
annual
reports
and
I
think
there
was
one
other
Reporting
System
they
had,
and
so
it
it
was
kind
of
Slash
in
interest
of
trying
to
make
it
a
little
more
accessible
and
not
asking
Sig
leaderships
to
constantly
be
doing
updates
all
the
time
which
is
kind
of
why
we
don't
have
that
kind
of
update
anymore.
L
Well,
then
people
don't
really
want
to
sit
and
talk
about
them.
They'd
rather
deal
with
it
later,
and
then
it
became
well.
Whatever
topic
people
want
to
talk
about,
and
now
we
can't
get
topics
so
I
think
that's
kind
of
the
evolution
that
we're
currently
talking
about.
Just
to
give
a
bit
of
background
to
folks
who
maybe
weren't
around
for
any
of
that.
L
F
I
So,
like
I
I
was
just
thinking
about
a
conversation
that
happened
in
a
steering
committee
meeting
a
couple
of
months
back.
The
conversation
was
around.
How
do
we
better
the
or
how
do
we
make
it
easier
for
six
to
generate
data
for
annual
reports,
and
one
of
the
suggestions
that
was
discussed
was
maybe
generating
this
data
per
release
rather
than
having
to
do
it
all
at
once
at
the
end
of
the
year.
I
I,
don't
know
what
happened
about
that,
but
like
drawing
a
parallel
to
that
here,
if
we
did
want
to
do
something
that
the
community
meeting
hoped
to
achieve,
but
not
get
everyone
on
a
zoom
call,
it
would
be
something
along
the
lines
of
like
a
like
a
blog
or
something.
The
good
thing
about
that
is
that
the
we
now
have
full
automation
to
generate
caps
that
each
stick
has
been
working
on
that
got
merged
just
this
week.
I
A
A
H
H
Let's
see
content's
already
comms
is
ready,
reg
is
up
in
the
air,
but
being
Set
sorted
out.
Celebration
is
ready,
Opps
I
need
confirmation
and
the
sick
meet
and
greet.
We
actually
have
someone
to
run
at
this
time.
So
I.
H
This
is
definitely
something
that
we'll
need
a
lot
of
help
on
site
yeah
other
than
that
we
we
started
the
meetings
sort
of
on
short
notice
and
then
the
second
meeting
happened
on
MLK
day.
So
we
expected
that
there
would
be
low
turnout
and
there'd
be
some
confusion,
but
by
this
coming
Monday
we
should
have
a
lot
of
things.
Sorted
out
should
be
sailing
a
lot
more
smoothly.
A
B
This
time
and
they
keep
on
you
I'm
running
for
the
first
time
in
person.
So
I
would
like
to
understand
just
like
just
about
the
Contemporary
Summit
as
a
whole
and
what
are
the
kind
of
agenda
or
line
items
to
be
known
before
returning
The
Summit
in
person,
yeah.
H
So
primarily
the
Summit
is
going
to
be
it's
an
entire
day.
Zero
event
it'll
happen
on
Tuesday
before
the
conference
proper
starts
it.
We
typically
start
with
a
AMA
with
the
steering
committee
so
that
everybody
gets
about
an
hour
to
just
ask
their
questions,
and
then
it
breaks
out
into
a
number
of
tracks.
H
For
the
past
couple,
it's
been
multiple
tracks
of
unconference,
so
the
topics
tend
to
be
decided
on
the
day
of
the
conference,
so
that
folks
can
break
into
the
sessions
that
they
want
to
talk
about
the
most
and
depending
on
what
we
get
from
a
cfp.
We
can
also
have
a
set
of
prepared
presentations.
D
A
Moving
on,
let's
move
on,
if
you
do
have
any
questions,
you
know
where
to
find
us
mentoring
anything
we
want
to
discuss
around
mentoring
today,.
K
A
We'll
move
on
past
that
for
now
contributor
comms
is
there
anyone
here
from
that
group
today,
yeah.
J
We've
been
a
little
busy
over
here
in
contributor.com
the
so
some
changes
castle
and
I
worked
on
last
week.
Thank
you,
Bob,
for
your
help.
We've
updated
our
owner's
files
to
have
all
of
our
sub-project
leads
the
approvers
and
so
forth.
We've
also
updated
our
Charter
to
reflect
the
change
from
marketing
team
to
contributor
comms
and
a
few
other
things
generated
a
rule
book
for
leading
the
sub
project,
which
is
you.
J
I
think
it's
kind
of
like,
oh
as
we
discover
things,
We'll,
add
things
but
I'm
glad
atari's.
Here
he
can
kind
of
dive
into
the.
Our
automated
tweet
system
is
not
very
automated
right
now
so
ping
caslin
myself
atarva,
you
can
just
ping
the
whole
cons
team.
If
you
want,
if.
J
A
But
we
can
always
help
out
with
tweets.
If
you
file
an
issue
in
the
in
the
repo,
we
will
make
sure
that
it
gets
done
or
if
you
ping
us,
we
will
make
sure
that
it
gets
done.
Even
if
our
Automation
in
GitHub
is
broken.
We
have
other
tools,
yeah.
J
We
have
a
buffer
account
that
we
can
load
things
up
into
which
it
would
be
cool
if
we
had
some
kind
of
if
there
was
a
GitHub
action
that
took
like
issue
content
and
push
them
to
buffer,
and
then
we
just
hit,
approve
and
out
the
door.
It
goes
that'd
be
kind
of
nice,
but
also
not
as
transparent
either.
So.
C
D
A
J
You
have
to
kind
of
like
feed
it
to
something
else
and
then
give
another
role
or
zap
as
they
call
it
another
job
to
where
it
takes
it
from
that
thing
and
then
puts
it
in
buffer.
So
in
my
case,
for
example,
I
do
all
the
suggested
reads.
You
know
everything.
I
read
I
share
kind
of
thing
that
goes
to
a
bookmarking
app
and
then
there's
another
zap
that
takes
it
from
the
bookmarking
app
to
buffer.
J
C
D
A
A
K
Sorry
hit
this
hire
me
button,
not
the
software
one.
We
can
just
put
this
and
move
on
to
the
next
thing.
Okay,.
A
Sounds
good
I
know,
there's
a
couple
folks
in
contributor
comms
that
are
standing
by
ready
to
help
with
that.
If
you
need
anything
next
item
moderation
and
media,
do
we
have
anyone
here
today
to
talk
about
that.
E
Yeah
I
was
thinking
that
we
have
the
proof
of
concept
zap
working
on
this
channel,
for
which
explain
is
like
relatively
reliable,
like
I've
been
seeing.
We
have
two
video
uploads
every
week.
One
from
explain
one
from
the
zap
and
I
was
wondering
if,
until
we
figure
out,
you
know
what
we're
going
to
do
largely
to
get
it
working
across
like
the
org.
E
If
we
could
turn
this
app
onto
a
Sig
that
is
manually
uploading
right
now,
so
I
know
like
Sig
docs,
for
example,
like
they
manually
upload
their
YouTube
videos
and
I'm,
wondering
if
there's
a
Sig
that
we
could
work
with
to
turn
this
on
for
them,
so
that
it's
actually
doing
something
useful.
While
we
figure
out
what
to
do
for
the
global
kubernetes
account.
K
So
Sig
node
actually
reached
out
to
me
about
this
the
other
day
and
asking
about
how
to
automate
this
process
so
I
think
there's
a
good
candidate
right
there.
There.
E
E
J
A
E
Stuff
marky's
out
for
a
bit
so
like
I'm,
taking
over
with
a
lot
of
the
YouTube
stuff.
So
if
there's
YouTube
stuff
while
marky's
gone,
let
me
know.
A
All
righty
GitHub
management.
I
So
I
I
just
had
one
item.
This
is
more
of
a
RFC
than
anything
else.
So,
if,
if
anyone
has
comments
or
opinions
about
this,
a
quick
summary
is
that
there
is
a
pro
plugin
called
needs,
rebase,
which
essentially
adds
the
label
needs
rebase.
Whenever
there's
a
merge
conflict
on
your
PR,
the
way
it
does
it
is,
it
gets
triggered
either
on
on
a
commit
change,
or
it's
run
as
a
periodic
and
right
now
it's
I
think
running
every
six
hours
and
checking
for
merge
conflicts
Etc.
I
I
That
label
will
will
remain
there
unless
you
rerun
all
of
the
Ci
or
you
wait
for
the
like
the
six
hour
window
to
close,
and
it
probably
isn't
that
far-fetched-
a
scenario
where
you
have
a
PR
that
that's
maybe
like
unblocking
the
kubernetes
CI,
which
you
know
has
blocked
quite
often
and
like
this.
This
might
happen
and
you
you
are
essentially
wasting
time
regarding
the
CI
over
there.
I
So
this
is
just
like
a
an
ask
or
a
or
a
proposal
to
just
add
functionality
to
manually
re-trigger
that
plugin
by
just
adding
an
additional
command
to
do
so.
I
opened
the
issue
up
a
few
I
think
last
week,
I'm
not
sure
if
folks
have
seen
it,
maybe
I
should
send
an
email
about
it.
But
if
people
from
here
have.
A
A
Tim
Hawkin
has
opened
an
issue
about
prow
should
not
at
mention
the
pr
author
looks
like
folks
are
generally
in
agreement
on
the
issue.
Any
comments
about
that.
You
can
find
the
link
in
the
notes.
C
I
just
had
one
question
about
it,
so
currently,
what
DPR
open
generally
works
on
removing
only
the
Kids
Bot
response
with
their
where
there
is
no
description
in
the
autobot
Autobot
response.
So
do
we
want
to
really
remove
all
the
admissions
from
what
response
so
KCI
robot
should
not
ever
mention
the
author.
Do
we
want
something
like
that,
or
we
should
just
focus
on
not
mentioning
the
pr
author
for
certain
instances.
C
D
A
K
I
think
it's
really
just
let's
see,
essentially
it's
just
updating
that
one
message
to
remove
the
the
adding
the
author,
so
I'd
be
issue
and
yeah.
It
looks
like
you
have
it
covered
in
your
PR
from
a
quick,
quick
look.
A
Awesome-
and
we
are
at
time
so
I
want
to
go
ahead
and
close
things
up,
so
folks
can
get
to
their
next
meetings
if
they
need
to.
Thank
you
all
so
much
for
joining
today.
If
you
have
any
questions,
you
know
where
to
find
us
on
slack
in
the
Sig
contribex
Channel
see
ya.