►
From YouTube: CHAOSS Common Working Group Meeting, August 3, 2023
Description
Meeting minutes are here: https://docs.google.com/document/d/1xsii5tfmmDwWpuhrFcBJMeYeT3RipJdiCdHrbi0NalQ/edit#heading=h.n3rh3l1y6dv7
Meeting summary is here: https://chaoss.discourse.group/t/common-working-group-meeting-august-3-2023/229
A
All
right,
hi
everybody
Welcome
to
the
chaos
Community
or
wait.
No
chaos
common
I
mean
it's
great
to
see
everybody
great
to
see
new
faces
as
well.
So
thanks
for
joining
us,
so
I
this
first
part
of
it
with
respect
to
Gary
I,
think
we'll
just
kind
of
hold
off
on
that
for
just
a
second
so
that
he
can
kind
of
take
a
look
at
that
and.
A
A
D
A
Okay,
so
the
request
is
for
each
of
the
kind
of
coming
out
of
common
for
each
of
the
working
groups
to
reflect
on
who
those
chairs
are
and
do
updates
as
needed
to
your
readme
files.
Just
to
reflect
that
and
gone
were
we
gonna
and
Elizabeth?
Were
we
gonna
have
kind
of
a
single
document
that
lists
everybody
was
at
the
plan
or
no.
E
C
Thought
it
was
probably
better
just
to
have
the
chairs
defined
in
the
working
group
repositories
or
whatever,
whatever
place
the
working
group
does
that
work,
so
they
don't
have
to
update
it
two
places
and
so
that
it's
in
the
place
where
they
see
it
more
often,
because
realistically
people
will
never
go
to
that
that
other
doc,
unless
they're,
looking
for
something
specific,
so
it'll
get
out
of
date.
If
we
have
it
separate.
B
B
B
A
D
E
A
You
that
are
not
familiar
with
chaos
Liaisons.
The
idea
here
is
that
we
have
three
chaos
context
groups.
In
those
chaos
context
groups
are
corporate,
ospos,
University,
open
source
program
offices
as
well
as
scientific
software
communities,
and
we
could
yeah
and
as
part
of
that
as
part
of
those
context,
groups
we're
asking
for
conversations
to
occur.
That
would
be
around
things
like
what
are
the
metrics
and
metrics
models
that
are
useful
and
meaningful
in
a
corporate
ospo
setting
or
what
are
the
metrics
and
metrics
models
that
are
useful
and
constructive
in.
A
Setting
and
within
each
one
of
these
context,
groups
we're
trying
to
abstract
the
kind
of
the
mechanics
of
the
chaos
project
so
that
within
those
those
two
week,
every
two
week
meetings
and
maybe
even
on
slack,
the
discussions
can
be
fairly
high
level
and
and
flowing
such
that.
The
participants
in
those
meetings
don't
have
to
worry
about
how
to
say,
create
a
metric
or
how
to
create
and
publish
a
metric
model
kind
of
the
the
details
that
go
into
that.
B
A
So
the
request
is
for
four
meetings
per
year
and
a
number
of
the
the
liaise
or
a
number
of
the
context
groups
have
more
than
one
liaison,
so
I.
Think
coverage
should
be
provided
by
those
two
people
pretty
easily
across
those
four
meetings
and
then
joining
the
respective
slack
channels.
So
for
the
respective
context
group,
and
then
this
slack
Channel,
as
well
as
the
metrics
model
slack
Channel.
A
A
A
So
the
hope
is
is
that
the
liaison
can
not
only
bring
the
metrics
or
metrics
models
that
are
discussed
in
the
context
working
groups,
the
again
the
corporate
osbo
scientific
software
or
university
hospital
kind
of
bring
those
to
these
meetings.
The
common
and
Metric
model
meetings
and
kind
of
present
what
the
the
model
is
and
what
the
thinking
was
from
that
context
behind
the
model
or
the
metric.
A
A
Here's,
how
we
understood
this
metric
or
metric
model
and
kind
of
iterate
on
you
know
the
motivation
wasn't
quite
clear
or
the
audience
isn't
quite
clear,
whatever
needs
to
be
iterated
on
and
again
bring
it
back
here
to
this
group,
and
we
can
continue
to
to
advance
that
metric
and
Metric
model.
So
that's
the
intention
of
the
work.
D
A
All
right
and
then
I
did
have
this
last
thing.
I,
don't
know
that
this
is
terribly
relevant
Elizabeth.
You
may
speak
to
this
because,
like
publishing
the
metrics
and
metrics
models
at
that
point,
when
the
metric
is
like
done
from
this
group
and
kind
of
done
from
the
context
group,
I,
actually
kind
of
feel
it's
just
handed
off
to
like
you
or
Kevin
for
publication-
is
that
right.
F
B
A
F
F
F
E
D
A
B
F
A
D
D
A
F
A
B
F
A
A
C
Yeah
I
mean
the
university.
The
context
working
groups
aren't
aren't
intended
to
develop
metrics
right,
so
the
metrics
happen
and
one
of
the
metrics
working
groups
each
of
the
metrics
working
groups
does
have
their
own
repository.
So
it
feels
like
creating
bringing
back
the
metrics
repository
would
possibly
create
more
work
and
confusion
than
than
the
issue.
We're
trying
to
solve.
D
C
A
D
D
A
B
A
G
I'm
here
and
embarrassed
I
volunteered
to
moderate
and
then
I
was
like
it's
at
12
right
and
then
Elizabeth
pinged
me
and
I
was
like.
Oh
okay,
it's
all
right,
yeah!
Well,
you
know
I
thanks
for
thanks
for
coming
back
to
it.
So
I
have
four
models
that
form
a
supermodel
that
we
have
talked
about
in
a
couple
of
working
groups
and
I.
Understand.
I
should
bring
it
here
to
talk
about
it
a
little
more
formally
as
like.
Does
this
fit
as
a
metrics
model
or
not?
G
There
was
a
bunch
of
feedback
that
I
have
gone
through
from
various
folks.
I
know
some
of
the
folks
in
this
call
have
had
a
read
through,
and
some
grammar
checking
and
some
commentary.
Eric
Sorensen,
notably
also
gave
me
some
of
his
input.
So
I
guess
what
do
these
need,
or
what
should
I
be
doing
to
kind
of
move
them
forward
or
kind
of
like?
Do?
They
need
more
discussion?
G
A
A
G
A
B
G
G
E
A
E
A
C
A
Of
so
we
have
a
couple
here
that
are
doing
the
same
thing:
okay,
okay,
well,
I
mean
if,
if
we
are
comfortable
and
you're
comfortable
Gary
as
the
author
of
these-
and
you
feel
like
you've
received
enough
feedback
and
it's
positive
really
are-
are
paths
to
publishing.
Metrics
models
is
typically
lower
because
the
intention
is
to
get
them
out
there
and
to
get
the
conversation
started.
A
E
E
I
just
noticed
that
in
some
of
the
metrics
model,
definitions
there's
some
reuse
of
metrics
across
the
four
categories
and
if
you're
releasing
it
as
like
a
super
model,
then
that
might
be
a
little
confusing
to
some
to
have
that
redundancy
and
so
not
to
say
that
those
aren't
important
for
how
you've
grouped
them
and
like
understand
conceptually.
While
you
would
have
say
something
like
libyers
listed
in
multiple
categories.
E
But
that
might
be
something
that
you
cover
sort
of
in
the
super
model
around
acknowledging
the
redundancy
and
maybe
the
way
that
it's
grouped
or
organized
and
the
presentation
can
help
the
reader
acknowledged
that
there
is
some
because
I
feel
like
in
in
a
perfect
world.
There
would
be
a
complete
exclusivity
across
all
the
metrics
used
in
a
related
model.
E
Knowing
that
someone
might
pick
one
of
these
and
not
all
of
them,
then
that
there's
reason
then
to
repeat
I,
just
think
that
it's
like
a
very
small
logistical
thing
that
you
might
be
able
to
cover
in
just
the
way
that
it's
presented
and
organized
versus
how
it
is
right.
Now,
where
it's
kind
of
folded
in.
G
E
Yeah
I,
agree
and
I
think
that's
that's
really
in
the
way
the
metrics
are
defined,
like
maybe
just
put
the
common
things
at
the
bottom,
or
something
like
that
and
acknowledge
that
they're
repetitive
and
then
in
the
I,
really
like
this
idea
of
a
blog
post,
because
I
do
think
having
some
way
to
show
all
these
things
connecting
and
providing
a
little
bit
more
like
context
that
isn't
really
warranted
in
a
strict
definition.
So
I
I'm,
basically
just
reiterating
it
I
like
this
path
and
go
forth
and
conquer.
G
F
And
then
we
talked
about
with
the
one
who
he's
working
on
One,
Stop
blog
post
is
written
and
published.
We
can
link
that
to
each
of
the
models
in
this,
so
that
there
is
some
kind
of
other
tie-in
for
people
who
are
just
going
to
that
and
not
might
miss
the
blog
post.
So
we'll
we'll
link
that
as
soon
as
it's
published
does
that
make
sense.
G
F
A
D
A
A
F
A
A
Yeah
yeah
and
then
Gary,
it's
just
waiting
for
Elizabeth
and
then
writing
a
small
blog
post
and
just
mechanically
I.
Think
Elizabeth
tell
me
if
I'm
wrong,
but
this
can
just
be
written
in
Google
Docs
and
then
just
share
the
link
with
Elizabeth
and
it
could
be
published
as
a
blog
post.
So
there's
nothing
difficult
about
it.
Yep.
F
B
A
G
Man
so
I'm
not
familiar
with
this,
but
this
appears
to
be
self
merge
and
merge
without
review
rates.
Another
model
that
we
are
looking
at
there's
plenty
of
comments
still
left
on
this
document,
so
it
might
be
related
to
the
change
request.
Reviews
metric
seems
like
we're,
bringing
it
up
as
kind
of
does
this
fit
neatly
alongside
change
request
reviews.
Is
this
complementary
in
some
way
has
anybody
had
a
chance
to
look
at
it,
or
maybe
we
can
take
a
couple
minutes
here
and
contemplate
out
loud.
C
B
F
C
C
G
Yeah
I
think
the
one
thing
that's
worth
pulling
apart
is
that
this
is
definitely
a
subset
of
change
requests,
reviews
in
the
way
that
it
doesn't
have
a
review
and
then
even
further.
You
can
dice
it
up
as
I've
merged
it
myself
without
it
being
reviewed,
because
you
can
do
a
self-merge
when
it
was
reviewed
or
you
can
do
emerge
where
it
wasn't
you
that
merged
it,
but
it
was
review,
it
wasn't
reviewed.
C
Yeah,
that's
a
really
good
point:
I
mean
I
in
other
communities.
We've
occasionally
talked
about
a
metric,
gotten
consensus
and
not
a
metric.
Sorry,
a
PR
talked
about
a
PR,
gotten
consensus
on
merging
the
pr
and
then
the
person
who
created
it
just
went
ahead
and
merged
it
because
we
talked
about
it
in
a
meeting
we
had
consensus,
so
it
had
reviews
by
a
bunch
of
people,
but
you
know
it
doesn't
really
look
like
it
and
get
home
and.
C
So
I
think
you're
right
I
mean
there
are.
There
are
a
bunch
of
use
cases
I,
don't
know,
I
think
it's
important
that
I
really
want
to
bury
it,
and
you
know
underneath,
like
the
change
request,
reviews
because
I
feel
like
this
is
it
is
sort
of
a
special
case
of
it
maybe,
but
it's
it
feels
a
little
bit
different
to
me.
Anyways.
E
I
have
two
thoughts,
one
it's
very
much
dependent
on
community
size
like
if
you
don't
have
anybody
else.
Working
with
you
then,
like
this
metric,
won't
mean
anything
because
clearly,
you're
gonna
be
verging
all
your
own
stuff,
but
as
your
community
get
larger,
then
it's
also
an
indicator
in
the
security
best
practices
badge
in
the
openssf.
E
In
that
we
want
more
things
to
be
reviewed,
because
it's
generally
a
better
practice
to
have
someone
else.
Look
at
the
thing
you're
about
to
put
into
the
code
base.
So
it's
usually
an
indicator
of
better
security
practices
or
just
general
development.
Better
practice
to
have
other
people
review
your
code,
so
I
think
it's
also
an
indicator
of
community
maturity.
E
If
there
is
a
process
that
ensures
that
everything
is
being
reviewed
before
it's
being
merged,
so
I
I
generally
think
it's
it's
a
metric,
that's
used
in
other
things
already
because
I
say
like
the
best
practice
is
bad,
but
I
would
again
like
caveat
it
with
the
depends
on
community
size,
because
you
only
have
a
couple,
a
handful
of
folks
in
the
community
or
project.
Then
not
everything
is
going
to
get
reviewed
just
because
of
functionality.
C
Yeah
and
I
feel
like
this,
so
so
this
is
a
metric
that
we've
talked
about.
I,
don't
know
if
it's
talked
about
when
I
was
off
in
July,
but
we
talked
about
it
a
lot
in
a
couple
of
different
meetings.
I
think
before
before
that
and
I
feel
like
we
we've
gotten
to
the
point
where
we
almost
continue
to
talk
ourselves
in
circles
around
this
metric
and
not
actually
coming
to
any
consensus
about
what
we
should
do
with
it.
C
So
it
feels
like.
Maybe
we
should
pick
something
make
a
decision.
It's
not
going
to
be
perfect,
you
know
do
we
do
we
split
it
into
two?
Do
we,
you
know
make
it
a
subset
of
something
else,
but
I
think
I
think
at
some
point
we
just
need
to
kind
of
make
a
decision,
so
this
metric
can
actually
proceed
because
I
feel
like
this
is
something
that's
been
waiting
on
a
decision
for
quite
a
long
time.
A
Agreed
my
thoughts
on
that
is
that
it
should
proceed.
There
does
seem
to
be
enough
conversation
that
it
is
of
interest
to
people
in
these
different
contexts,
and
there
certainly
are
like
some
of
these
caveats
associated
with
it
like
Community
size
and,
as
you
talked
about
Don
like
the
self-emerges
that
can
happen
based
on
in-person
reviews
that
we
don't
see
in
the
pr
itself,
but.
B
A
A
C
D
A
These
concerns,
without
like
going
over
the
edge
like
you
know
like
this
metric
may
not
be
useful
here,
and
it
may
not
be
useful
there
because,
as
you
say
done,
a
lot
of
our
metrics
are
not
useful
in
all
situations,
and
that
would
be
kind
of
a
weird
addition
to
add
to
our
metrics.
So
let
me,
let
me
take
it
on
as
an
action
item
to
clean
it
up,
bring
it
here,
probably
one
last
time
and
with
the
intention
of
signing
off
on
it
and
Publishing
it.
How
does
that
sound?
A
E
D
A
C
E
A
E
A
C
G
A
D
E
It
actually
isn't
in
it
the
other
one
was
in
it.
It's
the
merge
without
review.
That's
in
the
open
ssf.
It
says
the
the
metric
is
at
least
50
of
all
modifications
are
reviewed
by
another
is
part
of
the
the
metric
to
achieve
gold
status
in
the
security
best
practices
badge.
So
it's
it's
the
the
filtered
metric,
not
the
direct
metric,
so
self-merge
would
actually
be
distinct.
But
if
we
do
talk
about
merger
that
review
in
the
same
place,
that's
I
just
linked
the
the
GitHub
repo
for
that
description.