►
From YouTube: CHAOSS Risk Working Group 2/24/22
Description
Links to minutes from this meeting are on https://chaoss.community/participate.
D
E
E
E
A
A
A
C
C
C
E
On
that
matter,
I
had
wondered
if
we
should
put
something
similar
up
top
in
the
notes.
Section:
okay!
E
Well,
I
I
don't
know
again
like
maybe
that's
not
the
right
place
for
it
if
we
do
have
it
there,
but
just
acknowledging
that
each
project
has
their
own
mechanism,
so
we
can
do
that
more
generically,
but
we
could
also
do
it
at
the
bottom
of
the
labels
yeah,
because,
like
the
specific
example
that
we
have
about
a
defect,
consider
it
consider
it
being
resolved
when
the
issue
is
closed
and
merged
and
connected
to
the
associated
files.
But
that's
only
if
that's
the
process.
E
D
A
F
A
C
C
A
I'd
say
right
now:
we
don't
have
any
visualizations
for
for
this
that
are
developed.
So,
given
the
metric
release
date
of
march
1st,
are
we
comfortable
going
without
a
visualization
right
now.
A
F
E
I
have
another
tool
that
provides
a
very
similar
metric.
It's
not
the
exact
same
metric,
but
it's
also
maybe
a
little
bit
too
googly,
as
in
it's
one
of
our
products,.
E
It's
a
github
page,
so
it's
a
there's
a
public
project.
I
think
the
problem
is
that
the
project
is
set
up
to
pull
it
on
bigquery,
but
in
theory
you
could
point
it
to
any
sql
database.
D
C
E
A
C
A
A
E
C
E
More
about
service
failure
and
change
rates
versus
code
base
failure,
change
rates,
which
is
a
mild
distinction,
but
given
I
mostly
want
to
link
to
it
because
you
can
change
that
as
a
user,
so,
depending
on
it's
all
customizable,
this
is
just
what's
canned
out
of
the
box,
so
it's
just
another
tool
to
play
around
with,
but
it's
also
not
part
of
this
project
and
again
it
could
be
a
little
bit
too
googly.
So
I'm
completely
fine
to
strip
it
out.
I
just
wanted
to
throw
it
as
another
reference.
C
A
Yeah
I
hear
you
so
there
was
if,
when
there,
so,
when
is
it
we
only
kind
of
know
when
a
defect
is
identified
and
how
quickly
it's
resolved?
A
C
E
I
have
potentially
a
better
visual
if
we
want
to
do
for
more
laps
one.
Oh
so
right
now,
one
of
our
can
dashboards
for
the
chaos
project
is
maintain
a
response
to
merge
requests
duration.
E
E
Median
time
to
merge,
which
is
a
separate
dashboard,
wow,
okay,
it's
just
whether
or
not
we
can
if
we
could
filter
this
by
any
kind
of
like
bug
or
issue
tag
which
I
don't
know.
If
we
do,
then
I
think
that's
that's
a
better
visual.
It's
also
one
of
our
projects
versus
another
project.
There's
a
tag
there
yeah.
C
C
E
Here
we
go,
labels
is
bug
and
I'm
also
doing
for
the
pull
request.
Efficiency.
E
So
I
think
either
one
of
those
the
pull
request-
efficiency,
dashboard-
that
is
not
not
not.
Oh,.
A
A
E
The
link
didn't
preserve
my
filter,
so
we
might
have
to.
I
think
you
have
to
copy
there's
a
separate
copy.
That's
not
just
the
url!
If
you
want.
A
Oh
geez,
okay,
that's
a
big
link!
Shortener
going
there.
A
No,
it's
just
somebody
who's
promoting
nfts
and
stocks,
and
I'm
like
I
don't
even
know
how
this
happened,
but
I
eliminated
a
bunch
of.
A
E
Essentially
absolves
us
from
making
the
recommendation
that
projects
should
have
slas,
because
we
don't
want
to
make
that
recommendation
and
projects
have
their
own
operational
cadences
that
like
there,
there
is
no
such
thing
as
an
slam
project,
at
least
not
that
I've
seen-
and
I
know
like
it's
like
now-
that
we're
entering
into
a
land
where,
if
this
was
a
proprietary
tool,
there
would
be
an
sla
for
something
like
this,
but
there's
not,
and
so
I'm
wondering
if
there's
it's
worth,
adding
some
language
around.
E
There's
no
agreement
like
we
don't
have
a
contract.
There
is
no
sla
and
now
that
we're
suggesting
a
metric
that
very
much
could
be
construed
as
that.
I
want
to
make
sure
that
we
are
not
we're
not
stating
that
or
we're
not
confusing
people
into
thinking
that
they're
applying
slas
to
projects
and
project
maintainers.
E
F
A
D
Not
like
a
forcing
function
for
community
because
open
source
is
a
volunteer
driven.
C
G
E
I
think-
that's
probably
I
mean
I'm
guessing
here,
but
I
feel,
like
that's,
probably
a
metric.
That's
coming
out
of
the
like
the
common
working
group
in
terms
of
like
community
size,
but
it
has
nothing
to
do
with
response
times,
but
I
feel
like
that
could
be
a
nice
pointer
to
make
that
that
connection.
F
A
We
can
remove
these
document.
Note
things
here
now
right,
yes,.
E
I
was
thinking
in
relation
to
please
correct
me
if
I
see
your
name
wrong,
renisha's
comment
on
just
community
size
and
sort
of
impact
on
this.
I
was
thinking
the
two
things
we
could
do
in
filters
or
maybe
be
to
link
the
related
metrics
that
you
might
be
tracking,
so
one
of
them
is
just
population,
I'm
within
the
common
working
group-
and
I
can
put
a
link
to
that
metric
in
here.
E
But
depending
on
the
robustness
of
your
metrics
program,
I
would
probably
be
looking
at
those
in
concert
with
each
other,
like
we
did
with
the
gramor
labs
tool,
which
is
we're
looking
at
medium
pull,
request,
velocity
to
begin
with,
and
then
looking
at
bug
and
defect
resolution
as
a
related
metric,
because
that'll
kind
of
put
you
in
the
right
time
scale
of
like
generally
responsiveness
and
then
responsiveness
to
defects
versus.
If
you're,
just
looking
at
responsiveness,
defects
in
a
vacuum,
it
doesn't
really
give
you
a
sense
of
the.
E
It
could
tell
you
whether
or
not
the
measurement
is
more
or
less
believable,
because
it
puts
it
in
context
with
the
broader
operational
component.
So
I
wonder
that
should
be
a
filter
or
in
the
sort
of
like
references
we
could
link
to
like
other
metrics.
You
will
most
likely
be
tracking
in
relation
to
this
one
now
or
shouldn't
you
be
saying,
affiliated.
C
C
Or
relative
or
related
metrics
yeah,
caribbean
references.
I
could
go
there.
C
No
they're
not
synonyms.
It's
more
yeah
they're,
like
it's
things
that
you
want
to
look
at
in
conjunction
with
this.
D
E
One
minor
nuance
to
this:
I'm
trying
to
think
if
it's
it's
anywhere
explicitly
now
that
I'm
recalling
I'm
looking
at
not
exactly
distinguishing
between
the
time
that
the
issue
or
defect
is
reported
and
the
time
of
the
issue
or
defect
is
reported
in
the
project.
So
an
example
is
log
4j.
It
was
just
a
blog
post
and
a
cbe
not
in
the
blog4j
project
github
so
like
there
could
be
an
announcement
of
a
vulnerability
or
a
defect.
E
That's
public
and
announced,
but
not
actually
in
the
time
like
in
the
direct
context
of
the
project,
and
it's
like
that.
You
can't
really
measure
that.
So
we
do
want
to
be
more
explicit,
then
we
should
provide
the
additional
context
of
it
being
reported
inside
the
project's
spaces.
B
D
Yeah
and
also
it
was
like
in
the
last
discussion,
I
recall
david
specifically
forced
it
that
unless
it
is
reported
on
the
reporting
mechanism
of
the
project,
it
can
be
github
or
anything
if
it
is
in
a
blog
or
somewhere.
It
is
reported,
but
it's
not
reported
in
the
project.
You
cannot
measure
the
time.
F
A
C
E
C
A
E
A
C
Drop
right
now,
but
yeah.
A
I
I
think
I
do
too
so
thank
you,
everyone.
We
have
a
metric
to
release
good
on
us
and
I'll
move
it
forward
that
yeah
thank.