►
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
Boom,
hello,
everyone
and
welcome
to
the
monthly
contributing
github
edmund
team
meeting.
I
will
be
your
host
today
and
with
that,
let's
sort
of
kick
off
with
the
sort
of
regular
stuff.
This
is
a
recorded
meeting.
We
all
abide
by
the
cncf
code
of
conduct,
which
essentially
boils
down
to
please
be
excellent
to
each
other,
and
with
that
we
can
go
right
into
it
see
it
looks
like
you
have
the
the
first
oh
update
the
meeting
info
to
include
the
password.
I
thought
I
thought
it
wasn't
there.
B
A
A
Interesting
I'll
take
a
look
at
that
after
the
meeting.
A
B
A
I
we'll
take
that
as
a
no,
so
the
next
thing
on
the
list
was
to
it's
been
a
little
bit
of
time
and
we
wanted
to
promote
the
new
member
coordinators
to
approvers.
A
Okay,
I
will,
I
will
continue
with
you
know.
You
know
what
I
will
go
to
like
my
little
note,
real
quick
and
then
we
will
we'll
come
back
to
see
if
your
audio
and
everything
is
fixed
by
then
actually
she's.
B
A
A
A
Well,
a
little
note
that
I
have
is
that
github
has
slowly
been
rolling
out
the
recognition
beta.
It
has
not
been
applied
to
the
kubernetes
project.
Yet
I
will
let
the
admins
and
general
community
know
once
it
is
available
that
will
probably
be
sometime
next
week.
A
C
C
So
when
one
create
a
pr
for
the
kk
and
then
create
a
pr
with
for
the
k
website,
then
a
whole
level
will
put
manually
in
the
k
website
and
it
will
be
removed
once
the
kkprs
is
merged.
A
A
Does
anyone
else
have
thoughts
on
that?
One.
D
Thank
you
steven
recall
that
you
couldn't
hear
me
so
we
have
looked
into
this
before
and
the
conclusion
we
drew
with
the
time
is,
it
would
be
the
amount
of
like
the
corner
cases.
This
is
basically
like
a
hold
until
another
pr
virgin's
dependency
as
cross
repo.
D
We've
talked
about
it
before
it's
actually
there's
some
technical
issues
with
it
with
tokens,
like
the
amount
of
tokens
that
it
would
use
for
our
github
automation,
to
do
that
polling
because
it
isn't
something
that
github
would
necessarily
push
to
us,
and
then
we
keep
track
because
proud
doesn't
actually
hold
state.
D
So
yeah
we
looked
into
it
actually
fairly.
Recently,
within
the
past
few
months
that
came
up
and
the
conclusion
was
it's
too
much
work
to
try
and
support
it
and
overcome
the
technical
challenges
for
the
corner
cases
that
we
have.
This
is
a
corner.
This
is
a
case
that
we
hadn't
heard
about
and
makes
total
sense
and
I'll
make
sure
to
add
into
the
issue
so
that
if
we
revisit
this,
we
kind
of
have
this
log
that,
like
hey
the
docs
team,
would
potentially
like
to
use
this
too,
but
yeah.
D
C
D
Great
and
we're
free,
we
appreciate
the
engagement
the
so
this
this
team
doesn't
necessarily
isn't
directly
responsible
for
this,
like
the
prowl,
automation
would
normally
be
stick
testing,
but
I'm
also
like
involved
in
a
bunch
of
stick
testing
stuff.
So
I
could,
I
could
speak
to
it
so
I'll
link
you
the
issue
in
our
in
our
notes,
so
that
you
kind
of
have
it
and
basically
have
the
decision
that,
like
you
know,
we
aren't.
We
probably
not
gonna,
tackle
this
right
away
because
of
some
of
the
technical
challenges.
D
A
Okay,
what
that
nikita
are
we
back
to
your
audio
working.
E
E
So
I
think
it's
time
we
promote
them
to
approve
us
and
the
other
one
thing
I'd
notice
like
when,
like
during
onboarding
them
during
the
onboarding
period.
I
know
we've
discussed
a
lot
of
questions
and
like
things
that
weren't
documented
before
so
as
an
aside,
we
should
also
make
sure
we
document
them,
but
yeah.
I
think
I
think
it's
time
to
promote
from
an
mcs
to
approve
us.
What
does
everyone
else.
A
E
E
Yeah,
so
this
was
just
something
I
wanted
to
toss
out
an
idea.
I
wanted
to
pass
out
here
and
get
a
pulse,
what
y'all
think
so.
I've
been
working
on
the
approval
plug-in
with
bob
and
another
co-worker
of
mine's
attractive
into
this,
and
we
have
a
poc
right
now.
We
need
to
write
the
cap.
There
are
some
edge
cases
that
we
need
to
figure
out,
but
granular
also
like
rejects
filtering.
E
You
know,
as
files
works
right
now
and
you
can
also
like
specify
the
checks
for
approving,
so
you
can
select,
slash,
approve
and
then
list
the
files
that
you
want
to
approve
to.
So
I
will
create
a
cap
and,
like
formulas,
reach
out
to
you
all
for
review
later
on,
so
it's
not
ready
for
review.
Yet
what
I
wanted
to
talk
about
was
what
do
you
think
about
a
test
org
like
a
kubernetes
test
or
something
like
that
for
testing
such
broad
brow
or
release
engineering
changes?
E
I
say:
release
engineering
only
because
I
know
we've
talked
about
a
fork
of
gay
care
preferred,
so
I
just
want
to
get
get
a
pulse
of
what
you
think
for
a
dummy
or
us
and
just
also
add
on
to
that
for
publishing.
But
we
now
we
use
our
communities
nightly.
It
was
just
created
for
historical
reasons
and
we've
been
using
it
to
test
changes.
So
something
like
that.
But
for
pro.
B
Oh
come
on
aaron,
I'm
personally
in
favor
of
this,
at
least
from
the
release
engineering
perspective,
it's
something
that
we
had
submitted
a
while
back
and
didn't
really
get
traction
on.
B
Outside
of
using
an
org
and
ideally
the
org
would
be
blessed
by
the
kubernetes
project,
so
at
least
from
the
rel
engine
rel
inside
I'm
plus
one
for
this.
A
Aaron,
I
know
you're
muted,
but
can
you
do
you
like
a
good
alternative
to
another
org
or
someone
could
test
like
a
rewrite
of
the
approved.
E
Plugin,
so
to
the
question
for
why
and
or
was
the
specific
reapers
so
like
for
broad
changeless,
like
maybe
rewrite
of
an
approval
plug-in
that
can't
be
gated
behind
a
conflict
option,
we
can't
I
mean
if
we
enable
it
it
will
get
enabled
everywhere.
E
E
E
So
this
one
is
this
one
so
like
at
least
the
rewrite
of
the
approved
plugin.
I
can
talk
about
that.
It
changes
completely
how
approval
looks
at
files.
So
initially,
when
you
forget,
when
the
approval
plugin
looks
at
which
directories
and
files
to
consider
for
approval,
it
just
looks
at
owner's
files.
Now
we
would
be
looking
at
individual
files.
I
think
I
can
like
talk
more
about
this
when
we
have
a
designer
kept
open,
but
it's
hard
to
add
a
config
option,
I'm
also
totally
okay,
with
an
approved
plug-in.
E
If
that's
how
we
want
to
go,
I,
but
that
wouldn't
work
with
a
lot
of
duplication
of
code.
A
Yeah
we
had
pre
like
nikita,
and
I
previously
discussed
the
approved
two
plug-in.
You
know
approved
tube
before
looking
at
the
like
all
the
interdependencies
with
it
all.
F
D
D
I
I
come
from
the
perspective
of
I
agree.
We
don't
want
to
add
more
orgs
and
add
more
overhead
that
we
need
to
administer
if,
if
there's
like,
feasible
reasonable
technical
alternatives,
I
think
there's
a
couple
different
reasons.
Why
we'd
be
looking
at
a
a
staging
org
being
both
you
know,
potentially
this
this.
D
The
like
a
stage
having
a
staging
prowl
that
we
can
roll
things
to
which
I
actually
like
the
idea
of
a
staging
prowl.
Because
there's
been
a
lot
of
cases
where
we've
had
like
code
changes
to
prowl
that
we
haven't
found
until
we
got
into
production.
But
that
would
involve
a
conversation
with.
D
D
D
I
also
definitely
see
value
in
that
because
you
know
historically,
there
has
like
these
have
been
actually
pretty
good.
Recently,
I
haven't
really
seen
or
heard
anything
and
that's
a
credit
to
stephen
of
the
release
management
team,
but
historically
I'm
thinking
back
years.
We've
definitely
had
things
where
good
old
anago
has
gone
haywire
and
has
done
things
that
it
shouldn't
do
so
having
a
staging
environment.
For
that
also
wouldn't
be
a
bad
thing.
D
So,
but
my
I
guess
what
I'm
trying
to
say
is:
I
don't
necessarily
want
to
shoot
down
this
idea
completely,
but
I
do
think
we
need
to
flush
out
those
two
use
cases
and
I
think
engaging
with
relief
management
and
sick
testing
could,
because
I
I
don't
want
us
with
github
management
to
take
it
on
if
we're
not
gonna,
get
buy-in
from
testing
and
release.
If
testing
and
release
are
along
the
side
with
us
and
have
plans
of
like
okay,
this
is
how
we
can
use
it.
D
B
Given
given
the
changes,
I'm
I'm
also
wondering
if
these
sound
like
different
orgs,
the
there's,
also
the
the
discussion
about
feature
branches
and
forks
and
stuff,
and
that
I'm
not
sure
where
we
left
it
exactly
whether
how
people
felt
about
that,
but
I
had
reserved
orgs
for
that
purpose.
In
case
we
decided
to
go
that
route,
but
yeah,
I'm
I'm
open
from
the
release
management
perspective.
It
would
definitely
be
a
nice
to
have
just
for
our
tooling.
B
We
are
getting
to
the
point
where
the
tooling
is
much
safer
than
it
used
to
be
and
hoping
to
destroy
a
naga
by
the
end
of
the
year.
We'll
see
if
that
happens.
That
was.
That
was
my
initial
thing
that
I
said
on
on
kdev
from
the
last
inaugural
debacle,
but
we'll
see,
I
think,
we're
I
think,
we're
close
but
having
having
something
to
test
safely
against
both
the
the
release
engineering
proper,
as
well
as
publishing
bot,
which
is
also
release
engineering.
B
A
B
Who
has
ownership
of
like
is,
is
kubernetes
nightly,
is
like
a
thing
our
thing
or
is
it
kind
of
an
org
owned
by
the.
E
So,
coming
back
to
the
little
new
art
point,
I
just
wanted
to
get
like
an
initial
pulse
and
feedback
about
it,
and
this
is
helpful
feedback
and
I'll.
Come
back
to
this
problem,
to
stick
testing
and
other
things
with
when
I
have
more
concrete
info
and
a
cab
and
like
a
solid
plan.
D
Yeah
that
that
sounds
good
to
me,
like
my
initial
gut
feeling,
is
I
really
like
the
idea
of
an
approved
two
plugin,
even
if
it's
like
a
bunch
of
code
copying
and
then
we
like
rip
out
the
old
approve
plug-in
when,
when
we're
done
with
the
amount
of
changes
that
are
going
to
go
in
and
user
education
and
that
kind
of
stuff,
like
I
think,
having
having
an
approved
two
plug-in
and
being
able
to
switch
it
on
for
certain
repos,
I
think
is.
A
A
Okay,
we
have
to
only
seven
minutes
left.
Is
there
any
more
discussion
on
this?
I
think
the
next
item
was
either
backlog
going
through,
or
I
actually
see
our
no
her
nose.
B
A
Do
you
want
to
talk
about
it.
F
It's
just
one
action
I
need
from
aaron,
I
think,
and
also
basically,
the
idea
is
to
migrate
every
pre-summit
and
personal
job
to
the
new
gk
cluster.
But
before
that
we
need
to
create
the
token
related
to
the
different
bots
and
also
slack.
A
He
says:
try
paying
testing
for
on-call
to
get
a
new
token
yeah
to
get
the
secrets
added
over
over
there
if
you
need
a
new
slack
token,
just
ping
in
slack
admins,
and
essentially
it
pops
up
asking
us
to
approve
any
sort
of
requests,
and
when
that
happens,
we
just
you
know
hit.
Yes,
we
by
default,
like
essentially
just
hit
no
on
any
new
token
request.
A
A
Okay,
we
have
five
minutes
left.
Is
there
anything
anyone
else
wants
to
talk
about.
A
Okay,
I
don't
think
it's
github
actions
policy.
That
is
a
good
one.
We
were
talking
about
this
the
other
day,
thanks
for
bringing
that
up
again
aaron.
So
currently
we
have
github
actions
enabled
by
default
across
every
org
and
every
repo.
A
Now
historically,
we've
had
you
know.
Github
actions
is
very
similar
to
things
you
know,
travis
and
other
sort
of
like
third-party
bots
or
in
integrations,
and
our
previous
policy,
with
those
have
been
to
you
know,
have
people
file
requests
to
enable
it.
For
that,
do
we
want
to
potentially
disable
github
actions
across
the
orgs
and
have
people
go
through
the
same
process
for
us
to
enable
it?
A
A
There
are
there
there's,
I
know
of
two
that
contributes
owns
and
I
think
there's
a
few
others
out
there
that
are
using
them
as.
A
A
G
I
am
also
just
adding
to
the
list
the
kubernetes
clients
they
use.
Some
of
them
use
github
actions.
G
Can
we
possibly
like
send
this
out
and
put
a
deadline
like
a
timeline
to
it
that
maybe
in
one
month,
it's
going
to
be
disabled,
because
people
who
just
relate.
A
A
Yeah
we
wouldn't
just
like
blanket.
You
know
just
a
turn
of
dime
turn
it
off,
so
there
would
definitely
be
notifications
about
that
sort
of
thing.
Okay,
aaron
also
asks
if
we
want
to
maintain
a
white
list
of
allowed
actions,
as
it
is
in
attack,
vector
third-party
actions
changing
to
like
potentially
exfiltrate
secrets
that
was
actually
sort
of
the
root
issue.
That
sort
of
surfaced
this
I
can.
I
can
link
it
it's
from
in
the
the
korg
repo.
B
Yeah
there
was
one
that
popped
up
from
from
tim
bannister
as
well.
I
think
in
kk,
around
locking
down
the
dot,
github
workflows,
yep.
A
Yeah,
I
think
that's
he
cross-posted
that
to
k
org,
and
that
was
the
one
that
I
was
thinking
of:
okay,
cool
cool
yeah.
Personally,
I
don't
think
we
need
to
like.
I
would
go
ahead
and
disable
actions
on
on
kk,
but,
like
specifically,
the
the
current
owners
are
github
admins
or
the
you
know,
people
that
approve
are
github
admins,
so
I
wouldn't
be
concerned
about
kk.
A
D
D
A
I
I
am
okay
with
that
one.
We
are
also
at
time
at
this
point.
A
So
yeah,
I
think
you
know,
discuss
any
potential
well,
we'll
confirm
all
this
stuff.
On
the
issue
of
the
tactic
we
want
to
take
with
white,
you
know
potential
white
listing
or
just
putting
the
onus
on
repo
owners
and
then
set
up
the
timeline
for
sending
the
notification
out
to
kdev,
and
you
know
turning
them
off
work
wide
and
is
there
any
last
other
last-minute
items
people
want
to
get
in
or
that
we
should
be
aware
of.
A
Okay,
we
we
will
call
it
there.
Thank
you,
everyone
for
attending.