►
From YouTube: CHAOSS Common Working Group 4-29-21
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
We
have
actually
quite
a
few
people
on
the
call.
Are
there
any
any
people
who
are
new?
Who
haven't
joined
the
common
working
group
before
that
want
to
introduce
themselves?
You
don't
have
to
no
pressure,
but
if
you'd
like
to.
B
C
A
I
think
we
will
just
go
ahead
and
jump
right
into
the
atlanta,
and
first
thing
we
had
on
the
agenda
was
having
a
look
at
the
issues
and
prs,
so
one
of
them,
which
josh
just
mentioned
so
we
might
as
well
might
as
well
start
with
that
one
is
the
standardizing
of
the
readme
for
each
working
group.
So
josh,
do
you
want
to
just
kind
of
walk
us
through
this.
B
Yeah,
I
think
most
of
us
know
what's
been
going
on
I'll.
Just
give
a
quick
recap:
the
repositories
the
working
group
repository
specifically
have
a
different
structure.
Right
now
for
readme
files,
I
was
hoping
we
could
create
a
standard
one
that
could
be
followed
by
each
repository,
and
the
proposal
is
on
your
screen
of
the
structure.
B
C
I
was
actually
thinking
about
once
this
standard
read
b
is
made.
I
was
kind
of
thinking
about
taking
a
modified
version
of
this
and
actually
creating
a
page
for
it
on
the
website,
and
then
the
slack
channel
obviously
would
be
added
to
the
participate
page
but
yeah,
so
that
that
way,
kind
of
this
modified
version
of
the
readme
would
exist
on
the
website
as
well.
C
I
think
the
I
think
once
this,
I
think
this
would
be
this
particular
template
would
would
be
added
to
the
to
the
handbook
for
any
future
working
groups,
but
the
the
the
the
handbook
exists
within
the
governance.
Repost
of
the
governance.
Repo
is
actually
gonna,
probably
need
this
readme
as.
C
B
B
Yeah,
so,
regarding
the
contributor
section,
I
had
an
idea
that
instead
of
we
could
we
would
be
listing
each
maintainer,
but
we
could
also
create
a
team
of
them
for
each
repository.
C
You
know
in
in
a
prior
discussion
we
had
actually
had.
We
had
the
thought
of
not
listing
every
maintainer
for
every
admin,
but
having
each
working
group
nominate
two
individuals
to
be
the
contact
person
for
the
for
the
group
and
just
listing
those
two
people
on
the
readme.
Am
I
remembering
that
correctly
matt?
I
think
you
were
part.
F
A
Actually
wonder
if
we
should
do
some
do
this
a
little
differently
like
the
way
that
the
way
the
cncf
does
this,
for
example,
for
all
of
our
cncf
projects,
is
that
they
have
for
things
like
working
groups
there
there
are
chairs,
so
they
have
like
two
people
who
are
responsible
for
you
know
making
sure
the
meetings
happen,
making
sure
that
they're.
A
You
know
that,
basically,
that
everything
happens
within
the
working
group,
that's
supposed
to
happen
and
they
call
them
chairs,
and
those
are
the
people
who
are
listed
on
the
the
read
me
files
and
then
there
are
also
a
bunch
of
other
like
maintainers,
who
can
approve
and
merge
and
do
other
things
within
within
the
repositories.
B
G
C
C
So
the
the
website
maintains
a
list
of
all
of
the
contributors
to
the
chaos
project.
It
is
a
really
big
long
list.
C
C
Oh
no,
I
was,
I
was
not
saying
anything
I
will
say
something
now,
though,
the
one
one
caveat
for
that
is
that
it's
the
full
list
for
all
of
chaos.
It's
not
working
group
specific,
and
I
don't
think
that
matters.
E
H
H
C
So
as
you
as
you
know,
there
is
a
area
for
contributors
to
be
listed
on
individual
metrics
yep
and
I
think
that's
the
place
where
we
can
have
that
individual.
I
worked
on
this
thing
and
then,
as
far
as
the
the
working
group
goes,
I
think
most
people
belong
to
multiple
working
groups
anyway,
true
story,
so
identifying
them
as
a
common
working
group
contributor
doesn't
have
I
I
don't
know
that
that's
as
important,
so
I
think
just
pointing
to
the
full
contributor
list
from
the
working
groups
is.
H
I
would
then
propose
is
like
we
should
rename
it
something
like
contributors
to
the
chaos
project
and
provide
the
link
to
the
web
page
rather
than
just.
C
A
A
B
Not
currently,
we
do
not
have
a
timeline.
Okay,.
C
Are
there
are
there
documents
that
need
to
be
created
that
we're
going
to
point
to.
G
C
Right
so
every
working
group
has
a
contributor.md
file,
but
the
thought
on
the
region,
but
they
should
yeah.
The
thought
on
the
readme
is
that
we
point
to
one
master,
contributing
file
that
has
a
high
enough
high
enough
kind
of
general
directions
that
they
should
be
able
to
contribute
to
all
of
the
working
groups
right
and
then
the
the
the
contributor
file
within
the
readme
would
have
specific
directions
for
that
working
group.
But
it
would
also
point
to
the
the
high
level
how
to
contribute
to
chaos.
A
Oops
sorry,
I
went
on
mute
when
there's
a
siren
outside.
I
I
think
it's
similar,
so
the
cncf
projects
tend
to
be
very
different,
so
they
all
have
their.
A
A
That
code
of
conduct
in
the
repository
generally
just
points
to
the
cncf
code
of
conduct
and
says
we
follow
the
cncf
code
of
conduct.
You
can
find
it
here.
G
A
So
I
would
see
this
being
is
something
similar
we
could
put
that
way.
We
don't
have
duplicated
information
across
all
of
the
contributing
md
files
for
chaos
working
groups.
You
can
have
all
the
common
stuff,
not
common,
all
of
the
all
of
the
things
that
are
across
all
the
working
groups
in
one
main
document
yep
and
then,
and
then
we
can
point
to
it
from
these.
A
H
C
A
F
Am
I
mean
like
I'm,
because
I
I
I
hang
out
in
a
lot
of
working
groups
and
they
all
actually
run
like
really.
Similarly,
at
that,
like
98
level,
that's
hard
truth.
So
you
know
we
all
use
the
spreadsheet.
We
all
use
issues
and
pull
requests.
We
all
aim
towards
release.
We
all
use
google
docs
yeah,
I
mean
we
all.
We
do
all
these
things,
so
I'm
trying
to
even
think
like
I
was
trying
to
think
of
like
what
even
might
be
specific
for
common.
G
G
Does,
though,
I
think
if
they
have
a
standard
structure,
maybe
we
can
revis?
If
I
suggest
we
revisit
over
time
if
they
evolve
away
from
each
other,
because
I
I
don't
want
to
point
all
the
working
groups,
so
one
read
me
link
because
that
feels
like
it
could
become
chaotic,
but
the
minute
a
working
group
decides
they
want
to
do
something
a
little
bit
different.
C
H
I
think
like
read
me,
can
be
customized
based
on
the
working
group,
but
contributing
or
code
of
conduct
even
licenses.
These
three
files
needs
to
be
standard.
Entire
chaos
are
all
the
working
rules.
C
I
think
generally,
what
we're
talking
about
here
is
that
the
so
the
structure,
the
structure
of
the
readme,
needs
to
be
the
same,
but
the
structure
of
the
readme
will
allow
for
some
personalization
in
the
working
group.
C
Yes,
but
the
main
purpose
of
that
readme
is
also
going
to
be
to
point
to
the
shared
code
of
conduct,
the
shared
contributing
documents,
the
the
all
of
those
those
the
shared
process,
information
that
can
help
people
learn
how
to
participate
in
chaos
in
general
and
then
to.
C
H
G
Like
having
committing
contributing
code
of
conduct,
point
to
a
central
dock
somewhere
seems
okay
to
me,
because
those
probably
don't
change
very
often,
I
think
I've
seen
the
readme's
evolve
enough
over
time
that
I
wouldn't
want
to
make
it
like
just
a
here's,
your
readme
for
each
working
group.
Yet
anyway,.
H
Yeah,
like
I
participated
in
working
groups,
and
I
don't
see
these
files
like
contributing
code
of
conduct
files
or
license
files
ever
been
updated
in
the
working
group.
It's
just
there.
That's
where
I
was
proposing
like
yes,
we
keep
these
three
document
as
a
standard
document
and
point
to
the
main
repo
like
entire,
and
we
have
this
standard
format
of
readme,
with
the
flexibility
of
adjusting
for
each
group.
H
C
And
I
would
add
that
the
the
goal
is
to
reduce
duplication
for
most
for
documents
that
are
used
in
other
places.
So
the
the
question
should
always
be.
Does
this?
Is
this
document
duplicated
in
every
working
group
and
if
it
is,
can
we
create
a
master
version
of
it
and
just
point
to
it.
A
Yes,
so
I
found
an
example
here,
so
this
is
a
sub
provide
a
sub
project
of
the
kubernetes
community
and
that's
what
they've
done
so
that's
perfect,
for
they
have
a
contributing
md
file.
It
says
you
know:
here's
here's,
the
real
contributor
guide,
which
happens
to
be
the
one
under
kubernetes
community,
which
is
kind
of
the
sort
of
the
main
default
kubernetes
one
for
projects
that
don't
have
anything
specific
and
then
there
are
some
kubernetes
projects
that
are
very
specific.
So
I
was
just
looking.
F
A
No,
it
depends
on
each
each.
I
think
each
sig
working
group
handles
it
differently.
F
F
A
A
This
is
we
we
put
together
in
the
kubernetes
community.
A
very
specific
contributor
died,
so
this
is
the
contributing
files
are
part
of
this
guide,
so
some
people
use
this,
and
some
people
have
written
their
own
based
on
things
that
are
different
for
their
particular
group,
but.
F
A
F
Where
is
it
and
where
does
it
point?
Does
it
like
point
to
like
a
master
read
me
or
I'm,
I'm
sorry,
code
of
conduct
get
my
word.
Oh.
F
A
Exactly
and
then
for
the
for
the
common
working
group,
who,
who
would
the
chairs
be
I'm
obviously
happy
to
be
one
of
them,
but
I
would
need
a
co-chair.
G
F
G
G
A
Yeah,
okay,
that
makes
sense
to
me
yeah
any
any
other
questions
for
us
on
this
yeah.
B
G
C
That's
the
model
that
we
always
want
to
follow.
So
if
the,
if
a
document
exists
in
multiple
places
and
there's
there's
duplication
and
redundancy,
then
we
would
prefer
to
have
that
document
exist
in
one
place
and
just
point
to
it
and
right
now
I
think
what
we're
thinking
is
that
the
place
that
that
should
exist
is
probably
in
the
governance
repo
as
part
of
the
chaos
handbook.
A
F
F
I
think
okay,
so
at
that
point
I'm
guessing
it's
gonna
be
like
kind
of
thumbs
up
from
everybody
yeah.
I
think
at
that
point
we
could
just
start
rolling
this.
G
A
Perfect
thanks,
so
we
spent
we
spent
30
minutes
on
on
that
which
was
time
well
spent,
because
I
think
that
was
something
we
definitely
needed
to
go
through,
but
given
that
we
only
have
15
or
20
minutes
left,
are
there
any
of
these
items
that
are
on
the
agenda
that
are
super
urgent
that
we
have
to
do
today
or
should
I
go
back
and
start
going
through
the
issues
I
did
notice?
We
had
two
pr's
we
needed
to
look
at
so
unless
there's
anything
super
urgent
on
the
agenda.
E
Talk
about
this
issue,
please!
So
if
you
go
to
the
working
group
common
repository,
you
will
find
that
there
is
a
directory
called
template
folder,
which
actually
contains
two
markdown
files.
E
The
first
one
is
the
common
template.mb,
which
is
nothing
but
a
duplicated
matrix,
markdown
file,
it's
a
duplication
from
chaos,
matrix
repository
and
the
second
one
is
filename
convention.md,
and
I
have
already
duplicated
the
stuff
from
this
file
into
the
community
handbook
and
the
matrix
repository
and
they're
already
merged.
So
I
think
we
can
delete
this
directory,
so
I
made
a
pr
to
delete,
delete
this
directory
last
one.
A
E
E
F
Yeah
so
ritzik
are
there.
I
if
I
I'm
probably
wrong,
but
I
seem
to
think
that
common
and
dei
follow
a
similar
model.
E
And
that,
actually
there
is
inconsistent
inconsistency
in
the
common
one.
If
you
go
to
the
other
focus
areas
like
this
one
in
what
there
is
no
heading
on
the
top
of
the
readme
that
which
focus
group
this
is,
and
if
you
go
to
the
whole
one,
then
there
is
a
sub
heading
referring
to
the
who
focus
area.
E
H
F
C
C
Okay,
which
so
that's
fine,
and
that
does
that
matches
the
the
issues
that
we
we
have
with
with
redundancy
and
duplication.
C
The
the
editing
would
throw
off
the
the
editing
of
these
pages
would
throw
off
the
review
process.
A
One
of
the
things
we
could
do
that
would
help
this.
So
if
you
look
a
lot
of
the
a
lot
of
the
projects
that
I
work
on,
have
have
things
like
auto-generated
files,
for
example.
So
I'm
not
saying
we
should
auto-generate
the
focus
areas
files,
but
what
we
should
do
is
have
a
comment
at
the
top,
which
explains
how
the
file
needs
to
be
formatted
and
the
fact
that
it's
used
and
it's
pulled
into
the
release
and
to
give
people
some
some
guidance
about
updating
it.
A
So
in
this
one,
it's
like
don't
update
this
directly,
and
this
gives
you
a
link
to
the
place
where
you
go
to
to
update
it,
but
in
in
the
case
of
you
know
what
you're
talking
about
reddit,
you
could
put
your
instructions
in
here
that
say
you
know
this
should
not
be
a
there
shouldn't
be
a
header.
There
should
be
a
table,
there
should
be
whatever
it
is
that
you
need
in
order
to
make
the
release
automation
work,
we
should
document
it
in
a
comment
right
at
the
top
of
the
file.
E
F
C
I
got
you
okay
thanks
and
I'm
not
I'm
not
a
hundred
percent
certain
that
we
want
to
that.
We
want
to
pull
from
these
locations,
so
it
it
adds
complexity
to
the
review
process.
C
Particularly
for
this
process-
yes,
that
would
be
that
would
be
my.
That
would
be
my
preferred
method
to
to
combine
all
of
the
all
of
these
focus
group
readmes
into
a
into
another
markdown
document
and
pull
it
from
there.
B
C
So
pulling
pulling
from
the
metrics
tables
file
so
that
that
file
does
it
adds
an
element
where,
where
a
human
being
has
to
be
involved
in
the
release
process,
to
kind
of
sign
off
on
the
release.
C
So
that's
a
little
bit
more
work
for
a
person
and
it
removes
some
of
the
automation,
but
I
think
it
helps
with
the
review
process
and
the
and
the
creation
of
the
the
release
notes
as
well.
C
C
But
I'm
open
to
discussion
on
that
we
can.
We
could
talk
about
that.
The
the
common
common
working
group
discussion
with
us.
A
Okay,
well,
why
don't?
Why
don't
you
all
chat
amongst
yourselves
and
figure
out
what
you
need
to
just
confirm
what
you
need
to
do
for
the
for
the
release
process
and
then
and
then
come
back
and
let
us
know
if
there's
anything,
we
need
to
do
to
change
our
focus
area.
Read
me
files.
F
A
Yeah
absolutely
and
my
take
on
this
was
let
us
know
how
we
can
help
make
your
life
easier.
So
let
us
know
if
there's
anything,
we
need
to
change
we're
happy
to
do
that.
C
Standard
templates
make
the
entire
process
easier
and
there's.
Certainly,
there
certainly
is
room
where
we
could
pull
these
readmes
in
an
automated
way
into
the
master
document
that
we're
talking
about
okay,
but
for
the
release
itself.
I
would
prefer
not
to
pull
from
from
these
individual
readmes.
I
would
prefer
to
pull
from
that
other.
The
master
document
that
we're
talking
about
so.
D
A
Okay,
well,
like
I
said,
let
us
know
if
there's
anything
we
need
to,
we
need
to
change
so
that
was
let's
see
so
this
issue
is
this:
is
this
just
this
issue
is
over?
I.
A
There's
one
more
pull
request:
let's
look
at
that.
First
added
the
full
code
of.
A
A
Okay,
so
who
does
somebody
want
to
volunteer
to
sort
this
out.
F
H
B
I
think
that
it's
not
that
big
of
an
issue,
because
when
we
add
the
readme
at
that
time,
we
can
directly
delete.
You
know,
delete
the
full
thing
and
just
add
two
three
lines:
exactly
yep
cool.
C
Because,
just
through
just
through
this
conversation
today,
we've
identified
what
a
readme
template
a
contributing
template,
a
code
of
contact
template
a
they
have.
F
A
handbook
handbook,
that's
it
that's
the
only
folder
any
other
stuff
is
like
some
room.
Metrics
templates
yeah,
the
metrics
template
currently
sits
in
the
metrics.
The
slash
metrics
place.
F
H
A
Okay,
we
are
just
about
out
of
time.
Do
we
have
georg
on
the
call?
No?
No
okay,
so
we'll
skip
this
one?
I
think
we
talked
about
it
last
time
and
then
the
release
notes,
that's
one
that
stays
open,
and
then
these
are
new
metrics
that
were
on
the
agenda,
but
that
we
didn't
didn't
get
to
this
time.
So
hopefully
we
can.
We
can
do
this
next
time
gosh.
I
hope
someone
was
taking
notes
because
I
was
not
were
there
any
action
items.
F
F
Just
a
sense
of
maybe
how
you
would
plan
on,
I
mean
it
shouldn't
be
that
complicated,
so
just
the
timeline
has
included
so
far.
Unofficially,
I
think
you
attending
pretty
much
every
working
group
meeting
and
kind
of
circulating
this
idea
and
getting
feedback
which
is
awesome.
C
C
C
Yeah
so
convert
this,
convert
this
into
a
markdown
file
and
put
it
into
the
the
governance
repo
in
a
templates.
C
C
And
then
from
there
we
can.
We
can
get.
C
C
And
those
templates
will
be
smaller
because
the
the
contributing
is
basically
just
going
to
be
a
pointer,
a
temp,
a
template,
a
template
file
that
basically
just
has
pointer
information
that
points
to
the
code
of
conduct
or
the
contributing
documenter.
B
A
A
Okay,
I
think
that's
probably.
A
So
what
I'll
probably
do
is
move
move
the
agenda
items
that
we
didn't
get
around
to
and
just
move
those
to
the
the
agenda
for
the
for
the
13th
and
feel
free
to
add
things
to
the
agenda
that
we
need
to
talk
about
on
the
on
in
the
next
meeting
as
well.
C
A
A
Okay,
now
that
we're
out
of
mushroom
hunting
news
thanks
everybody
for
participating.
This
was
a
super
productive
meeting
which
I
like
to
see,
and
everybody
have
have
a
good
day.