►
From YouTube: CNCF CNF WG Meeting - 2022-07-18
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
Hey
folks,
hey
tom
looks
like
we
have
a
small
group
today.
Yeah.
A
Well,
other
than.
A
C
D
A
We
can
get
started
on
this
first
one
as
far
as
documenting
the
process
to
publish
the
best
practices
last
week,
kind
of
went
through
quickly
with
a
few
things,
but
didn't
organize
all
of
it.
A
A
C
A
A
C
A
A
C
D
Yeah
but
technically
you
cannot
make
a
comment
on
closed
pr
so
or
where
you
can.
D
A
B
A
A
B
B
A
A
Allow
privileges
on
containers,
okay,
that
sounds
a
little
more
specific.
But
what
do
you
mean?
Oh,
we
mean
don't
allow
root.
Okay,
what
about
privilege
equals
true?
What
about
you
know
running
the
runtime
privilege
you
know
just
on
and
on
and
on?
Oh
okay,
we
can
break
it
down.
Each
one
of
those
sub
ones
should
be
their
own
issue,
but
they
may
not
be
ready,
but
if
they
are
go
ahead
and
create
an
issue.
D
D
So
taylor,
what
what
is
going
to
be
the
criteria
for
open
an
issue
versus
open
a
pr
I
mean
me
from
my
perspective
when
you
create
an
issue,
is
like
so
you're
reporting,
something
that
you
don't
know
how
to
do
it
like.
In
this
case,
probably
you
are
suggesting
a
topic
that
you
don't
know
what
is
the
best
practice
or
like
what
is
the
use
case,
but
at
least
you
raise
the
hand.
D
On
the
other
hand,
a
pr
is
more
like
a.
I
have
I
propose
in
this.
This
is
my
proposal.
This
is
my
the
best
practice
that
I
am
proposing
and
I'm
just
need
feedback
of
that
specific
proposal.
So,
but,
in
this
case
yeah
what
could
be
the
choosing
between
an
issue
versus
a
pr.
A
A
A
Maybe
you,
the
the
pr
is
related
to
that
best
practice
is
adding
a
user
story
that
provides
context.
Then
you
create
another
pr
with
the
first
draft
of
the
best
practice
that
references,
the
use
of
story.
So
you
could
have
multiple
pr's
under
one
issue,
but
the
issue
is
communicating
where
you're
trying
to
head
with
the
best
practice.
D
D
D
First
of
all,
in
the
in
the
discussion
discussions
section
or
like
just
going
directly
and
open
an
issue
or
or.
A
I
I
think
it's
partly
a
preference
or
opinion
on
that
for
myself,
I
see
the
benefit
of
having
the
entire
process
so
that
people
can
see
how
it
fits
together
and
if
you're
stuck
at
any
stage,
you
can
jump
in
and
help.
You
know
put
it
in
there.
If
you
don't
know
where
to
start.
You
know
many
reasons
so
have
that
process,
and
then
I
personally
think
it's
okay
to
jump
in
anywhere
that
you
can
help.
A
As
long
as
you
recognize
that
you
know
there
could
be
areas
where
there's
missing
stuff
before
or
whatever
else
you
know,
then
I
think
it's
fine
and
then
other
people
may
want
to
the
way
that
they
their
process
for
work
are
the
way
they
work
through
things
they
want
to
start
from
the
start
and
move
forward.
A
So
if
you
already
have
you
know
this
idea
for
this
don't
use
static,
are.
Are
you
saying
don't
statically
configure
ip
addresses
in
the
cnf.
A
So
you
may
already
have
enough
information
to
feel
like
you
can
create
an
issue
and
say
here's
some
references
already
yeah.
I
mean
you
may
already
be
ready
to
write
the
pull
request
because
you
have
so
much
document.
That's
fine!
If,
in
that
case,
I'd
say,
create
an
issue.
Have
the
quick
summary
in
the
issue
and
then
you
know
you
could
put
a
pr
in
to
draft.
A
Otherwise,
if
you
don't
have
something
drafted
yet
then
create
the
issue.
Add
the
summary.
Maybe
you
know
you
add
references
and
say:
hey
here's,
a
bunch
of
places
where
people
have
said
you
should
not
statically
configure
ip
addresses
in
your
application.
You
should
allow
it
to,
you,
know,
be
dynamically
assigned
and
you
build
all
that
into
the
issue.
A
If
you
think
it's
a
good
idea,
but
don't
have
any
content
yet
and
you'd
like
to
get
more
people
talking
about
it
and
it's
you
know
you're,
just
not
sure,
that's
where
to
socialize
the
idea
and
you
may
this
is
this-
is
kind
of
open
between
three
and
four
someone
may.
A
Not
know
if
it's
a
good
idea
and
not
realized
that
the
whole
working
group
already
would
have
agreed
with
them,
so
they
could
have
jumped
ahead.
It's
okay,
then,
to
first
socialize
the
idea.
The
other
way
is.
You
may
think
it's
a
great
idea
and
believe
everyone's
going
to
agree
with
you
and
you
create
an
issue
and
people
don't
well.
It's
okay,
we'll
discuss
it
in
the
issue,
so
I
think
three
and
four
are
kind
of
open.
A
A
A
D
A
A
I
think
that's
what
we
haven't
had
as
much
forward
momentum
on,
and
I
think
that's
what
oliver
you
were
referring
to
last
time
was
the
process
specifically
for
best
practices
and
not
all
the
other
contributions.
C
A
A
A
A
It's
not
hard
rule
written
close
out
prs,
which.
A
Yeah,
I'm
that's,
that's
I'm
totally
fine
with
it
victor.
You
want.
A
D
Regarding
this
step,
does
that
mean
that
we
are
not
going
to
check
any
pr?
If
that
is
not
including
the
agenda
or
like
I
mean
it's
like
highly
recommended
that
the
submitter
adds
that
to
the
agenda?
To
I
mean
because
I
guess
usually,
we
take
a
look
of
all
the
open
pr's.
D
No
no
well.
The
thing
that
I
was
saying
is
like
for
me
this.
The
the
the
the
sentence
regarding
the
adding
the
the
pr
in
the
agenda
seems
more
like
a
suggestion
right,
because
essentially,
every
single
week
we're
going
to
discuss
all
the
open
pr's
and
even
when
they
are
not
including
the
agenda
right.
D
A
D
A
Is
separate
from
what
will
the
working
group
do
to
run
the
weekly
meetings
or
anything
else,
there's
overlap
between
all
the
work
that
we
do,
but
what
is
the
process
of
someone
is
coming
in
and
wants
to
publish
so
on
accepting
or
rejecting
at
some
point?
So
there's
a
there's,
a
pr
saying:
here's
a
best
practice!
Okay!
So
what
do
we
do
on
the
step
for
acceptance
or
rejection
of
that
pr?
A
We
need
to
review
and
discuss
it
and
I'm
putting
submitter.
Please
add
I'm
adding
this
in
here,
because
I
want-
and
this
is
like
a
note-
I
mean
this-
this
is
all
of
these
steps.
We
need
to
clean
up
and
eventually,
I
think,
publish
in
a
document
on
the
repo,
but
right
here,
I'm
putting
it
here,
because
I
want
people
that
are
submitting
ideas
to
actually
be
present.
Here's
your
pull
request.
A
We'll
then
add
it
to
the
agenda
like
proactively.
Add
it
so
it's
on
the
next
meeting
and
then
you're
saying
here's
the
not
or
whenever
they're
going
to
be
able
to
join
next.
Add
it
there.
Yes,
you
or
I
or
tom
are
going
to
go
through
and
go
hey,
there's
a
new
pull
request,
let's
discuss
it,
but
if
that
person
that
submitted
doesn't
even
show
up
we're
not
going
to
make
as
much
progress.
A
B
One
thing
we
could
do
is
maybe
just
create
a
dead,
simple
pull
request
template.
So
when
a
new
pull
request
is
created,
the
question
is
asked
of
the
person
creating
it
if
they've
added
it
and
a
link
to
it
to
the
upcoming
meeting
agenda,
just
as
a
trigger.
A
So
in
the
have
it
where
they're
going
to
see
it
as
they're
moving
through
the
process.
B
But
on
that
specific
point
about
adding
the
pr
to
the
upcoming
weekly
agenda,
we
could
create
a
simple
pull
request
template
so
that
when
a
pull
request
is
created,
there's
a
there's,
a
text
in
the
body
of
the
pull
request
asking
them
to
add
a
link
to
the
pull
request
to
the
meeting
agenda.
A
Sounds
good
so
there's
a
two
there's
a
lot
of
places
that
we
can
do
it
so
part
of
it
is
in
the
pull
request:
template
yeah.
We.
A
Add-
and
I
don't
know
if
it's
in
here
yeah
being-
and
there
is
see
this
so
that
this
stuff
is
not
going
to
be
visible.
A
A
So
we
can,
you
know,
have
something
here
that
maybe
I
I
don't
know
what's
possible
on
the
github,
but
if,
if
it
says
your
your
pr
has
been
created,
please
go
do
this
would
be
good
as
well.
D
B
Well,
in
terms
of
doing
something
about
this
there's,
I
think
quite
a
lot
of
what
you've
listed
there
is
in
the
contributing
file
already,
but
maybe
over
a
few
different
sections.
B
A
Yeah,
I
don't
even
want
to
say
it
must
go
in
the
con
contributor
document.
The
contributor
document
may
be
more
general
contributions,
but
we
can
have
just
a
section
creating
best
practices.
B
A
Whatever,
wherever
it
makes
sense
to
put
it
in
yeah
yeah,
it's
possible
that
we
want
something
like
a
you
know,
just
put
something
under
the
docs
folder.
For
that,
specifically
here's
the
process
outlining.
A
A
A
Yeah,
okay,
we
say
where
to
go
so
this
kind
of
put
him
off
to
that
how
to
talk
in
the
meetings
yeah.
I
think
this
one's
pretty
good.
If
you're
going
in
and
saying,
I
don't
know
how
to
do
this,
like
I've,
never
created
a
pr.
Well,
we
have
some
general
info
on
that.
Yeah
probably
need
to
link
over
to
the
github
docs
for
how
to
create
a
pr
stuff
like
that.
B
So
shall
I
create
an
issue
for
documenting
that
that
you
just
listed
in
there.
A
D
So
taylor,
usually
when,
before
creating
any
pull
requests
for
issue,
there
is
a
step
which
verifies
if
the.
C
C
B
A
We're
not
going
to
cover
all
cases,
we're
gonna
put.
What
we
think
is
gonna
help
us
and
help
guide
people,
and
then
we
should
set
our
expectations
that
people
aren't
going
to
always
read
and
they
will
do
open
stuff
anyways.
A
B
A
Right
yeah
we'll
stop
here.
I
feel
like
there's
something
after
this
maybe
published
to
the
there's:
a
publish
to
best
practice
list
review
and
get
buy-in
from.