►
From YouTube: CHAOSS Common Working Group Meeting May 25, 2023
Description
Meeting summary can be found here: https://chaoss.discourse.group/t/chaoss-common-working-group-meeting-summary-may-25-2023/151
A
Thank
you
all
for
coming
looks
like
we.
We
have
a
actually
had
some
pretty
short
agenda
today.
If
anyone
does
have
any
agenda
items
to
add,
please
feel
free
to
do
so,
but
with
that
I
suppose
we
could
jump
right
into
the
agenda
and
the
at
the
top
of
the
list.
We
have
the
there's
a
discussion
going
on
currently
about
context
and
and
keyword
keywords
in
the
metrics.
A
So
we've
been
talking
about
removing
the
the
context
and
keywords
from
the
metrics
pages.
The
keywords
themselves
do
appear
on
WordPress
so
like
for
the
keywords,
it
was
a
matter
of
duplication,
I,
suppose
open
that
up
for
discussion.
If
anyone
has
any
thoughts
on
it,
the
one
the
one
thing
I
would
say
about
the
context
and
keywords.
That
is
that,
if
determining
whether
or
not
they
are
included
in
the
the
metrics
pages
is
I,
think
it's
kind
of
depends
on
what
their
their
purpose
was.
A
B
B
So
that
is
my
first
thought
and
my
second
thought
was
like
in
the
past
we
had
a
synonyms
like
how
this
metric
is
similar
to
other
that's
where
we
wanted
to
keep
them
as
a
replacement
like
if
I'm
coming
with
some
other
context,
or
some
other
word,
that
I
want
to
include
or
review,
and
is
it
similar
to
that
metric
or
the
context.
So
maybe
these
are
the
two
reasons
that
it
is.
A
So
I
do
think
the
the
context
words
and
the
keywords
are
kind
of
two
different
issues.
For
me,
the
context
keywords
I
think
they're.
They
are
very
much
there
to
help
with
navigation
and
I.
Don't
yeah
I,
don't
have
any
I,
don't
have
any
questions
about
removing
them.
I
think
that's
removing
the
context.
Words
is
fine.
A
So
when
we
have
synonyms
keywords
are
where
they
go,
so
it
does
kind
of
become
the
the
the
that
keyword
line
does
kind
of
become
these
are
these
are
keywords
that
help
describe
the
metric
and
they're
they're
keywords
that
we
would
ask
the
we
would
ask
the
groups
to
to
set
when
they're,
creating
the
metric
I'm
once
again,
I
I'm,
not
I,
don't
have
any
strong
feelings
on
it:
I'm,
fine,
moving
them
completely.
I
just
thought
we
should
probably
discuss
the
purpose
of
them
first,
because
I
think
that's
relevant.
C
A
B
A
A
And
I
like
and
I
like
the
way
this
displays
I
do
too
and
I
also
and
I,
like
the
lack
of
repetition
and
not
having
them
in
the
page
it
it
really
is.
It
really
is
kind
of
comes
down
to
that
are
the
keywords
part
of
the
metric
specification
and
if
the,
if
the
keywords
are
part
of
that
metric
specification,
then
that
that
metrics
page
is
kind
of
it's
a
one-pager
right.
A
D
C
C
Yeah
I,
like
this
I,
like
this
design,
how
they
are
down
here
at
the
bottom
I
think
it
looks
good
I
think
it's
also
nice
because
it
ultimately
like
overall,
we've
really
been
working
to
clean
up
the
metrics
by
moving
that,
for
example,
that
disclaimer
down
to
the
bottom
trying
to
get
rid
of
the
synonyms
up
on
top
and
the
keywords
and
context
tags
up.
On
top.
There
was
just
so
much
going
on
in
the
metric
that
it
was
I
thought
sometimes
a
little
distracting
to
get
to
the
the
real.
B
B
A
A
Why
I
don't
I,
don't
actually
need
them
anywhere
else,
so
the
only
the
only
the
only
consideration
I
had
was
whether
or
not
they
belonged
on
the
the
metrics
page,
because
I
think
of
that
I.
Think
of
that
metrics
markdown
page
as
the
as
the
specification
that
we're
defining
or
creating
for
that
metric
right.
So
the
the
question
is:
are
those
keywords?
Are
those
synonyms
part
of
the
description?
A
A
So
if
we,
if
we're
just
creating
them
to
help
find
the
metric,
then
the
process
around
creating
those
metrics
and
putting
them
in
WordPress
can
be
kind
of
simpler
right.
But
if
it's,
if
it's
actually
part
of
the
specification,
then
it
it
I
think
there's
a
there's,
a
process
that
we
need
to
go
through
kind
of
like
as
part
of
the
template.
Basically.
C
A
So
I'm
I'm
questioning
whether
the
keywords
need
to
be
part
of
this
template
or
whether
we
can
just
remove
them
and
by
the
way
and
I'm
fine,
just
removing
them.
If
that's
the
consensus
and
I
think
that
I
think
that
is
kind
of
that
the
consensus,
so
it's
I
I,
like
the
clean
look
of
not
having
them
so
I,
just
I
just
wanted
to
make
sure
we
had
a
conversation
about
it.
C
A
C
A
A
Then,
when
we,
when
we
create
these
metrics,
we
do
need
to
make
sure
that
the
working
group
adds
them
to
the
Google
sheet,
so
I
mean
that
is
part
of
the.
That
would
be
part
of
the
the
metrics
definition
process.
So
if
we
have
that,
if
we
have
that
process
kind
of
documented
somewhere,
it
should,
it
should
say,
create
keywords
for
the
metric
right.
B
E
A
We
could
consider
I
mean
if
we,
if
we
want
to
document
this
process,
which
we
should
probably
take
parts
that
were
removed
and
add
them
into
maybe
a
separate
document
to
document
how
to
maybe
it's
maybe
that
maybe
the
document
is
how
to
how
to
create
a
metric
or
how
to
how
to
define
a
metric
so
I
know
there
is.
There
was
guidance
in
the
template
on
how
to
do
image,
links
and
I
know.
A
B
A
Yeah,
maybe
we
maybe
rename
this
to
metrics
release
checklist
or
something
like
that,
because
we
don't
really
do
the
the
candidate
thing
anymore,
yeah,
also
the
renaming
it
to
something
more
explicit
and
then
and
then
updating
the
list
so
that
it's
accurate,
so
I
think
a
couple
of
those
links
point
to
the
template.
Maybe
we're
used
to
point
to
the
template.
B
A
B
C
So
it
sounds
like
there's
a
few
things
here:
vanad
we
have
like
an
old
metrics
template.
That's
sitting
in
the
yep
in
the
metrics
folder
sounds
like
we
have
an
old
like
issue
template.
You
know
that
you
had
shown
here
that
we
have
revising
metric
template
like
this.
This
should
all
yes
be
brought
together
and.
B
B
A
B
B
B
A
A
F
They
just
copied
and
pasted,
and
then
you
know
they
feel
like
it's
been
tested
in
their
private
repo,
so
they're
just
going
to
merge
them,
which
is
not
a
healthy
thing
that
you
want
to
encourage
in
a
collaborative
project
right,
so
I
I
mean
I
want
to
in
terms
of
naming
I
think
code
review.
Health
is
more
more
positive,
I
mean
sell
merger,
it
just
sounds
sounds
negative.
F
So
and
then,
obviously
you
want
to
measure
this
see
a
trend
over
a
period
of
time,
because
if
it's
a
new
project
which
is
a
couple
of
people,
then
you
can
almost
understand
that
happening.
Although
you
don't
want
to
see
that,
but
it's
just
to
measure,
you
know
how
projects
have
evolved,
especially
as
they're
growing
like
it's.
It's
a
review
happening
on
a
regular
on
a
regular
basis,
or
is
this
I
think
Matt?
F
B
D
Aiming
at
code
review
health
is
that
I
think
that
there's
probably
other
things
that
we
could
measure.
That
would
also
indicate
code
review
health,
and
this
is
why
I'm
wondering
if
code
review
Health
might
be
a
metrics
model
and
something
around.
Maybe
we
rename
it
like
self-merge
rate
I,
agree
that
that's
kind
of
negative,
maybe
there's.
F
F
A
A
A
D
A
F
Yeah
I
mean
I've,
seen
cases
where,
like
it's
normal
for
submitters,
to
merge
or
merge
their
pull
requests
after
the
reviews
done.
I
still
think
that's
not
a
good
thing,
but
I
mean
first.
You
know
like
I
said
again:
small
projects
are
small
companies
is
somewhat
understandable
that
you
have
like
one
CTO
and
like
maybe
one
other
engineer,
that
you
can
conceivably
see
that
happen,
but
you
still
don't
want
to
see
that
after
the
project
grows
right
so.
D
Is
and
I've
also
the
other
the
other
way
I've
seen
this
happen.
That
is
not
necessarily
negative.
Is
that
I've
seen
a
couple
of
times
within
us
and
I've
discouraged
this?
So
we
don't
think
we
do
this
anymore,
but
within
the
cncf
tag
contributor
strategy,
sometimes
what
we
would
do
is
we
would
actually
review
the
pull
request
together
for
something
that
you
know.
We
really
wanted
more
feedback
on
and
we'd
review
it
together
in
a
meeting.
D
D
B
D
A
D
A
I
think
I
think
the
model
can
be
called
whatever
we
want
it
to
be
called.
It
doesn't
have
to
be
connected
to
the
if
it
was
if
we're
going
by
metrics
naming
it
would
have
to
be
like
change,
request,
review
health,
but
but
I,
don't
think
the
the
models
have
to
go
by
the
those
metrics
naming
conventions.
Oh.
F
C
F
B
C
F
B
B
C
F
A
D
C
And
this
is
something
Sean
has
been
talking
about
for
a
long
long
time,
taking
a
look
at
second
contributions.
Don
I,
don't
know
if
he's
ever
worked
with
you
on
that,
but
I
know
that
this
is
something
that
has
come
up
for.
I
feel
like
years
is
something
that
he's
been
kind
of
focusing
on
and
I.
Think
it's
just
it's
really
about
just
trying
to
identify
like
just
the
contributor
base,
and
just
whether
people
are
sticking
around
is
really
the
pretty
simple
premise:
yeah.
D
Yeah
I
mean
it's:
it's
related,
it's
different,
but
it's
related
to
the
model
that
grammar
Lobby
uses
where
it's
like,
you
know,
got
the
drive-through
contributors
or
what
they
call
Casual
contributors,
regular
contributors,
core
contributors.
So
these
are
like,
like
the
Casual
contributors
who
came
back.
B
C
E
A
C
A
So
I
I'm,
assuming
this
the
second
contribution
metric,
the
purpose
of
this
metric
is
to
see,
is
to
kind
of
determine
how
I
don't
know
how
welcoming
the
group
is,
or
if
the
community
manager
is
is
doing
things
to
try
to
build
the
community
is,
is
second
contribution,
a
measure
that
these
these
onboarding
mechanisms
and
the
welcomedness
of
the
community
is
is
good.
Is
that
is
that
what
we're
is
that?
What
this
is?
The
second
contribution
is
about
kind
of
a
a
measure
of
whether
or
not
we're
succeeding
in
in
onboarding.
C
I,
don't
yeah
I,
don't
quite
know
we
can
ask
Anessa
and
Melissa.
Those
are
the
two
folks
that
are
kind
of
leading
that
working
group
I
do
know
that
welcomingness
was
a
really
important
thing
for
Melissa
again
in
these
python
communities,
so
she
works
like
in
communities
like
pandas,
and
this
was
a
welcoming.
This
was
a
really
important
part.
D
That's
one
of
the
reasons
I
would
want
to
look
at
something
like
this
was
because
I
do
think
it
gets
at
how
welcoming
the
community
is,
because
if
somebody
shows
up
and
and
does
something
and
then
goes
away,
then
they
probably
either
either
they
didn't,
have
a
very
good
experience
or
it
was
just.
It
was
just
sort
of
a
one-off
and
they
don't
really
don't
really
care
about
the
project.
Okay,.
B
A
B
E
Trying
to
think
of
how
to
say
this
new
contributors
who
come
to
your
project
do
first-time
contributors
over
of
all
the
first
time
contributors.
How
many
of
those
folks
came
back
and
did
a
second
contribution
yeah,
or
is
it
just
a
count
like?
Would
we
care
about
percentage,
I,
guess
versus?
If
we
have
100
percent,
then
that's
great?
It
might
be
a
little
more.
That
I
was
just
thinking
that
might
be
a
little
more
applicable
across
projects
to
look
at
the
rate
versus
account.
B
D
D
D
E
That
would
be
another
curious
filter
to
look
at
like
if,
if
you
know
your
rate
is
90,
but
it
takes
three
years
for
someone
to
come
back
then
maybe
there's
a
steep
learning
curve.
But
if
it's
you
know
first-time
contributors,
but
then
in
next
month
the
you
know
the
90
have
come
back.
Then
that's
that's.
F
C
A
Yeah,
so
that
one
should
be
pretty
close
to
being
done
if
you
want
to
go
ahead
and
click
on
that,
so
the
event
location,
Equity
metric.
So
this
this
metric
is
actually
an
edited
metric.
So
previously
it
was
just
called
event:
location
and
we've
been
going
through
and
kind
of
defining
some
metrics
around
event,
location,
inclusivity
and
event.
Location
accessibility
is
that
the
other
one
we
did
so
Event,
Event
location
Equity
is
is
one
that
kind
of
came
from
that
right.
A
So
it's
a
it's
about
the
where
conference
events
are
located
and
all
and
it's
also
about
how
they
are
distributed
in
relation
to
the
community.
So
we've
been
working
on
this
one
out
of
the
Dei
working
group
for
the
most
part,
however
event
location,
the
the
metric
that
we
are
editing
is
actually
owned
by
Common,
so
we
we
defined.
We
originally
defined
this
metric
a
year
or
so
ago.