►
From YouTube: CHAOSS Common Working Group 3/17/22
Description
Links to minutes from this meeting are on https://chaoss.community/participate.
A
B
Yeah-
and
I
think
this
is
just
about
across
the
metric
working
groups-
yeah
like
how
to
involve
that,
because
the
folks
at
gremore
lab
label,
things
is
kind
of
unique
to
them
and
the
way
that
you
probably
label
things
is
unique
exactly,
but
I
do
think
the
metrics
working
groups
between
like
revisiting
metrics
or
candidate
release,
metrics
or
like
new
metric
idea.
I
think
that's
pretty
common
across
all
of
them
and
they,
I
think
they
should
work
the
same
way
like
yeah.
I.
A
B
All
right
so
looking
at
the
I
did
have
a
chance
to
talk
to
don
about
this
github
repo.
So
I
think
the
general,
the
general
approach
here
is
to
I
will
put
issue
in
in
pr
templates.
That
is
easy
enough
to
do
in
a
github
repo,
so
there's
no
problem
there,
and
so
those
issue
and
pr
templates
can
be
overridden
at
the
local
level.
You
know
I
mean
you
can
always
opt
to
not
use
them.
B
A
A
B
A
B
E
D
A
D
B
For
the
community
repo
and
for
the
auger
repo
and
for
more
library,
so
I'm
a
little.
I
don't
want
to
like
create
this
like
web
of
things.
You
have
to
look
at
first
and
then
you
know
how
there's
like
this
little
link
that
says,
create
blank
pr,
like
you
have
all
these
templates
and
then
you
have
this
link.
B
B
G
E
B
E
B
E
E
B
So
but
like
if,
if
there's
no,
if
there's
that's,
if
there's
a
name
conflict?
Okay,
but
if
there's
no
name
conflict,
the
org
will
just
show
up
as
a
new
issue
template
okay,
along
with
all
the
the
local
replo
issue
templates.
So
I'm
not
my
personal
take.
Is
I'm
not
super
inclined
to
do
this?
I
think
it
would
create
a
lot
of
noise
for
a
lot
of
people.
I
don't
know
what
the
other
people's
thoughts
are.
D
B
D
B
It
would
be
it,
there
would
be
three
reasons.
One
would
be
a
the
readme
can
be
distributed
that
way.
The
contributing
file
can
be
distributed
that
way.
Okay
and
then
it
also
allows
us
to
remember
that,
like
that
banner
that
we
could
have
at
the
org
level,
it
would
allow
us
to
do
that,
like
like
welcome.
B
D
B
G
G
G
D
F
G
G
A
G
D
I'm
just
not
sure
anyone's
using
getbook,
but
I
I
don't.
I
guess
I
new
years
new
users,
I've
talked
to
or
new
members
have
talked
to
haven't
they
haven't
found
getbook
generally.
If
I'm
looking
for
a
specific
answer,
as
a
member
of
the
group,
I
go
to
the
repo
rather
than
get
book,
so
I
just
I
haven't
heard
of
in
and
I
could
be
wrong.
Maybe
I'm
not
talking.
E
G
So
this
brings
up
an
interesting
question.
Then
my
feeling
was
that
the
community
handbook
would
be
the
single
source
of
truth
so
and
kevin's
nodding.
Okay,
so
in
the
dei
badging,
just
for
instance,
I've
been
trying
to
clean
those
docks
up.
There's
a
ton
of
duplication
and
I've
been
changing.
All
the
links
to
the
community
handbook.
E
B
Yeah
I
mean
I
love
the
handbook,
it's
a
great,
like
the
handbook
as
a
thing
like
having
a
community
handbook,
whether
it's
in
get
book
or
in
the
knowledge
base.
It's
super
important,
I
agree
and
it's
written
in
such
a
way
that's
really
accessible,
which
is
really
nice.
Like
I
don't
know
it's
kind
of
in
small
pieces
of
information,
it's
not
in
markdown.
It's
not,
and
it
just
looks
nicer,
so
I
would
like
to
with
the
knowledge
base.
I
think
you
know,
with
the
knowledge
base
I'd
like
to
kind
of
keep
that
same
look.
G
D
D
Saying
not
so
don't
don't
put
that
information
if
it's,
if
it's
project-wide
information,
don't
put
it
in
working
group
repos
make
sure
that
all
project-wide
information
lands
in
the
community
repo
so
that
the
community
repo
becomes
the
that
one
source
of
information
and
the
knowledge
base
will
just
go
in
and
grab
that
information
from
the
community.
Repo,
correct,
yep.
B
D
F
D
D
And
if
we
have
so,
we
we
can
kind
of
think
of
it
as
as
two
or
three
different
knowledge
bases
right,
so
we
it's
it
it'll
all
it'll
be
integrated
together.
So
you
go
to
one
page
and
you'll
have
the
options
to
to
go
down
these
different
rabbit
holes,
but
you
can
kind
of
think
of
it
as
different
knowledge
bases
for
different
things
right.
So
we
can
have
a
metrics
knowledge
base
and
we
can
populate
that
from
the
metrics.
We
could
have
a
metrics
model
database
or
a
metrics
model
knowledge
base.
D
C
D
B
Can
you
can
you
show
us
what's
in
your
head
and
then
secretly
show
us,
because
I
would
it
would
help
me
a
lot
it
really
like,
even
just
what
you
were
describing
helped,
but
if
I
could
start
seeing
even
just
a
visual
of
some
sort.
Okay,
because
fundamentally,
like
you're
gonna,
be
looking
for
ideas,
but
I
mean
clearly
you're
the
one
kind
of
leading
this
whole.
B
D
F
D
B
C
B
B
B
I
fixed
up
a
little
bit
of
text.
The
mesh
metric
issue
checklist
is
the
same.
The
metrics
model
template.
I
did
update
a
little
bit
to
kind
of
coordinate,
remember
how
we
decided
we
kind
of
like
this
design
we
were
talking
about.
I
changed
a
few
things,
so
you
can.
I
might
it
might
be
smart
to
just
merge
this,
and
then
we
can
finalize
kind
of
what
it
looks
like
as
a
potential
template
for
folks,
quick
question
before
you
know.
D
B
B
Document,
so
if
people
could
take
a
look
at
those
templates
as
soon
as
those
get
merged
into
the
community
repo,
I'm
actually
going
to
archive
the
metrics
repo
there's
nothing
else
in
there
at
this
point,
there's
like
a
readme
and
a
license
file
and
all
that
kind
of
stuff,
but
I'm
just
going
to
archive
that
because
there's
nothing
else
in
there
oddly
enough
and
then
the
privacy
and
ethics
document,
I
didn't
name
it
real
well
here,
but
the
privacy
and
ethics.
I
just
call
the
data
use
statement.
Is
this
all
right?
B
So
it's
all
here
and
it
should
be
good
to
go
so
then,
I'm
with
you
kevin.
We
need
to
update
that
that
block
of
text
with
the
link
to
this,
whatever
you
might
want
to
rename
it,
because
it's
not
really
data
use,
but
data
use,
awareness,
recommendations
or
maybe
data
use
statement,
is
fine
but
update
the
link.
B
B
I
just
think
it
would
create
a
lot
of
like
we
only
have
like
a
couple
weeks
left
in
this
review
period,
and
I
just
think
it
would
create
a
lot
of
noise
in
the
process
that,
because
the
translations
are
currently
happening,
I
see
you
nodding.
Kevin
translations
are
currently
happening.
I
think
we'd
have
to
reach
back
out
and
say
here's
a
whole
nother
thing,
and
I
think
we
could
just
catch
it
in
the
next
round
or
after
the
release.
B
D
D
B
F
A
A
A
E
G
A
G
D
So
as
we
go
through
and
review
these,
I
would
imagine
that
we're
kind
of
all
reviewing
them
a
little
differently.
So
for
for
consistency,
we
may
want
to
meet
like
when,
when
I
go
through
and
review
them.
One
of
the
things
that
I'm
looking
for
is
that
language
is
being
consistently
used
across
the
working
groups
right
like
the
we're
using
the
same
terminologies
and
if
metrics
are
mentioned,
that
were
that
we're
linking
to
them
so
that
that's
kind
of
a
specific
focus
that
I
have.
G
G
Matt-
and
I
did
talk
about
this
in
the
bei
working
group
yesterday-
a
little
bit
because
code
of
conduct
was
one
that
we
had
been
reviewing
in
earnest
and
so
code
of
conduct
out
of
it.
So
we
kind
of
have
us
a
lightweight
process
by
which
we
did
it,
which
was
essentially
just
reopening
the
old
issue,
adding
the
checklist,
the
new
quality
checklist
in
and
then
kind
of
going
down
the
list.
So
if
there
are,
maybe
we
need
to
add
that
to
the
checklist
kevin?
Do
you
think
so?.
G
G
A
A
D
A
D
D
D
H
G
D
A
G
G
F
E
E
C
A
A
A
But
I'd
have
to
search
through
the
metrics
to
see
if
we're
using
author,
submitter
or
some
combination
of
both
of
them.
Perhaps
one
of
the
review
activities
would
be
to
create
a
google
doc
with
a
glossary
for
terms
like
these,
so
that
we
are
able
to
identify
when
we
have
multiple
terms,
referring
to
the
same
thing,.