►
From YouTube: CHAOSS Common Working Group March 2 2023
Description
Minutes from this meeting can be found here: https://docs.google.com/document/d/1xsii5tfmmDwWpuhrFcBJMeYeT3RipJdiCdHrbi0NalQ/edit
A
B
C
It
be
embarrassing
to
say
it
was
only
maybe
one
or
two
years
ago
for
me
no.
C
A
A
Probably
had
like
oak
trees,
which
are
great
for
climbing
all
right,
so
today
we
have
a
couple
things:
it's
kind
of
metric,
so
just
as
a
reminder
to
everybody,
the
Common
working
group
is
is
kind
of
starting
to
serve
as
a
place
where
metrics
can
be
developed
and
those
metrics
are
the
metrics
that
may
come
from
the
metrics
model.
Working
group,
for
example,
you
know
that
a
metric
model
is
put
together
and
a
metric
would
be
useful,
but
it
doesn't
exist
in
chaos,
and
so
this
is
really
the
place
to
start.
A
I
think
start
that
conversation
I
also
think
that,
as
we
build
out
the
user
groups
like
with
the
you
know
the
to
do
group
The
aspo,
to
do
group
working
group
and
Hospital
plus
plus
on
the
University
government
side.
But
a
lot
of
those
conversations
are
probably
going
to
be
a
bit
like
more
strategic
or
a
little
bit
higher
level
and
less
about
like
focusing
on
opening
up
a
new
markdown
file
and
and
typing
and
so
I.
A
So
I
think
this
is
great
for
common,
but
it's
just
something
we're
gonna.
We
need
to
be
aware
of,
because
I
do
think
this
group
is
going
to
be
developing
it's
probably
more
than
any
other
group
and
on
that
note,
there's
a
metric
that
needed
to
be
developed
as
part
of
a
metric
model.
A
So
I'll
just
give
a
little
bit
of
background
on
this
and
Don.
You
can
chime
in
too,
of
course,
but.
D
Oh
okay,
yeah
absolutely
so.
This
came
up
because
in
the
metrics
model
meeting
we
were
reviewing
a
PR
for
Compass,
where
Yahoo
was
showing
us
how
he
was
implementing
the
metric
model
and
he
had
some
some
questions
and
particularly
around
the
time
to
close
metric
and,
as
we
were
discussing
the
time
to
close
metric.
That's
currently
in
the
metrics
model,
the
starter
project,
Health
metrics
model.
D
What
I
realized
was
that
time
to
close
wasn't
actually
the
metric
that
I've
been
using
and
that
I
kind
of
described
the
metric
model
I
used
it
I
think
because
it
was,
it
was
relatively
close
and
I
thought
it
kind
of
served,
maybe
the
same
purpose
as
as
the
metrics
that
that
I
use,
but
but
the
more
we
talked
about
it.
D
D
B
A
A
D
And
so,
if
you
look
at
like,
if
you
scroll
down
in
the
metrics
model-
and
you
look
at
the
time
to
close
this-
isn't
actually
this
doesn't
have
anything
to
do
with
time
to
close.
So
so
the
graph
that
I'm
using
really
does
not
reflect
the
and
as
I've
described
it
also
doesn't
isn't
the
time
to
close
metric
so
I'm
not
sure.
Frankly,
what
I
was
what
I
was
thinking
there,
but
but
anyways,
so
we're
gonna
we're
gonna
rewrite
it.
D
So
what
I
really
want
is
what
I'm,
calling
keeping
up
with
change,
requests
and
I
am
I
would
be
super
happy
if
someone
else
came
up
with
a
maybe
a
better
name
for
that,
because
I'm
not
I'm,
not
sure
for
for
the
metric.
But
the
idea
is
that
the
the
question
it's
designed
to
solve
is:
is
the
project
keeping
up
with
change
requests,
so
pull
requests
or
merge,
requests
and-
and
you
can
see
in
the
description
I
mean
it-
has
lots
of
benefits
but
I
think
the
two
primary
ones
are.
D
The
contributors
benefit
from
actually
getting
a
decision
about
their
contribution
and
change.
Requests
are
less
likely
to
have
merge
complex
if
they're
dealt
with
more
quickly.
So
I
think
this
serves
the
project
in
a
couple
of
different
ways,
and
so
I
highlighted
a
couple
of
objectives.
I
suspect
there
are
more
so
maybe
when
we
look
at
this
I
think
that
all
of
you
will
probably
have
other
ideas
for
for
objectives
for
this
metric,
but
the
primary
one
and
the
one
that
I
look
at
most
closely
is.
D
It
helps
me
know
whether
a
project
actually
has
enough
people
and
in
particular,
maintainers
to
keep
up
with
change
requests
and
also
just
measuring.
This
also
encourages
maintainers
to
close
change
requests.
It
will
not
be
merged
because
those
often
involve
difficult
discussions
and
people
tend
to
put
them
off,
and
that's-
and
in
my
experience
when
you
end
up
with
a
gigantic
pile
of
neglected,
pull
requests.
D
It's
usually
because
people
don't
want
to
have
those
conversations
about
closing,
pull
requests
that
can't
be
merged
for
whatever
reason,
and
then
the
third
one
I
think
is
I
thought
there
was.
D
I'd
put
a
comment
because
I
said
especially
participants
from
underrepresented
groups
and
I
think
that
there's
probably
a
better
way
to
say
that
maybe
I
accidentally
closed
my
comment,
but
this
is
the
the
Dei
piece
of
it
that
you
know
these.
These
neglected
change
requests
can
drive
people
away
from
the
project
and.
D
I
suspect
that
this
would
be
more
more
prevalent
with
participants
who
are
from
underrepresented
groups
or
I.
Don't
know,
I
feel
like
that's,
not
quite
the
right
way
to
say
that
so
I'd
be
I'd,
be
happy
to
have
someone
reward
that
and
then
the
way
it's
measured
is
by
comparing
the
total
number
of
open,
merge
requests
during
a
specified
time
period
with
the
number
of
merge
requests
that
were
closed
during
that
same
time
period.
D
So,
projects
where
the
two
values
are
really
close
together
are
keeping
up
with
change
requests
because
they're
closing
most
of
the
open
full
requests
during
the
time
period.
So
the
total
number
of
open
merger
requests
is
always
going
to
be
larger
than
the
total
number
of
closed
full
requests,
because
you
can't
close
more
requests
than
are
currently
open
so
that
total
will
always
be
larger
in
the
yeah.
D
The
closed
ones
will
always
be
a
smaller
number,
but
the
idea
is
for
that
to
be
a
small
Gap,
a
couple
of
potential
filters,
I
included
the
visualization
that
we
were
just
looking
at
and
that's
that's
kind
of
kind
of
where
I
got
on
this
one.
D
That's
mine,
okay,
yeah!
Actually,
so
if
you
look
at
the
link
back
at
the
the
keeping
up
with,
if
you.
B
D
I'll
probably
move
it
just
because
I
think
it's
better
to
have
it.
Do
we
want
to
have
it
just
in
one
place
and
link
to
it,
or
should
we
have
it
in
the
let's.
B
A
D
D
It
depends,
it
depends
a
lot
on
how
the
project
has
defined
their
roles,
so
they
might
have
other
roles
that
are
able
to
merge,
pull
requests
that
are
not
necessarily
called
a
maintainer,
so
they
might
have
a
separate
committer
role.
They
might
have
a
approver
role.
I
mean
I,
tend
to
Loosely
kind
of
think
of
all
of
those
as
maintainers.
C
So
if
we
were
to
call
this,
if
we
were
to
call
this
this
metric
attention
to
change
requests,
would
that
make
sense,
and
would
that
be
inclusive
of
maintainer
response
to
to
the
pull
request?
Like
a
comment,
maintainer
review
of
a
pull
request
or
change
request
and
maintain
a
merging
of
a
pull
request,
it
would
be
inclusive
of
all
those
things.
B
D
Or
a
close
without
merge,
but
the
the
actual
Act
of
closing
the
pull
request,
because
I
think
some
of
those
other
things
are
already
defined
in
various
metrics.
So
we
have
things
like
we
have
a
bunch
of
change
requests
metrics,
but
none
of
them
were
so
a
lot
of
them
were
kind
of
the
things
that
you
talked
about.
So
you
know
a
response,
a
comment,
a
review.
There
wasn't
actually
because
I
I
did
look
through
the
metrics
like
well,
maybe
I.
D
Maybe
there
isn't
I
couldn't
find
it,
but
I
couldn't
see
one
that
was
specifically
about
closing
the
change
requests.
E
But
we
do
have
one
that
is
about
a
ratio,
but
it's
overall,
like
oh
out
of
all
the
whole
requests.
How
many
do
you
accept
in
so
I?
Don't
want
to
confuse
it
with
that
one,
because
that's
a
different
thing:
yeah.
D
Yeah,
because
that
that's
pull
requests
merged
or
change
requests
emerged,
no
I
mean
that
that
definitely
that
definitely
makes
sense.
Can
you
say
it
one
more
time
just
so
I
can
about
it.
One
more
time.
E
E
D
I
do
I
do
kind
of
like
change,
requests,
change,
request,
closure
ratio,
I,
don't
know
what
do
other
people
think
about
that.
B
E
D
Yeah
but
I
do
think
if
we're
going
to
frame
it
as
a
as
a
ratio
that
might
mean
tweaking
some
of
the
other
other
bits
to
talk
more
about
how
it's
it's
a
ratio
rather
than
because
I
talked
about
it
as
like,
like
looking
at
the
gap
between
the
two
numbers,
but
I
think
it
might
be.
It
might
be
better
to
talk
about
it
in
the
context
of
of
ratio
just
to
be
kind
of
clear.
D
A
ratio
between
it's
the
ratio
between
the
total
number
of
open
pull
requests
in
a
time
period
against
the
total
number
of
pull
requests
closed
during
a
time
period
with
the
idea
that,
as
Elizabeth
said,
you
are
looking,
the
ideal
is
a
one-to-one.
D
E
D
Yeah,
okay,
I.
A
D
B
D
Whereas
if
you
just
look
at
the
number
of
pull
requests
that
were
opened
during
a
time
period,
you
can
easily
easily
close
all
of
those
and
still
have
a
gigantic
backlog,
so
it
hides
it
hides
the
backlog.
If
you,
if
you
just
look
at
the
number
that
were
opened
during
that
particular
period,
great.
C
C
Of
inclusive
of
that
technical
that
term
yes.
D
Oh,
what
else
do
we
have
on
the
agenda,
because
my
my
thinking
was
that
we've
spent
20
minutes
well,
not
counting
the
first
five
minutes
where
we
talked
about
plants.
D
So
it's
about
15
minutes
talking
about
this
one
metric
I'm
happy
to
go
off
and
rework
it
as
a
ratio
metric
myself.
If
we
have
other
things
that
we
need
to
get
through
in
the
rest
of
the
meeting,
if
we
don't
have
a
bunch
of
stuff
that
we
need
to
get
through,
I'm
also
happy
to
just
do
this
as
a
as
a
group
I'm
good
with
either
one
depending
on
what
else
we
need
to
cover.
Okay,.
D
A
Good
conversation
all
right,
okay,
so
the
we
have
other
metrics
in
progress,
but
before
we
get
to
those
in
vanads
not
on
right
now,
but
before
we
get
to
those
I
did
want
to
just
talk
a
little
bit
about
the
knowledge
base
kind
of
at
large,
but
then
specifically
focusing
on
the
Community
Resources,
and
the
reason
that
this
comes
up
is
because
right
now
are
contributing.
Files
across
the
project
are
inconsistent
and
I.
A
Think
our
readme's
I,
don't
they're,
probably
inconsistent
too
and
Don
had
some
suggestions
on
copyright
stuff,
so
they're
kind
of
a
I
think
there's
a
little
bit
of
interest
in
kind
of
cleaning
those
up
and
just
ensuring
that
they're
consistent
across
the
project
and
I
think
Kevin.
You
had
pointed
out
that
we
have
done
this
in
the
past,
but
it's
probably
important
to
do
it
occasionally
again,
probably.
B
C
A
It
so
as
I
go
into
the
templates
into
the
templates
part
of
the
knowledge
base.
I
will
say
that
I
absolutely
love
having
the
templates
in
the
knowledge
base
and
accessible
through
the
website.
It's
much
easier
to
find
all
of
these
templates,
and
they
are
they're
here,
which
is
great
I,
do
have
a
couple
comments
and
I'd
love
to
get
people's
feedback
on
the
template,
just
kind
of
how,
at
the
highest
level
how
we're
displaying
the
template.
A
So
in
this
situation
like
the
metric
template,
it
shows
up
as
a
page
here
in
the
knowledge
base.
Some
of
you
may
know
where
I'm
going
with
this.
Others
like
the
contributing.md,
is
a
link
this
to
a
contributing
to
the
contributing
page
on
GitHub.
So
it's
a
slightly
different
design,
and
this
isn't
even
the
contributing
document.
A
The
let
me
just
the
readme
is
the
same.
So
the
readme
or
here
it's
a
nothing
at
this
point,
so
we're
we're
some
of
them
go
out
to
GitHub
some
of
them
kind
of
go
to
the.
What
I
think
is
the
wrong
place.
Some
go
nowhere
in
summer
on
on
this.
In
this
knowledge
base.
So.
D
Oh
sorry,
let
me
ask
one
more
question:
how
often
are
are
these
pulled
in
from
from
GitHub.
C
I'm,
not
I'm,
not
exactly
certain
on
the
specific
amount
of
time
for
the
caching,
but
it's
probably
it
might
be
a
day
or
two
yeah
in
some
cases
and
I
can
I
can
or
we
we
can
clear
the
cache
if
we
we
want
it
to.
If
you
shift
that's
immediately.
C
We
we
do
have
server
side,
caching
as
well,
so
the
the
server-side
caching.
We
have
to
clear
that
on
the
WordPress
site,
okay,
so
I
generally,
do
that
anytime
we
pull
the
new
page
in,
but
I
don't
do
it
when
just
GitHub
pages
are.
B
D
It
will
eventually
get
there
okay.
The
reason
I
asked
was
that
I
wanted
to
make
sure
that
I
had
submitted
the
pull
request
against
the
right
markdown
file,
but
it
sounds
like
if
it's
cached-
it's
probably
it's
probably
the
right
place.
D
I
would
like
to
see
it
as
a
link
because
I'll
be
honest.
This
actually
doesn't
help
me
at
all,
because
I
need
the
raw
markdown,
yeah,
so
100
sure
I,
don't
even
know
where
to
go,
and
then
I
end
up
just
going
to
the
I'm,
like
oh
I'll,
go
to
the
community
repo
and
search
for
template,
oh
yeah
there
it
is
and
then
and
then
I
grab
the
raw
mark
down
and
paste
it
into
a
Google
doc.
B
C
C
So
you'll
need
you'll
need
one
page,
that
kind
of
provides
a
basic
description
and
the
link,
and
then
you
also
need
the
one
page
that
provides
the
actual
template.
C
D
What
I
would
suggest,
maybe
instead
of
doing
two
pages
for
each
of
like
what
we
have
here?
Maybe
we
just
have.
If
you
go
back
to
that
templates
page,
maybe,
instead
of
having
all
of
all
of
these
links,
do
we
just
have
like
one
page
that
has
links
to
all
of
the
templates,
because
we
could
have
a
you
know:
I,
don't
know
a
templates
page
about
about
our
templates
page,
something
so.
A
C
C
C
Text
at
the
top
of
that
that
that
links
to
the
the.
A
E
A
E
D
Yeah,
but
but
to
Kevin's
Point
we
do
have,
we
do
have
options
right
we
could
put.
If
you
go
back
to
the
metrics
template,
you
could
put
the
link
to
the
markdown
at
the
very
top,
so
that
makes
it
easy
for
us
to
find
because
I
think
that
what
we,
what
we
need
to
think
a
lot
about,
is
that
the
knowledge
base
is
not
really
actually
for
us
right.
D
B
A
B
A
A
D
That,
but
that
is
a
template
actually,
because
the
template
for
the
code
of
conduct
is
we
if
you
go
back
to
what
was
before
whoops
yeah
this?
This
is
what
we
want
people
to
put
in
each
of
the
individual
repositories.
C
C
For
the
yeah,
if
I
was
looking
for
the
the
text
that
I
need
to
add
for
the
code
of
conduct
in
the
in
the
repository,
that
would
be
very
confusing
to
me.
Yeah
also.
E
I,
don't
know
if
that,
just
as
an
aside
that
code
of
conduct
do
we
even
have
that
list
anymore,
since
we
went
away
from
the
mailing
list
stuff
like
if
you
click
on
that
that
says
the
chaos
inclusion
at
lists,
no,
no
go
back
yeah
right
there.
Chaos
include
like
I,
don't
think
I,
don't
even
know
if
we
have
that
now,
since
we
are
shutting
them
down.
So
we
need
to
think
about
that.
Just
another.
A
So
you're,
okay,
so
this
is
helpful.
So
what
I'll
do
is
I'll
open
up
a
a
thread
just
to
kind
of
articulate
what
we're
talking
about
here,
I,
don't
want
to
keep
it
open
too
long.
I'm
gonna
see
if
people
have
yet
opinions
just
because
I'd
like
to
get
this
looking
pretty
good
and
being
useful.
A
What
I
am
kind
of
hearing
is,
if
I
looked
at
the
code
of
conduct,
template
that
as
an
example
here
Kevin,
this
wasn't
clear
that
this
is
the
template,
so
I
mean
some
text
here.
That
would
say
you
know
this
link
takes
you
to
our
code
of
conduct.
This
is
actually
the
template
that
we
want
you
to
put
in
each
one
here
like
just
more
explicit
on
what
that
text
is
about
and
then
potentially
below
kind
of
in
this
white
space.
Here
you
know
above
where
this
article
was
helpful.
A
C
C
Mean
but
it's
just
it's
just
the
text
that
we
were
just
seeing
prior,
that
we
want
to
add
to
each
repo,
so
this
bit
here
is
actually
the
text
that
we
want
to
add
to
the
repo.
C
D
A
B
A
C
I
think
we
would
need
text
that
says
something
to
the
effect
of
create
a
code
of
conduct
MD
file
in
the
Repository
paste.
This
code
paste
this
marked
out
into
that
into
that
file.
Point.
B
C
We
could
otherwise
or
or
we
could
follow
the
the
other
pattern
which
would
link
to
well
I.
Don't
know
I
mean
maybe
we
need.
Maybe
we
need
direction
on
this
template
as
well
right,
so
maybe
there's.
Maybe
we
create
some
way
of
at
the
top
of
each
of
these
templates
documents.
We
we
create
kind
of
a
separate
area
where
we
provide
like
actual
direction
for
what
this
is
right.
So
this
this
is
the
the
metrics
model
template
you
can
edit
it
or
you
can
get
the
mark
down
here.
It's
used
for
this.
B
C
B
D
Yeah
I
was
just
I
was
just
looking
to
I
I
just
did
a
quick,
GitHub
apiatic
query
to
see
what
the
code
of
conducts
looked
like
for
our
repositories
and
all
of
the
ones
I
found
so
far,
I
haven't
iterated
through
all
of
the
repos.
Most
of
them
have
pasted
the
some
version
of
the
entire
entire
code
of
conduct,
including.
D
D
A
D
C
D
C
D
How
many
repositors
we
have
49
repositories,
let
me
look
through
I
can
probably
grab
all
50.
because
in
particular
the
chaos
ones
are.
Oh,
go
back.
Go
back
to
that
yeah.
D
B
D
D
I
think
so,
yeah
I
think
that
we're
we're
populating
all
of
we're
yeah
we're
populating.
So
sorry,
I'm,
not
very
articulate,
articulate
today.
So
the
thing
with
putting
it
here
is
that
when
a
new
repository
is
created,
it
will
grab
all
of
these
files
and
put
them
in
the
new
repository
I.
Do
not
believe
that
if
we
make
a
change
to
this,
that
it
then
changes
it
in
all
of
the
repositories,
I
think
it's
a
copy,
not
a
not
linked
in
any.
D
A
A
A
B
B
A
B
B
A
D
Do
you
want
me
to
I
can
send
you
a
quick
report.
Mat
yeah.
D
Can
I
just
send
you
a
big
big
chunks
of
Json?
Is
that
all
right,
because
that
way,
I
don't
have
to
do
anything
to
it?
That's.
B
A
You
know,
then
I
think
we
might
want
to
consider
how
we
present
this,
whether
it's
I
think
the
question
comes
down
to
whether
it's
a
just
a
link
to
the
GitHub
file
or
it's
a
link
plus
this
and
the
same
would
hold
true
for
the
metrics
model
template.
Is
it
just
a
link
to
the
template
in
GitHub,
or
is
it
a
link
plus
this
and
then
so
on
and
so
forth
kind
of
down
the
line
here,
yeah.
A
C
If
it's
being
populated
automatically
by
the
by
the
organization
I,
don't
know
that
we
need
to
keep
it
in
here
to.
A
Yep
yeah,
we
would
just
have
contributing,
and
then
I
mean
some
of
these
templates
too
I
do
wonder
about
like
just
as
as
being
present
so
read
me
for
sure
metric
model
metric,
contributing
the
release
issue,
template
I
think
is
good.
The
revising
these
are
checklists,
so
I'd.
Probably
these
probably
need
to
be.
This
needs
to
be
labeled
as
an
issue
template.
B
C
B
C
Say
on
that
that
contributing
in
the
file
that
document
that
it
points
to
is
not
a
great
document,
I
think
the
the
community,
the
community
team
or
the
community
handbook.
A
team
at
one
point
had
had
that
as
a
to-do
to
yeah.
A
A
A
Maybe
we
could
answer
just
first
answer
the
question
of
how
we
want
this
page,
for
example,
to
look
and
then
I
100
agree
with
you
like
the
template
for
the
readme
probably
needs
to
be
updated
itself
and
the
template
for
contributing
to
totally
needs
to
be
updated
as
well.
Yeah.
C
B
A
C
And
you
could
you
could
have
that
contributing
MD
to
the
the
GitHub
organization
level
to
automatically.
C
Yeah
I
think
I
think
it
needs
to
be
I,
think
it
needs
to
be
edited,
and
then
it
maybe
needs
to
link
to
maybe
some
more
specific
documentation
right.
So
if
we,
if
we
create
a
high
level
one,
then
it
can
also,
we
can
also
have
a
line
where
it
links
to
specifically
contributing
to
other
or
specifically
contributing
to
the
more
lab,
because
right
now,
it's
just
kind
of
a
general
contributing
to
GitHub.
C
C
It
should
be
more
about
the
specific
ways
to
contribute
to
chaos.
Yeah.
D
Way
better
documentation
how
to
do
stuff
on
GitHub
than
we're
ever
going
to
put
in
a
contributing
file,
but
this
is
something
everyone
makes
contributing.
Files
like
I've
been
trying
to
get
us
not
to
do
that
at
VMware,
because
we
we
also
do
this
with
our
contributing
files
at
VMware,
and
it's
like
no,
it's
not
just
link
to
it.
Yeah.
A
Yeah,
so
this
is
super
helpful,
so
what
I'm
understanding?
Okay,
I'm,
not
even
going
to
repeat
it,
but
this
is
super
helpful
and
maybe
my
repeat
would
be.
It
sounds
like
there's
a
series
of
maybe
three
steps
to
start
cleaning
this
up
and
the
the
last
step
is
actually
changing
the
content
in
contributing
or
in
readme.
A
C
Think
your
action
item
is
just
the
just
the
code
of
conduct,
MD
file.
C
If
I
was
understanding
that
correctly,
just
yeah
at
the
organization
level
and.
A
In
the
determination
of
how
to
present
the
the
templates,
yeah
right
link
or
link
plus
text,
basically,
it
sounds
like
we're
all
in
agree
with
that.
We
want
it
to
link
out
to
GitHub,
because.