►
From YouTube: CNCF SIG App Delivery 2020-12-16
Description
CNCF SIG App Delivery 2020-12-16
A
A
A
B
B
So
there
are
basically
two
important
progress
here
and
first
is
of
course
the
first
meeting
of
the
working
group
has
been
successfully
held,
so
it's
very
successful
community
meeting
and
we
see
a
lot
of
participators
there
and
they
are
all
very
exciting
to
make
sure
that
the
whole
working
group
is
a
open
and
mutual
vendor-neutral
organization.
So
we
are
actually
working
with
that
as
part
of
the
work
and
me
and
eloise
has
almost
finished
a
working
group
charter,
jobs
and
the
link
is
over
there.
B
I
think
in
this
week
or
at
at
least
latest
next
week
and
then
when
we
have
the
working
group
charter,
we'll
send
it
to
cncf,
so
the
cnc
will
give
us
a
official
meeting
link
and
the
calendar
event
imitation.
So
that
means
the
working
group
is
established,
and
this
is
the
first
progress.
Second
one
is.
We
have
also
talked
with
the
current
maintainers
of
the
working
group
repo
and
they
are
actually
working
on
migrating,
the
whole
project
to
a
independent
organization,
and
I
think
the
last
step
is
from
the
v
works.
B
Folks
they
are,
they
are.
They
need
some
legal
improvement
to
move
that
thing
from
the
flux
organization
and
basically,
they
need
approval
from
the
flux
maintainer.
I
don't
see
if
there's
any
blockers
there,
so
it
just
will
happen
this.
This
is
our
true
update
from
my
site
and
then
do
you
have
any
upgrade
on
the
working
group.
No,
you
you
covered
it
all
perfectly
sure,
thank
you
and
do
anyone
have
other
inputs
or
questions
regarding
to
the
working
group
before
we
move
to
next
discussion.
A
C
B
A
election
running
after
the
working
group
is
established,
and
so
this
is
exactly
next
step
and
also
the
the
existing
content
in
the
working
group
report
might
need
some
revised
because,
and
today
it's
fully
inherited
from
the
flux,
currency
model
and
documentation.
So
it's
basically
writing
around
the
flux,
so
we
need
to
revise
a
little
bit
a
little
bit
to
make
it
a
fully
independent
project.
B
B
Okay,
so
this
is
the
first
issue.
The
second
issue
is
regarding
to
the
operator
working
group.
I
didn't
see
tom
is
here,
so
I
will
have
to
speak
for
him.
So
the
the
progress
is
that
the
the
charter
of
the
opel
working
group
is
also
finished,
and
I
have
already
reviewed
this
documentation.
It's
basically
about
open
technicians
and
the
use
cases
of
operators.
B
So
I
I
believe
they
will
send
out
the
draft
documentation
to
the
mailing
list
of
the
c-gap
delivery
and
everybody
can
add
their
final
input
and
just
as
a
github
working
group,
we
will
try
to
finalize
this
charter
and
publish
it
as
the
official
sensitive
working
group
charter
in
github.
So
this
is
the
next
step
and
there's
also
another
thing
happening
in
c-gap
delivery
last
week,
and
that
is
a
flux
project
is,
is
asking
for
incubation
review,
so
the
sig
will
also
involve
in
that
process,
but
the
decision
maker
to
use
it.
B
So
we
will
try
to
provide
the
every
information
we
know
and
which
we
think
is
useful
to
the
toc.
So
if
anyone
in
the
sig
wants
to
want
to
contribute
or
talk
with
me,
please
feel
free
to
talk
with
me
and
always,
if
you
know
any
either
story
of
vlogs
or
you
know
anything
you
want
to
let
toc
know
or
you
think,
there's
anything
useful
to
help
or
anything
information
in
the
process
of
the
reviewed
vlogs.
Please
feel
free
to
ask
me
on
slack
talk
to
me
on
the
slack.
B
So
basically,
this
is
the
standard
review
process
which
happened
a
lot
in
the
past
few
years.
So
I
think
it
will
be
very
easy
to
handle
for
us
this
time,
and
another
issue
is
that
I
don't.
I
didn't
see
that
flux
folks
here,
but
the
issue
is
flux.
It
right
now
is
under
merging
with
flagger.
So
we
are
very
not
sure
if
we
want
to
involve
flagger
in
this
review
process
and
so
right
now.
B
My
proposal
is
that
if
the
merge
happen
I
mean
happen
for
example
recently,
then
we
need
to
involve
flagger,
but
this
is
not
it's
not
started
yet.
So
I
didn't
know
that,
for
example,
for
argo
family,
you
basically
also
have
several
stop
project.
So
how
do
you
handle
that?
Do
you
see
the
every
project
as
a
same
family
or
they
do
have
independent
functionalities.
C
B
B
A
B
That
means,
if
you,
if
you
want
to
add
a
new
project
into
the
existing
oracle
organization,
that
you
need
to
actually
run
under
the
revealed
cncf
again.
Okay,
I
see
yeah.
That
is
valuable
information.
I
didn't
know
that
before
okay,
this
is
basically
what
the
the
sig
has
up.
The
sig
has
already
is
already
working
on,
and
oh,
let
me
just
mention
the
next
sandbox
project
reviews
that
sure
yeah
like,
but
the
flux
is
actually
trying
to
promote
to
the
incubation
level.
D
D
C
B
So
this
is
not
decided
yet
because
the
standard
process
is
they.
The
working
group
will
have
a
separate
meeting
that
is
actually
the
meaning
for
working
group
because
they
want
to
have
their
independent
meeting.
But
we
do
have
discussion
that
maybe
you
want
to
merge
them
into
the
sig
meeting,
because
this
is
basically
one
of
the
important
one
of
the
most
important
field.
So
this
is
still
under
discussion.
B
I
think
we
can
discuss
that
after
we
have
the
working
group,
because
we
need
some
decision
makers
like
chairs,
for
the
working
group
to
say
okay,
if
they
want
to
merge
them
together
or
not
because
because
today,
there's
no
official
decision
makers
in
a
working
group
instead
of
several
community
meet
community
members
or
community
maintainers
there.
So
maybe
we
want
to
discuss
that
after
we
have
the
former
working
group.
This
is
my
contact.
The
content
idea
I
have-
I
don't
know
if
dan
has
any
other
styles
from
that.
E
Yeah,
I
I
think
we
could,
we
could
potentially
merge
some
of
it
or
we
could
use
the
the
working
group
to
kind
of
come
up
with
proposals
and
and
come
back.
You
know
as
a
sort
of
a
subcommittee
if
you
will
and
and
kind
of
present
those
things
I
could
see
it
going
either
way.
I
think
it
just
depends
on
level
of
interest
and
level
of
importance.
You
know
and
and
what
else,
what
other
things
are
going
on?
You
know
don't
want
to
be
disruptive
to.
B
Another,
oh
another
issue
is:
we
do
have
some
some
devices
from
toc
that
the
name
of
the
project
is
kind
of
needs.
Some
rethinking,
because
there
is
a
plan
to
donate
this
project
to
since
the
standbox,
but
it
will
be
very
interesting
to
see
their
project
in
the
sandbox,
which
has
a
name
of
the
working
group.
So
I
think
this
part
is
also
under
discussion.
B
B
So
it
looks
like
more
like
a
project
instead
of
the
working
group-
and
I
I
see
that
is
also
valuable
option.
But
I
didn't
read
this
discussion
with
everybody
here,
because
it's
just
some
ideas,
but
I'd
like
to
see
your
your
thoughts
on
that.
So
whether
you
want
to
have
a
where
do
you
think
they
need
a
new
name
or
you
think
that
the
working
group
has
a
project.
Name
is
fi.
A
E
F
Yeah,
so
I
honestly
have
not
thought
that
through
in
detail,
so
I
don't
know
whether
this
should
be
a
it
its
own
independent.
I
think
it
was.
It
was
proposed
as
an
idea
and
that's
something
that
we
as
a
as
a
as
the
sig
app
delivery
and
maybe,
as
the
working
group
itself,
should
make
that
decision
on
whether
this
is
something
that
we
do
want
to
actually
create
a
sandbox
project
around.
So
I
don't
know,
I
don't
know
what
the
answer
is
there.
It.
C
E
D
So
I
can
speak
to
some
of
that
and
I'll
just
kind
of
like
wander
on
it
and
like
hi,
so
the
working
groups
that
actually
exist
predate
the
sigs
and
serverless
is
the
only
one.
That's
still
active
around
that
there
was
a
conversation
a
little
bit
ago
about
them
becoming
a
sig
but
kind
of
died
for
lack
of
interest,
and
there
wasn't
a
lot
of
reason
to
be
able
to
move
through
that.
D
E
A
B
This
is
pretty
new
thing
to
you
know,
have
a
project
which
name
is
a
working
group,
so
this
is
the
question
I'm
asking
for
so
I
also
talked
with
alexis
before
for
this
thing.
I
think
his
answer
makes
sense,
because,
basically
we
want
to
have
very
useful
content
in
the
repo
of
the
working
group.
So
not
not
just
like
documentation
or
white
paper.
We
want
to
have
code
tools
and
framework
which
are
maintained.
C
B
Community
in
the
repo,
so
that
will
make
this
ripple,
have
the
potential
to
become
a
sandbox
project.
So
I
also
agree
with
that.
So
I
think
the
only
thing-
I'm
not
very
sure
or
I
don't
know
how
to
handle-
is
whether
we
should
split
them
out
as
a
project
which
has
a
name
for
project,
for
example,
potato
head
right:
we
can
give
it
a
name
and
then
donate
to
sandbox,
which
is
one
of
the
delivery
of
the
working
group,
or
we
just
want
to
donate
the
whole
working
group.
People
understand
our
project.
B
E
Out,
I,
I
can
imagine
a
scenario
where
you
have
almost
a
new
category
of
project
that
are
like
best
practice
kind
of
you
know,
because
that
that's
what
we
ultimately
are
trying
to
do
is
accomplish
is
like
people
are
doing,
get
ops
today,
and
people
are
doing
a
lot
of
things.
What
we're
trying
to
do
is
kind
of
come
up
with
this
framework
of
like
this
is
these
are
the
best
practices.
C
Where
yeah
that's
going
to
be
an
ongoing
statement
and
it's
going
to
have
to
be
maintained
and
updated
and
there's
going
to
be
ancillary
code
around
it,
but
it's
at
the
same
time.
It's
not
necessarily
like
a
binding.
It's
not
going
to
be
on
the
same
level
as
like
official
project
policy.
It's
just
kind
of
a
statement
of
a
working
group
of
this
is
our
opinion,
but
can
that
be
a
deliverable
of
a
project?
Maybe
that
needs
to
be
that
new
kind
of
project
that
you're
talking
about.
G
Yeah,
so
I
have
two
questions.
One
is,
I
guess:
what
do
we
get
by
making
this
working
group
a
project
instead
of
just
a
working
group,
and
then
second,
if,
like
this
working
group,
project,
eventually
delivers
code
and
tools
and
stuff,
like
that,
I
mean
how
does
that
relate
to
other,
like
non-working
group
projects
in
this
space
like
it
seems
like
it
would
get
like
some
kind
of
implicit
indoor
endorsement,
because
it's
like
a
multi-uh.
A
I
think
we
should
think
about
it,
because
cornelia
then,
like
flux,
is
a
githubs
project.
Argo
is
a
good
ops
project,
which
part
should
then
go
in
this
working
group
project.
We
need
to
discuss
right
now.
If
I
look
at
the
working
group
charter,
the
deliverables
are
more
best
practices
documents
and
there
are
more
documents.
G
F
G
F
I
think
that
there's
a
set
of
things
that
that
pre
preclude
that
that
come
before
tools,
and
that
is
a
whole.
I
I'm
very,
very
interested
in
examples.
Yeah
and
I
want
you
know,
sample
and
that's
part
of
the
reason
why
we
didn't
want
to
just
make
this
a
repo
somewhere.
We
wanted
to
have
a
get
ups
working
group
organization
in
github.
F
It
was
that
we
anticipate
having
multiple
repos
that
this
you
know
there
might
be
a
repo
here,
which
is
some
example
that
shows
you
exactly
how
to
do
things
a
particular
way
in
argo
cd.
It
shows
a
particular
you
know
best
practice
on
argo,
cd
and
another
one
that
shows
the
best
practice
around
flux
and
and
those
types
of
things.
So
we
we
want
this
to
be
largely.
You
know
enabling
enabling
users
to
make
the
most
of
get
ops
and
right.
A
F
G
Like
sandbox,
it
becomes
incubating
whatever
what?
How
would
you,
how
would
you
measure
the
adoption
of
a
working
group
project?
Is
it
based
on
the
documentation
but
like
I'm,
not
sure
how
you
like
it's
easy
to
measure
adoption
or
use
of
a
tool?
But
how
do
you
measure
the
adoption
of
a
process
and
determine
so
I
don't
know
if
a
working
group
style
of
thing
we
should
put
that
in
the
same
landscape
as
like
a
project
specifically
tailored
to
deliver
like
an
opinionated
way
of
doing
githubs
type
of
things.
G
F
Yeah,
I
mean
one
of
the
questions
that
I
have
to
is
to
the
folks
who
are
a
little
bit
more
familiar
with
this
whole
project.
You
know
progression
that
you
just
described
ed.
Is
there
a
notion
of
like
everything
that
becomes
a
sandbox?
Is
the
ultimate
goal
to
get
to
graduation
or
is
being
a
sandbox
project,
valuable
in
some
way
in
and
of
itself,
because
it
gets
back
to
your
point
ed
of
what
does
it
mean
for
this
to
go
through
the
graduation
process?
F
G
G
I
would
say
that
the
intent
of
most
projects,
as
far
as
I
know
and
becoming
a
stand-in
bus
project,
is
to
eventually
go
to
graduation
projects.
May
stop,
of
course,
short
of
that
also.
You
know,
I
guess
my
question
is
not
so
much
whether
there
should
be
some
type
of
maturity
framework
for
something
like
a
working
group.
You
know
and
as
amy
was
saying
you
know,
the
six
were
started
after
the
working
groups,
most
of
the
existing
working
groups.
G
E
G
E
What
if
we,
you
know,
we
came
out
with
something
like
15
factor
app,
you
know,
and
when
that
was
when
that
was
written,
there
wasn't
quite
a
cncf
thing,
but
but
it's
doing
it
as
a
you
know.
The
community
is
invested
in
these
patterns
and
is
invested
in
these
and
says
yeah.
This
is
the
way
that
this
is
the
way
right.
E
This
is
the
way
it
should
be
done
and
and
enough
people
have
tested
it
and
kicked
the
tires
and
worked
through
it
and
they've
found
that
if
you
follow
these
patterns
that
there's
security
improvements,
there's
productivity
improvements,
all
these
kinds
of
things
like
yeah,
I
mean
agree,
it's
a
little
weird
like
it's,
not
something.
That's
really
been
done
before.
G
Well,
the
other
thing
is,
of
course,
the
cncf
has
up
to
now
been
very
careful,
and
you
know
their
job
is
not
to
pick
winners
or
losers
right
to
endorse
one
opinionated
way
of
doing
things
versus
another.
On
the
other
hand,
there
are
benefits
to
you,
know,
standardizing
and
publishing
practices.
As
long
as
it
doesn't
exclude.
G
E
That's
a
good
point
and-
and
I
can
also
see
you
know
on
the
horizon-
there
are
these.
There
are
people
who
are
probably
thinking
about
you
know
if
you,
if
you
can
put
a
stamp
of
approval
and
you've
gone
through
the
process
with
the
community
of
making
this
practice
mature
and
making
sure
you've
thought
through
the
you
know
the
the
variables
and
stuff
I
can.
I
can
imagine
some
bank
out
there
being
like
oh
yeah.
G
E
B
B
Easier
to
understand,
if
there
can
be
some
code,
I
mean
some
kind
of
library
framework
or
even
some
command
line
tool.
That
would
be
also
helpful
to
see.
Okay,
this
is
a
project,
so
it
can
go
through
the
whole
process
of
the
sandbox,
even
graduation
someday.
That
will
be
also
helpful.
I
think
this
is
the
direction.
We
also
want
to
push
everybody
working
on
that,
so
what
kind
of
idea
we
can
have
in
this
repo?
B
E
E
Some
of
the
pain-
that's
happened
around
like
service
meshes
a
little
bit
like
like
trying
to
say
like
no.
This
is
like
this
is
like
kind
of
the
framework
in
which
you
know
we
can
work
and
we
can
compete.
We
can
play
and
we
can
agree
about
the
best
practice
and
stuff,
and
you
know
some
some
other
project
might
come
along.
That's
competing,
that's
better.
It
just
might
be
a
different
thing.
You
know
it
would
fit
still
under.
E
G
Yeah,
so
exactly
then,
like
you
know,
I'd
like
to
make
sure
that
say:
you're
a
githubs
project,
you're
not
participating
in
the
working
group
and
that
you
know
such
projects
are
not
fundamentally
disadvantaged
or
something
simply
because
they're,
not
you,
know,
participating
in
it,
because
the
tools
that
we're
developing
for
this
thing
only
there
is
very
focused
on
the
stuff
like
flux
and
argo
or
other
projects
that
are
actually
participating.
And
so
it
creates
this
barrier
which
prevents
innovation
in
the
future.
C
H
G
So
I
mean
it
brings
up
a
really
excellent
point
like
there
are
obviously
other
industry
groups
like
the
cdf,
that's
also
interested
in
space,
so
I
feel
like
if
the
get
off
working
group,
if
we
do
our
job
right,
it
will
benefit
everyone
right,
whether
or
not
you
are
a
member
of
the
cncf
or
the
working
group
or
if
you're
working
in
the
github
space,
it
should
benefit
you
if
it
only
benefits.
Members
of
the
working
group
then
we're
doing
a
terrible
job
right.
G
And
maybe
we
should
also
be
reaching
out
and
working
with
the
cdf
and
other
such
groups
to
make
sure
you
know
I
mean
if
we're
the
city
of,
and
we
are
both
working
on
it
and
trying
to
raise
the
votes
for
everyone.
We
can
obviously
get
a
bigger
outcome
than
if
we're
each
independently
working
on
our
own
and
then
at
some
point,
we're
gonna
try
to
get
our
mess.
Turn
up
the
volume
on
our
message
versus
someone
else's
message.
E
With
like
tracy
reagan
and
some
of
those
folks
just
talking
about
like
what
we're
doing
and-
and
there
was
a
question
early
on
about-
if
if
it
would
make
more
sense
in
the
cdf
than
in
the
cncf-
and
I
think
that
the
members
kind
of
felt
like
there
was
a
little
bit
more
support
for
better
or
for
worse
in
the
cncf
at
the
moment.
But
it's
not
like
there's
not
an
overlap.
I
mean
they're
very
overlapped
between.
E
H
G
And
david,
you
you're,
you
know
familiar
with
both
communities,
you
know
so
you're,
like
a
bridge.
In
a
sense,
you
know
between
some
other
stuff,
that's
happening.
More
of
us
should
probably
be
bridges
in
that
respect,
but
yeah
so
yeah.
So
how
do
we?
I
guess
one
question
is
like:
how
do
we
structure
this
so
that
it
benefits
everyone?
Whether
or
not
you
are
an
active
participant,
because
not
everyone
also
has
resources
to
actively
participate
in
all
of
these
activities
right,
it's
very
time
consuming.
G
G
G
I
E
It's
kind
of
it's
kind
of
it's
it's
it's
interesting
because,
like
git,
ops
is
very
clearly
something
that
would
fit
underneath
sig
app
like
within
sig
app
delivery
like
we're
we're
playing
in
the
same
playground,
but
you
know
sig
app.
Delivery
is
trying
to
solve
kind
of
different
scopes
of
problems
like
around
like
it's.
C
F
I
mean
one
of
the
things
that
I
have
to
say
is
that
I
am
not
hugely
concerned
at
this
stage
of
us
ending
up
doing
something
that
only
benefits
the
participants
of
this
working
group.
Because
of
the
things
that
we
have
defined
that
we
want
to
produce.
We
want
to
produce
white
papers,
we
want
to
produce
demonstrations,
we
want
to
produce
presentations,
we
want
to
produce
all
of
those
things,
we're
we're
about
producing
educational
materials,
and
so
I'm
not
worried
that
we
aren't
going
to
achieve
that
because
that's.
F
G
G
F
F
G
Yes,
because
at
some
point
like,
if
you're
a
vendor
you're
in
a
competitive
landscape
right-
and
so
if
one
vendor
is
a
member
of
the
working
group-
and
it
only
benefits
them,
then
it's
this-
you
know,
disadvantages
other
vendors
who
are
not
part
of
the
working
group.
So
I'm
saying
that
our
focus
should
be
to
lift
the
boats
for
everyone
right,
whether
you
are
an
actor
of
course
in
the
working
class
should.
G
E
E
You
know
like
the
people
that
were
on
the
call
and
the
the
get
ops
principles
that
we
discussed
and
the
the
outputs
that
we
discussed.
There
was
pretty
broad
consensus,
not
just
from
the
maintainers
but
very
much
from
the
whole
community.
That
was
participating,
and
it's
quite
a
few
people
I
mean.
So
I
felt
I
felt
good
about
it.
I
mean,
I
think,
we're
on
the
right
track
right
now,
but
we
should
definitely
be
mindful
that
there
are
some
potential
pitfalls
to
fall
into.
E
C
F
Responsibilities
are
to
say,
hey,
look
at
this
cool
new
project
over
here,
and
this
is
something
that
we
haven't
thought
about.
It's
it's
it's
it's
addressing
it's
providing
a
set
of
solutions
that
we
haven't
included
under
the
get-ups
umbrella.
Let's
and
it
shouldn't
to
your
point
ed.
It
shouldn't
be
that
that
project
needs
to
come
and
say,
hey,
please
consider
us.
That's
part
of
our
responsibility
of
the
working
group
is
to
stay
apprised
of
the
whole,
get
ops
landscape
and
include
things
whether
those
people
are
coming
actively
or
not
right.
C
Agree
if
I
can
jump
in
there
too,
I
think
one
of
the
one
of
the
things
about
that
is
maintaining
easy
on-ramps
for
people
to
reach
in
like
this
first
meeting
here,
and
the
reason
I'm
here
is
because
I
gave
a
talk
at
kubecon
and
thomas
shoots
reached
out
to
me
and
said:
hey
we're
working
on
this
white
paper
in
the
operator.
You
know
working
group
or
whatever
that
we
think
you
might
be.
You
know
have
some
contributions
on,
so
he
sent
me
a
google
docs
link.
That
was
it.
C
G
Right
so
yeah,
so
I
guess
one
area
of
slippery
slope
is
like
if
we
once
we
start
creating
tools
or
things
like
that.
Of
course,
some
of
these
tools
may
be
competitive
with
tools
or
other
projects
that
vendors
other
projects
have,
whereas
things
like
practices,
you
know,
and
so
on
and
so
forth.
Even
if
they're
opinionated,
I
mean
we
have
collections
of,
we
can
have
collections
of
these
things
and
some
of
them
may
be
contradictory
to
each
other
like
not.
G
All
of
them
can
be
the
best
best
practice
that
kind
of
asset.
You
know
anyone
can
like
leverage
and
use
so
there's
a
little
bit
of
like.
I
guess
you
have
to
think
carefully
about
what
kinds
of
activities
might
exclude
participation
versus
other
things.
You
know
everyone
can
benefit
from
and
I'm
you
know
like
if
no
one
is
interested
in
doing
some
diagnostic
tool
or
something
and
it
helps
the
industry,
then
you
know
it's
probably
in
a
fair
game
to
consider,
but
you
know.
E
Yeah,
I
I
view
it
as
like
if
we
push
these
get
off
standards
and
practices
and
we're
collecting
the
case
studies
and
we're
collecting
the
patterns
and
we're
agreeing
upon
them.
I
see
I
see
this
situation
where
all
these
companies
and
engineering
teams
who
are
looking
for
like
how
they
should
be
deploying
software.
Looking
at
that
and
they're
saying,
oh
look,
I
can
go
and
do
this
with
argo.
E
You
know
I
mean
I've
gone
through
the
process
of
setting
up
argo
and
and
flux,
and
they
have
different
degrees
of
opinion
on
them,
but
so
many
people
get
lost
on
implementation,
detail
that
they
can't
get
full
advantage
out
of
all
the
tools,
and
that's
like
you
know
if
I
understand
the
principles,
if
I
understand
the
patterns
I'm
going
to
adopt
it
quicker
we're
going
to
be
happier
as
a
team.
You
know,
I,
I
think
it's
a
huge
benefit
to
the
community.
D
B
Yeah
yeah,
I
think
it's
a
very
valuable
discussion
and
gave
me
a
lot
of
input,
so
I
think
from
my
side
I
mean
from
sensitive
side.
There
are
two
things
very
important
to
make
this
thing
successful.
So
first
we
need
to
establish
an
open
vendor
neutral
organization,
which
is
a
github's
working
group
under
cncfc
guide.
I
think
this
is
the
right
direction,
we're
going
we're
on
the
right
track.
The
second
thing
is
just
as
john
mentioned,
that
we
need
to
make
sure
that
the
contribution
bar
of
this
working
group
is
pretty
low.
B
You
don't
have
to
be
the
member
of
this
working
group.
We
don't
have
to
be
the
maintainer
of
this
working
group
to
contribute
to
ideas
or
be
part
of
that.
So
I
think
this
is
also
really
important.
That's
why
I
think
the
the
governance,
the
governance
and
the
chairs
election
yeah,
which
is
the
next
step,
also
important
that
we
need
to
make
sure
that
the
whole
working
group
has
a
right.
It
has
a
right
vision
and
has
a
right
kind
of
white.
B
My
side
to
set
the
bar
for
everybody
to
be
involved
into
this
working
group.
I
think
these
two
things
are
very
important,
based
on
the
today's
discussion
and,
as
they
think,
they've
see
that
literature,
I
think
me
and
the
lawyers
were
trying
to
make
sure
that
they
go
to
the
right
direction,
a
open
and
very
friendly
working
group
to
engage
everybody
from
the
community
who
are
interested
in
this
topic.
So
we
are
not
building
something
that
can
that
that
is
focused
on
certain
project.