
►
From YouTube: CHAOSS Metrics Models Working Group 9-14-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).
C
B
B
C
B
B
C
B
All
right
um
all
right,
so
I
think
a
few
things
that
that
we
need
to
think
about.
I
know
that
we
have
some
metrics
models
that
we
want
to
talk
about,
and
I
know
yeah
we
had
done
a
metrics
model
and
we
can
take
a
look
at
that
in
a
pull
request
down
here
and
I
had
started
one
as
a
google
doc
for
event
badging,
and
we
can
take
a
look
at
that
too,
but
to
kevin's
point
as
well.
D
B
D
D
B
B
D
D
C
B
B
B
B
E
B
B
D
B
D
B
C
B
B
B
Focus
like
is
this:
what
we
want
to
do.
Oh,
I
should
probably
not
name
that
metric
metric
model,
um
but
we
just
have
seen
I'm
saying
it'd
just
be
a
pretty
simple
readme
here.
It
would
just
be
a
the
name
and
we
have
to
specify
the
goal.
We
could
just
put
this
in
as
a
placeholder,
and
I
could
then
put
out
all
of
these
readmes
in
the
respective
folders.
That
would
just
correspond
to
these.
B
B
F
B
D
F
B
Okay,
okay,
I
can
do
that
and
then
just
so
I
had
only
done
one,
but
just
so
you
know
I'll
make
a
folder
then,
like
I
said,
for
each
one
of
these
particular
focus
areas
and
then
within
there,
that
folder
will
capture
all
the
metric
metric
models
for
each
one
of
those
focus
areas.
So
like
yeah,
I
think
the
one
that
you
had
done.
I
don't
obviously
it's
not
placed
in
a
folder
the
pull
request.
I
think
you
just
placed
it
like
in
the
main
repo,
but
we
can
move
it.
I
B
B
B
G
B
B
B
I
need
to
format
this
a
little
bit,
but
we
have
a
metrics
model
template
here
and
based
on
looking
at
the
upcoming
metrics
models.
I'm
gonna
suggest
one
one
or
two
changes
to
this.
This
template
all
right,
so
you
can
just
wait
with
wait
with
excitement.
While
we
do
something
before
I
tell
you,
what
those
changes
propose.
Changes
would
be
all
right
so
now
we're
finally
into
the
metrics
model.
B
A
B
I
Yeah,
it's
about
uh
part
of
the
development,
precise
uh
model
matrix
model,
but
but
you
know
we
have
goal
that
we
should
provide
integrate
everything
into
one
model.
So
I
I
divide
those
development,
uh
oh
okay,
into
several
parts.
So
this
is
the
first
part
about
issue
handling
or
they
can
call
to
the
requirement
anyway.
I
A
I
C
I
So
I
integrated
with
the
latest
matrix
model
like
a
bot
activity,
something
like
that
into
the
issue
response,
because
we
invoke
a
lot
of
uh
thoughts,
activities
with
the
response
and
also
some
other
new
metrics.
So
I
go
through
how
the
metrics
we
have
today
and
they
plan
to
use
media
stage
next
month.
B
B
I
B
I
B
H
D
D
E
So,
uh
uh
adding
to
the
cabins
like
on
focusing
in
like
when
I
was
reading,
okay,
new
issue,
thinking
that
somebody
has
opened
a
new
issue
and
somebody
has
responded
to
the
new
issue.
So
I
was
thinking
like
how
the
bus
factor
is
impacting
a
new
issue.
So
these
kinds
of
questions
making
you
think,
maybe
we
have
some
description
to
add
to
those
list
of
metrics
like
I
was
having
hard
time
to
connect
this
first
factor
with
a
new
issue,
so
how
this
bus
factor
is
connected
to
a
new
issue
that
somebody.
I
Else:
okay,
the
bus
factor
means
we
need
to.
I
mean
we
need
to
guide
those
uh
people
or
users
identities,
uh
including
uh
where
are
they
come
from?
Maybe
come
from
comes
from
the
different
organizations,
so
we
could
collect
those
information
to
identify
okay
today
or
this
month,
most
issues
was
created
by
one
company
of
all
organizations.
I
E
Okay,
so
this
is
helpful,
but
what
I
felt
is
like
now
you
have
provided
me
the
context.
This
is
helping
me
to
connect
the
dots,
but,
let's
just
looking
at
the
bigger
picture,
I
was
having
a
hard
time
to
connect
the
dots.
So
that's
where
I
was
trying
to
say
maybe
a
some
context.
Background
will
be
helpful
in
this
way
to
help
our
reader
to
think
through
those
contexts
that
we
can
provide
them
just
looking
at
the
list,
I
like
it
was
good.
E
D
B
So
there
is
a
story
there
for
me
that
I
can
create
to
myself
um
and
so
then
my
second
comment
is:
I'm
I'm
really
hesitant
to
in,
like,
in
this
case,
to
add
descriptions
to
everything
like
why
new
issues
why
new
contributors?
Why
contributor
attribution?
Why
issue
label
inclusivity
um
and
the
reason.
B
Do
some
of
the
metrics
show
up
in
indifferent?
They
show
up
an
issue
new
and
they
show
up
initial
response
and
they
may
show
up
an
issue
closed.
I
don't
know,
um
but
it
would
make
the
the
document
huge
and
we're
trying
to.
I
think
we're
just
trying
to
draw
people
to
a
location
where
they
can
think
about
the
metrics
in
really
just
kind
of
concise
ways
that
that
maybe
they
haven't
otherwise
been
able
to.
D
So
I
do
uh
I
do
agree.
I
think
simple
is
better.
uh
So
too
much
too
much
text
content
is
going
to
take
away
from
it.
I
think
the
uh
so
simplicity
in
the
description
and
also
simplicity
in
in
the
models
I
think,
are
better
and
then
to
the
to
the
point
that
she
made
earlier
when
I,
when
I
look
at
this
model.
Yes,
it
tells
it
tells
me
a
story
as
well
as
a
matter
of
fact.
D
It
tells
to
the
point
that
I
was
trying
to
make
is
that
it
actually
tells
me
four
or
five
different
stories,
uh
and
maybe
that's
the
maybe
that's
a
little
bit
the
strength
of
the
model
in
that
it
can
be
interpreted
a
little
bit
differently.
uh
But
the
point
that
I
was
making
is,
it
might
be,
it
might
be
nice
to
to
focus
in
on
those
three
or
four
or
five
stories
that
I'm
seeing
and
create
a
model
specifically
for
those
as
well.
B
So
that's
um
we'll
run
into
the
same
thing.
Actually,
it's
interesting
because
we'll
run
into
the
same
issue
on
the
metric
model
that
I
put
together
for
the
dei
event
badging
because,
like
for
event,
badging
they're,
all
the
metrics
and
you
don't
have
to
attend
to
all
of
them.
Each
one
of
them
can
have
like
an
impact
on
the
metric
model
that
is
dei
event
badging.
B
D
And
it
does,
it
does
become
a
problem
of
scope
for
us
when
we're
def
when
we're
creating
these
metrics
models.
So
how
do
we
know?
How
do
we
know
the
scope
that
we're
looking
at?
Are
we
looking
at
it
at
a
high
level
like
this,
or
are
we
looking
at
it
at
a
at
a
lower
level,
or
are
we
looking
at
it
in
in
both
ways.
B
H
I
think
that
there
are
many
uh
there
are
an
infinite
number
of
use
cases
for
the
models.
There
is
no.
There
is
no
one
scope
or
complexity
level
uh
and,
as
as
as
we
learn
how
to
write
these
we'll
do
a
variety
of
kind
of
complexity
levels.
You
know
simpler
ones,
more
complicated
ones.
um
So,
for
example,
the
uh
why
you
should
care
section
um
for
some
other
hypothetical
model
might
say.
H
The
influence
of
the
bus
factor
on
um
on
the
waiting
time
for
issues
to
be
accepted
and
then
the
only
real
metric
would
be
uh
the
bus
factor,
and
I
don't
have
it
open
on
the
screen
right
now,
but
whatever
there
is
that
talks
about
the
um
the
throughput
processing
time.
um
So
in
that
case
there
would
only
be
two
metrics
or
maybe
three
at
the
most
that
were
actually
so.
I
think
that,
um
to
summarize
I
see
this
particular
model
as
being
um
kind
of
a
proof
of
concept
uh
and
will
develop.
B
D
D
C
B
B
um
That
model
was
too
big
needed
to
scope
it
down
to
just
the
issue
component
um
and
I
think,
we're
just
kind
of
kevin.
I
think
you're
wondering
how
and
you
can
totally
correct
me
if
I'm
wrong
but
like
how
far
down
do
we
scope
it?
You
know
what
I
mean
and
lucas
then
is
saying
we
may
have
metrics
models,
that
kind
of
live
at
different
scopes
and
that's
okay,
right
um
and
and
we'll
find
the
groove
over
time.
I'm
trying
to
summarize
you
huey
kevin
and
lucas
yeah,
one.
D
Yeah,
I
agree.
I
agree
with
that.
I
think
we
can
have
models
that
exist
at
different
scopes,
but
I
think
we
have
to
be
kind
of
clear
about
what
those
what
those
scopes
are
when
we're
defining
this.
So
I
think
the
the
first
thing
that
I
had
said
was:
I
thought
this
model
was
a
great
high
level
model
because
for
me,
when
I
look
at
it,
I
see
five
stories
and
it's
and
it's
a
great
model
for
that,
because
when
I
looked
at
it,
I
immediately
looked
at
it
and
saw
five
stories.
B
Maybe
I'm
okay
with
that,
like
that,
they
don't
need
to
be
like,
I
think,
about
our
metrics.
Some
of
our
metrics
are
they're,
just
like
a
single
thing
and
other
like
of
the
are
small
unit.
Metrics
and
other
metrics
are
considerably
more
complex
and
that
doesn't
seem
to
get
in
the
way
of
how
we
talk
about
metrics,
I
mean:
do
you
see
this
as
a
potential
problem.
I
I
I
B
B
B
B
I
B
D
In
there,
but
I
don't
think
we
need
references
because
we
are
referencing
the
metrics,
uh
so
we
don't
need
to.
We
don't
need
to
reference
any
external
literature
websites.
We
just
need
to
reference
our
metrics,
so
I
think
I
think
resources
or
I
think,
uh
what's
the
heading,
is
it
tooling
or
uh
implementation
implementation?
That's
what
it's
called
yeah,
so
maybe
the
maybe
that
section
is
implementation.
D
B
Now
there
could
there
there
could
be
a
case
for
um
references,
and
my
only
thought
here
is
um
like
I'm
reading
an
opensource.com
article
and
somebody's
like
we
should
look
at
this
metric,
this
metric
this
metric
and
this
metric.
When
we're
thinking
about
this
concept,
I
can
see
somebody
writing
something
like
that
up.
E
K
K
B
B
C
H
I
had
two
things
I
just
wanted
to
throw
out
there.
um
Let's
do
it
one
is
um
um
I'm
not
able
to
edit
this
sharepoint
document
because
of
some
weirdness
in
microsoft's
accounts,
yeah,
I'm
having
the
same
problem.
I
I
wonder
if
this
could
live
in
github.
Would
that
be
I?
I
know
that
could
be
really
inconvenient.